The thing is, as far as I remember when network units were in place, even
before reboot, the system tried to apply them to any newly appeared interface,
i.e. created by tinc or pptp, despite MAC filter. Anyway, now it does not, so
it fixed.
___
Pkg-sy
> Please make sure to update your initramfs (via update-initramfs -u).
> Those link and udev rules files are embedded in the initramfs, so you
> need to ensure it is rebuilt.
>
> Can you please report back what happens if you do that?
I do not remember for certain if I did that earlier.
Anyway,
I've tested it again.
Removed 70-persistent-net.rules, created two units in /etc/systemd/network:
10-lan1.link:
[Match]
MACAddress=xx:xx:xx:xx:xx:xx
[Link]
Name=lan1
10-wan0.link:
[Match]
MACAddress=yy:yy:yy:yy:yy:yy
[Link]
Name=wan0
(Apparently MAC values in quotes are in
> ppp0 being renamed to rename13 sounds suspiciously like the old network
> interface naming is still being used.
> Can you attach your /etc/udev/rules.d/70-persistent-net.rules if present
I do not remember for sure, but I probably moved or commented out this file
back when I tested the new schem
@Jonathan de Boyne Pollard
SIGHUP behavior you've described seems like the proper logical solution. Was it
ever explicitly submitted upstream?
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.d
If some software is supposed to relate to user's session and does not properly
exit with session, that is the bug of said software and no business of init
system.
This change breaks things and requires to jump through hoops to repair things
that until now just worked.
__
This also happens with tap devices. The one created by tinc daemon is also
renamed. The sole .link file present is matching local ethernet device by MAC.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lis
> That sounds like you have an outdated udev rule in the initramfs, which
> renames your interface.
> Please run "update-initramfs -u" and then test again.
That seem to be the case, thank you!
Digging a bit deeper, I now think that udev's README should be updated and
initramfs-tools should someho
I've googled out that this can have something to do with lvmetad enabled or
not.
I've enabled lvmetad in /etc/lvm/lvm.conf, reconfigured current kernel package.
On boot, there were error messages about failed connection to lvmetad socket,
but boot process finished successfully without any waiti
I have this problem too, not every boot, but some 1 in 2-3 boots. Home
partition times out.
Just plain ext4 on LVM, no encryption.
>From the log:
systemd[1]: Job dev-mapper-mf4sys\x2dhome.device/start timed out.
systemd[1]: Timed out waiting for device dev-mapper-mf4sys\x2dhome.device.
system
10 matches
Mail list logo
