Created attachment 790556 [details] Output of emerge --info sys-apps/systemd-utils I noticed eth0 wasn't getting renamed to enp8s0 like I wanted it to so I had to manually rename network interface device. I also noticed that when I ran startx and opened up into dwm I didn't have any use of m\kb nor my usb audio interface. I took me a while to figure out why, but I ended up downgrading systemmd-utils-251.2-r1 down to 250. After that my issues where resolved. I'm not sure on what else to post besides emerge --info, but I will gladly provide any more information if needed.
Please run the following command as root and provide the output. udevadm test --action=add /sys/class/net/eth0 Replace "eth0" with whatever name your network interface currently has.
Note that I want to see the output of the command with 251.2 installed, not 250.
Here's output with systemd-utils:251 ❯ doas udevadm test --action=add /sys/class/net/eth0/ This program is for debugging only, it does not run any program specified by a RUN key. It may show incorrect results, because some values may be different, or not available at a simulation run. Trying to open "/etc/systemd/hwdb/hwdb.bin"... Trying to open "/etc/udev/hwdb.bin"... === trie on-disk === tool version: 251 file size: 11547705 bytes header size 80 bytes strings 2439297 bytes nodes 9108328 bytes Load module index Found cgroup2 on /sys/fs/cgroup/unified, unified hierarchy for systemd controller Found container virtualization none. Using default interface naming scheme 'v251'. Parsed configuration file "/lib/systemd/network/99-default.link" Created link configuration context. Loaded timestamp for '/etc/udev/rules.d'. Loaded timestamp for '/run/udev/rules.d'. Reading rules file: /lib/udev/rules.d/10-dm.rules Reading rules file: /lib/udev/rules.d/11-dm-lvm.rules Reading rules file: /lib/udev/rules.d/13-dm-disk.rules Reading rules file: /lib/udev/rules.d/40-gentoo.rules Reading rules file: /lib/udev/rules.d/50-udev-default.rules Reading rules file: /lib/udev/rules.d/60-autosuspend.rules Reading rules file: /lib/udev/rules.d/60-block.rules Reading rules file: /lib/udev/rules.d/60-cdrom_id.rules Reading rules file: /lib/udev/rules.d/60-drm.rules Reading rules file: /lib/udev/rules.d/60-evdev.rules Reading rules file: /lib/udev/rules.d/60-fido-id.rules Reading rules file: /lib/udev/rules.d/60-input-id.rules Reading rules file: /lib/udev/rules.d/60-persistent-alsa.rules Reading rules file: /lib/udev/rules.d/60-persistent-input.rules Reading rules file: /lib/udev/rules.d/60-persistent-storage-tape.rules Reading rules file: /lib/udev/rules.d/60-persistent-storage.rules Reading rules file: /lib/udev/rules.d/60-persistent-v4l.rules Reading rules file: /lib/udev/rules.d/60-sensor.rules Reading rules file: /lib/udev/rules.d/60-serial.rules Reading rules file: /run/udev/rules.d/61-dev-root-link.rules Reading rules file: /lib/udev/rules.d/64-btrfs.rules Reading rules file: /lib/udev/rules.d/69-cd-sensors.rules Reading rules file: /lib/udev/rules.d/69-dm-lvm.rules Reading rules file: /lib/udev/rules.d/70-camera.rules Reading rules file: /lib/udev/rules.d/70-joystick.rules Reading rules file: /lib/udev/rules.d/70-memory.rules Reading rules file: /lib/udev/rules.d/70-mouse.rules Reading rules file: /lib/udev/rules.d/70-power-switch.rules Reading rules file: /lib/udev/rules.d/70-touchpad.rules Reading rules file: /lib/udev/rules.d/71-seat.rules Reading rules file: /lib/udev/rules.d/73-seat-late.rules Reading rules file: /lib/udev/rules.d/75-net-description.rules Reading rules file: /lib/udev/rules.d/75-probe_mtd.rules Reading rules file: /lib/udev/rules.d/78-sound-card.rules Reading rules file: /lib/udev/rules.d/80-drivers.rules Reading rules file: /lib/udev/rules.d/80-libinput-device-groups.rules Reading rules file: /lib/udev/rules.d/80-net-setup-link.rules Reading rules file: /lib/udev/rules.d/80-udisks2.rules Reading rules file: /lib/udev/rules.d/81-net-dhcp.rules Reading rules file: /lib/udev/rules.d/90-alsa-restore.rules Reading rules file: /lib/udev/rules.d/90-fwupd-devices.rules Reading rules file: /lib/udev/rules.d/90-libinput-fuzz-override.rules Reading rules file: /lib/udev/rules.d/90-pipewire-alsa.rules Reading rules file: /lib/udev/rules.d/95-cd-devices.rules Reading rules file: /lib/udev/rules.d/95-dm-notify.rules Reading rules file: /lib/udev/rules.d/95-upower-hid.rules Reading rules file: /lib/udev/rules.d/95-upower-wup.rules Reading rules file: /lib/udev/rules.d/96-e2scrub.rules Reading rules file: /lib/udev/rules.d/99-fuse.rules Reading rules file: /etc/udev/rules.d/wooting.rules eth0: /lib/udev/rules.d/75-net-description.rules:6 Importing properties from results of builtin command 'net_id' eth0: MAC address identifier: hw_addr=a8:a1:59:16:66:a6 → xa8a1591666a6 sd-device: Failed to chase symlinks in "/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:07.0/0000:08:00.0/physfn". eth0: Parsing slot information from PCI device sysname "0000:08:00.0": success eth0: dev_port=0 eth0: PCI path identifier: domain=0 bus=8 slot=0 func=0 phys_port= dev_port=0 → p8s0 eth0: /lib/udev/rules.d/75-net-description.rules:12 Importing properties from results of builtin command 'hwdb --subsystem=pci' eth0: hwdb modalias key: "pci:v000010ECd00008168sv00001849sd00008168bc02sc00i00" eth0: /lib/udev/rules.d/80-net-setup-link.rules:5 Importing properties from results of builtin command 'path_id' eth0: /lib/udev/rules.d/80-net-setup-link.rules:9 Importing properties from results of builtin command 'net_setup_link' eth0: Failed to query name_assign_type: Invalid argument eth0: Failed to get "name_assign_type" attribute, ignoring: Invalid argument eth0: Device has addr_assign_type=0 eth0: Config file /lib/systemd/network/99-default.link is applied eth0: MAC address on the device already matches policy "persistent". eth0: Policy *path* yields "enp8s0". eth0: /lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'enp8s0' eth0: sd-device: Created db file '/run/udev/data/n2' for '/devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:07.0/0000:08:00.0/net/eth0' enp8s0: Network interface 2 is renamed from 'eth0' to 'enp8s0' enp8s0: sd-device: Created db file '/run/udev/data/n2' for '/devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:07.0/0000:08:00.0/net/enp8s0' DEVPATH=/devices/pci0000:00/0000:00:01.3/0000:01:00.2/0000:02:07.0/0000:08:00.0/net/enp8s0 INTERFACE=enp8s0 IFINDEX=2 ACTION=add SUBSYSTEM=net ID_NET_NAMING_SCHEME=v251 ID_NET_NAME_MAC=enxa8a1591666a6 ID_OUI_FROM_DATABASE=ASRock Incorporation ID_NET_NAME_PATH=enp8s0 ID_BUS=pci ID_VENDOR_ID=0x10ec ID_MODEL_ID=0x8168 ID_PCI_CLASS_FROM_DATABASE=Network controller ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd. ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Motherboard (one of many)) ID_PATH=pci-0000:08:00.0 ID_PATH_TAG=pci-0000_08_00_0 ID_NET_DRIVER=r8169 ID_NET_LINK_FILE=/lib/systemd/network/99-default.link ID_NET_NAME=enp8s0 ID_RENAMING=1 INTERFACE_OLD=eth0 USEC_INITIALIZED=143927767 Unload module index Unloaded link configuration context. I ran command with interface device named eth0, because that's the default before renaming device.
> ID_NET_NAME=enp8s0 > ID_RENAMING=1 This tells me that udev wants to rename your network interface to enp8s0. If it fails to do that, it is probably because the network interface is being brought up before udev gets a chance to rename the interface. To test that udev is working properly, you could do the following: 1. Stop any dhcp clients (if any) that are running. 2. Bring the interface down (ip link set eth0 down). 3. Run udevadm trigger --action=add /sys/class/net/eth0. 4. Check to see if udev renamed your interface. If this test works, it probably means that some program is taking control of your network interface before udev starts. You should review your startup logs to see if anything mentions eth0 before udev. It's also possible that something in your initramfs is configuring the interface. You should also check that the "udev-trigger" service is running on boot up.
I also have an issue where in tty I've got control of usb devices, but after running startx it's as if none of my usb devices are recognized anymore. And that issues doesn't occur when systemd-utils:250.7 is emerged instead of 251
(In reply to Mike Gilbert from comment #4) > > ID_NET_NAME=enp8s0 > > ID_RENAMING=1 > > This tells me that udev wants to rename your network interface to enp8s0. > > If it fails to do that, it is probably because the network interface is > being brought up before udev gets a chance to rename the interface. > > To test that udev is working properly, you could do the following: > > 1. Stop any dhcp clients (if any) that are running. Udev is ran before dhcpcd is started. > 2. Bring the interface down (ip link set eth0 down). The interface is down once I login into tty. > 3. Run udevadm trigger --action=add /sys/class/net/eth0. I'll try this > It's also possible that > something in your initramfs is configuring the interface. I don't have an initramfs. > You should also check that the "udev-trigger" service is running on boot up. I'll check this
(In reply to JustCauseWhyNot from comment #5) > I also have an issue where in tty I've got control of usb devices, but after > running startx it's as if none of my usb devices are recognized anymore. And > that issues doesn't occur when systemd-utils:250.7 is emerged instead of 251 That's likely to be some interaction with elogind. You should file a separate bug report for that.
> That's likely to be some interaction with elogind. You should file a > separate bug report for that. Should I file the bug report for systemd-utils, or elogind?
(In reply to JustCauseWhyNot from comment #8) > Should I file the bug report for systemd-utils, or elogind? Let's figure out your networking issue first. Maybe it will magically fix the other issue.
Ok after running doas udevadm trigger --action=add /sys/class/net/eth0 it renames to enp8s0 as intended. But when using btop to search my processes the only udev process running is systemd-udevd.
I suspect that either the udev-trigger service is not running on boot, or there is a race condition between it and the dhcpcd service. It's really hard for me to say more without observing the system boot myself.
(In reply to Mike Gilbert from comment #11) > I suspect that either the udev-trigger service is not running on boot, or > there is a race condition between it and the dhcpcd service. I can test with udev-trigger added to boot startup since it wasn't there already. > It's really hard for me to say more without observing the system boot myself. I's there anything I can provide like a boot log?
(In reply to JustCauseWhyNot from comment #12) > I can test with udev-trigger added to boot startup since it wasn't there > already. udev and udev-trigger should both be in the "sysinit" runlevel.
> udev and udev-trigger should both be in the "sysinit" runlevel. You're right both were there. And whatever is causing interface naming issues is also causing usb issues. When I remove dhcpcd, and any service that calls it in I'm able to then inconsistently reboot with proper interface name set & usb devices working. I say inconsistent because I seem to need to reboot a couple times for the effects of change to make a difference. It's odd, and something I don't really know how to explain. It seems to be more consistent when I shutdown vs reboot.
(In reply to JustCauseWhyNot from comment #14) > I say inconsistent because I seem to need to reboot a couple times for the > effects of change to make a difference. It's odd, and something I don't > really know how to explain. It seems to be more consistent when I shutdown > vs reboot. When I say reboot I'm running doas reboot, and when I shutdown I'm just pressing power button on front panel of my pc case.
To elaborate on rc-service oddity. I added to default runlevel dhcpcd, and unbound. Then I rebooted once, and ip a showed interface name was eht0. I then removed from default runlevel dhcpcd, and unbound & rebooted. My system showed the same interface name being eth0 same as when I had dhcpcd, and unbound started on boot despite them not being loaded. So then I shutdown pc with power button, and I had to hold it down for a second to forcefully shutdown since elogind wasn't working properly. After all that I boot up again and interface is now name enp8s0 instead of eth0. I than manually start dhcpcd, and unbound & both seem to be working properly. Weirdly on running startx on this session only my keyboard was loaded not mouse nor audio interface.
Actually I don't know anymore. Because I just shutdown my pc with pressing not holding down my power button, and on boot ip a showed enp8s0, but I ran startx and none of my usb devices worked so I had to re-plug them in. I then started dhcpcd, and unbound. That somehow caused enp8s0 to be named eth0, and dhcpcd gave error on start saying no valid interfaces found. So right now I don't know what the issue is.
Maybe try adding udev-settle to the sysinit runlevel as a workaround. It should be unnecessary, but you seem to be running into some kind of race condition here.
I added udev-settle to sysinit, and then I shutdown my pc. I than booted back up, and udev-settle failed to start after a 2 minute delay. I set a stop watch on my phone to time it. I was able to boot into tty login, but I failed entering my login credentials 3 times & got a 10 minute cooldown. So I shutdown, and restarted my pc again. This time I didn't see udev-settle even try to start on boot, and I logged in first time. But I was still having typical issues. I still have dhcpcd, and anything else that requires dhcpcd disabled on startup.
Here's ❯ doas rc-status --all Runlevel: boot termencoding [ started ] modules [ started ] fsck [ started ] root [ started ] mtab [ started ] swap [ started ] localmount [ started ] seedrng [ started ] sysctl [ started ] bootmisc [ started ] keymaps [ started ] save-keymaps [ started ] procfs [ started ] systemd-tmpfiles-setup [ started ] dbus [ started ] hostname [ started ] elogind [ started ] binfmt [ started ] save-termencoding [ started ] loopback [ started ] Runlevel: sysinit devfs [ started ] kmod-static-nodes [ started ] systemd-tmpfiles-setup-dev [ started ] sysfs [ started ] dmesg [ started ] cgroups [ started ] udev [ started ] udev-trigger [ started ] udev-settle [ started ] Runlevel: nonetwork local [ started ] Runlevel: shutdown killprocs [ stopped ] savecache [ stopped ] mount-ro [ stopped ] Runlevel: default rsyslog [ started ] local [ started ] Dynamic Runlevel: hotplugged Dynamic Runlevel: needed/wanted hwclock [ started ] dhcpcd [ started ] Dynamic Runlevel: manual unbound
I'd just like to say the problem persists when I updated to sys-apps/systemd-utils-251.3, but not when updating to sys-apps/systemd-utils-250.8.
One thing I've noticed upon retrying to use systemd-utils-251.3 is that udev is ran twice.
I recently did a oops, and deleted my root partition. I did a reinstall and I'm currently using version 251.4. It's all working correctly. I don't know why I had the original issue, but it was a user error.
I got the same issue, this is not resolved, can this be reopened to be investigated further? Now that systemd-utils-251.3 was marked as stable, I think there will be more people bumping into it, so we'd better get to the bottom of it. My system broke after a world upgrade, where systemd-utils package got upgraded from 250.7 to 251.3: https://forums.gentoo.org/viewtopic-p-8743696.html#8743696 Reverting to 250.7 fixed the problem. All >=251 ebuilds are now masked on this system. I use open-rc init system, I have no elogind as this is a server without a gui and I use only static NIC configurations, ie no DHCP. On the usb issue: I used to have an INSTALL_MASK like this: INSTALL_MASK="/etc/system.d /lib/systemd /lib64/systemd /usr/lib/systemd /usr/lib64/systemd <some non systemd related dirs>" When the system booted and openrc tried to start udevd, it could not find the binary, as I only had udevadm. Symlinking /sbin/udevd to /bin/udevadm fixed the issue and USB devices started to work fine.
(In reply to Nikolay Kichukov from comment #24) > I got the same issue, this is not resolved, can this be reopened to be > investigated further? > > Now that systemd-utils-251.3 was marked as stable, I think there will be > more people bumping into it, so we'd better get to the bottom of it. > > My system broke after a world upgrade, where systemd-utils package got > upgraded from 250.7 to 251.3: > https://forums.gentoo.org/viewtopic-p-8743696.html#8743696 > > Reverting to 250.7 fixed the problem. All >=251 ebuilds are now masked on > this system. > > I use open-rc init system, I have no elogind as this is a server without a > gui and I use only static NIC configurations, ie no DHCP. > > On the usb issue: I used to have an INSTALL_MASK like this: > INSTALL_MASK="/etc/system.d /lib/systemd /lib64/systemd /usr/lib/systemd > /usr/lib64/systemd <some non systemd related dirs>" > > When the system booted and openrc tried to start udevd, it could not find > the binary, as I only had udevadm. Symlinking /sbin/udevd to /bin/udevadm > fixed the issue and USB devices started to work fine. The news item mentions not having an INSTALL_MASK like that though. That's PEBKAC and user-caused. If the only issue you had was caused by that, then there's nothing for us to do?
(Of course, you can still mask unit files if you wish, but those directories there are bound to cause issues.)
The news item does not mention removing existing user-defined install masks for systemd. I did rebuild the new package without the INSTALL_MASK and I got the same defect. For me, this needs more investigation. I do run the new systemd-utils package on other systems and they do not have this problem, so perhaps this is some corner case and maybe worth looking into deeper.
(In reply to Nikolay Kichukov from comment #27) > The news item does not mention removing existing user-defined install masks > for systemd. > > I did rebuild the new package without the INSTALL_MASK and I got the same > defect. Oh, I see, it's in the udev news item instead, which was a while earlier: https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html.
(In reply to Nikolay Kichukov from comment #27) > For me, this needs more investigation. I do run the new systemd-utils > package on other systems and they do not have this problem, so perhaps this > is some corner case and maybe worth looking into deeper. Without access to the affected system, there is nothing for us to investigate. Please let us know if you manage to figure it out.
