Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
On 2022-01-06 13:23:37, Michael Biebl wrote: Am Do., 6. Jan. 2022 um 10:00 Uhr schrieb Mantas Mikulėnas : Grep your entire /etc for those interface names (starting with /etc/udev), find out where they're defined, and remove them Please also make sure to rebuild your initramfs after doing that. Files from /etc/udev are usually embedded in the initramfs. The initrd has been rebuilt and eth4 and eth5 are gone. # ls -l /sys/class/net/* lrwxrwxrwx 1 root root 0 Jan 6 15:06 /sys/class/net/eno1 -> ../../devices/pci:00/:00:01.1/:02:00.0/net/eno1 lrwxrwxrwx 1 root root 0 Jan 6 15:07 /sys/class/net/enp2s0f1 -> ../../devices/pci:00/:00:01.1/:02:00.1/net/enp2s0f1 lrwxrwxrwx 1 root root 0 Jan 6 15:07 /sys/class/net/enp2s0f2 -> ../../devices/pci:00/:00:01.1/:02:00.2/net/enp2s0f2 lrwxrwxrwx 1 root root 0 Jan 6 15:07 /sys/class/net/enp2s0f3 -> ../../devices/pci:00/:00:01.1/:02:00.3/net/enp2s0f3 lrwxrwxrwx 1 root root 0 Jan 6 15:07 /sys/class/net/enp5s0 -> ../../devices/pci:00/:00:1c.4/:05:00.0/net/enp5s0 lrwxrwxrwx 1 root root 0 Jan 6 15:05 /sys/class/net/eth3 -> ../../devices/pci:00/:00:19.0/net/eth3 lrwxrwxrwx 1 root root 0 Jan 6 15:07 /sys/class/net/lo -> ../../devices/virtual/net/lo eno1 and eth3 are still present, i.e. the original problem (2 onboard interfaces supposed to be renamed to eno1) is still unresolved. The workaround is to kick out "onboard" in the NamePolicy, e.g.: # cat /etc/systemd/network/98-ignore-onboard.link [Match] OriginalName=* [Link] NamePolicy=keep kernel database slot path AlternativeNamesPolicy=database onboard slot path MACAddressPolicy=persistent (https://www.freedesktop.org/software/systemd/man/systemd.link.html) Do you think it would be reasonable for udev to use the next option from the name policy list instead of falling back to the "kernel" policy, if there is a conflict? Thank you very much for your support and your patience Regards Harri
Re: [systemd-devel] homed: Issues with LUKS storage on btrfs
Hi, Sebastian Wiesner wrote on 28/12/2021 00:04: Hello, I've experimented with homectl today, and noticed two issues when creating LUKS-lookback-backed home areas on top of a btrfs filesystem: 1) homectl resize doesn't work reliably on btrfs: It looks as if on btrfs resizing a home area requires more free space on the underlying btrfs filesystem than I expected. I assumed that resizing from X to Y only requires Y-X extra free space on the underlying device, but on btrfs it seems to require Y free space, i.e. it looks as if homectl attempts to allocate the entire home area anew. I've found https://github.com/systemd/systemd/issues/19398 which looks like the problem, but went nowhere. 2) homectl creates loopback files which have COW-enabled. As far as I understand btrfs it's not recommended to enable COW for large files which frequently get updated in-place which as far as I see it would include the backing loopback files for LUKS home areas. Shouldn't homectl explicitly disable COW for new home areas if the underlying file system is btrfs? I can work around 2) by setting -C on /home/ but I haven't figured out a solution for 1) Is LUKS on btrfs supported by homectl? Or should I rather use e.g. ext4 as underlying file system for /home/? I'm migrating to a similar setup with a new laptop so would be interested in guidance/recommendations on this too if it's available. Reddit/other google results seem a little dated. Managed to get it working on Fedora 35 install with a little PAM fighting and selinux tweaks. Col
Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
Am Do., 6. Jan. 2022 um 10:00 Uhr schrieb Mantas Mikulėnas : > Grep your entire /etc for those interface names (starting with /etc/udev), > find out where they're defined, and remove them Please also make sure to rebuild your initramfs after doing that. Files from /etc/udev are usually embedded in the initramfs.
Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
On Thu, Jan 6, 2022 at 10:42 AM Harald Dunkel
wrote:
> On 2022-01-05 21:48:11, Michael Biebl wrote:
> > Am Mi., 5. Jan. 2022 um 13:50 Uhr schrieb Mantas Mikulėnas <
> graw...@gmail.com>:
> >> It does, yes, but note this part:
> >>
> >> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4:
> renamed from eth2
> >> Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5:
> renamed from eth3
> >>
> >> Here the kernel-assigned names (eth2, eth3) are being renamed to custom
> names (eth4, eth5). That's not something systemd or udev does by default.
> It suggests that you likely have old "70-persistent-net" udev rules (or
> something similar) that assign custom eth* names separately from the
> slot-based "predictable" naming – perhaps a leftover from Debian 7.
> >>
> >> These interfaces aren't being skipped due to an earlier conflict – they
> are intentionally skipped by 80-net-setup-link.rules because they already
> have a custom 'NAME=' assigned by an earlier rule, so the "predictable"
> name is not applied to avoid breaking existing configuration.
> >
> > Yes, please check if you have a leftover file
> > /etc/udev/rules.d/70-persistent-net.rules
> > See also the relevant NEWS entry in /usr/share/doc/udev/NEWS.Debian.gz
> >
>
> You are right about Debian 7 wrt 70-persistent-net.rules, but for Debian
> 10 I had used net.ifnames=0. It was changed to 1 after(!) the upgrade to
> Debian 11:
>
That's really irrelevant to what I was saying. The net.ifnames= option only
disables the "predictable naming" udev helper; it does nothing about custom
udev rules that directly set NAME= on network interfaces (and are
apparently setting NAME="eth4" on your system).
Grep your entire /etc for those interface names (starting with /etc/udev),
find out where they're defined, and remove them – that should bring the
enp* names back. (Also grep for "eno1" just in case.)
As for 'index' and 'acpi_index' attributes, they're in /sys on the parent
PCI device of the network interface (e.g.
/sys/class/net/eth2/../../{acpi_,}index or
/sys/bus/pci/devices/:02:00.2/{acpi_,}index), another way to see them
is `udevadm info -a /sys/class/net/eth2`.
--
Mantas Mikulėnas
Re: [systemd-devel] eth2: Failed to rename network interface 6 from 'eth2' to 'eno1': File exists
On 2022-01-05 21:48:11, Michael Biebl wrote: Am Mi., 5. Jan. 2022 um 13:50 Uhr schrieb Mantas Mikulėnas : It does, yes, but note this part: Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.2 eth4: renamed from eth2 Jan 03 11:30:14 nasl002b.example.com kernel: igb :02:00.3 eth5: renamed from eth3 Here the kernel-assigned names (eth2, eth3) are being renamed to custom names (eth4, eth5). That's not something systemd or udev does by default. It suggests that you likely have old "70-persistent-net" udev rules (or something similar) that assign custom eth* names separately from the slot-based "predictable" naming – perhaps a leftover from Debian 7. These interfaces aren't being skipped due to an earlier conflict – they are intentionally skipped by 80-net-setup-link.rules because they already have a custom 'NAME=' assigned by an earlier rule, so the "predictable" name is not applied to avoid breaking existing configuration. Yes, please check if you have a leftover file /etc/udev/rules.d/70-persistent-net.rules See also the relevant NEWS entry in /usr/share/doc/udev/NEWS.Debian.gz You are right about Debian 7 wrt 70-persistent-net.rules, but for Debian 10 I had used net.ifnames=0. It was changed to 1 after(!) the upgrade to Debian 11: root@nasl002b:/etc/default# git diff 0b18eef098908adf5a5478c2938c0228f971494d 0bcaa7872b54f31bfe0f1ed8cf403a7990844746 -- grub diff --git a/default/grub b/default/grub index c723e1f..5b5e60b 100644 --- a/default/grub +++ b/default/grub @@ -6,8 +6,8 @@ GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` -GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 vsyscall=emulate quiet" -GRUB_CMDLINE_LINUX="net.ifnames=0 vsyscall=emulate nfs.nfs4_unique_id=43705d58-c986-4b4b-9205-50040cbdd9c6" +GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=1 vsyscall=emulate quiet" +GRUB_CMDLINE_LINUX="net.ifnames=1 vsyscall=emulate nfs.nfs4_unique_id=43705d58-c986-4b4b-9205-50040cbdd9c6" # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains Regards Harri
