Timed out for waiting the udev queue being empty on pacman update

thebrownmamba · 2024-11-16 06:09:27

So I just performed an update with pacman -Syu, and while pacman is running post transaction hooks, I get an error:

( 8/14) Reloading device manager configuration...
Timed out for waiting the udev queue being empty.
error: command failed to execute correctly

It then proceeds to continue normally and it seems to be working fine. The system still works but I haven't rebooted yet. Is this something that I should worry about? I feel like it is but I don't know how to troubleshoot it. journalctl doesn't show up anything useful when I use

journalctl | grep "udev"

Nov 16 12:45:21 <hostname> systemd[1]: Listening on udev Control Socket.

Nov 16 12:45:21 <hostname> systemd[1]: Listening on udev Kernel Socket.

Nov 16 12:45:21 <hostname> systemd[1]: Starting Load udev Rules from Credentials...

Nov 16 12:45:21 <hostname> systemd[1]: Starting Coldplug All udev Devices...

Nov 16 12:45:21 <hostname> systemd[1]: Finished Load udev Rules from Credentials.

Nov 16 12:45:21 <hostname> systemd[1]: Finished Coldplug All udev Devices.

Nov 16 12:45:20 <hostname> systemd-udevd[448]: Using default interface naming scheme 'v255'.

Nov 16 12:45:22 <hostname> iwd[669]: udev interface=wlan0 ifindex=4

Nov 16 12:45:22 <hostname> iwd[669]: udev interface=virbr0 ifindex=5

Nov 16 12:46:21 <hostname> systemd-udevd[448]: sr0: Worker [459] processing SEQNUM=5114 is taking a long time

Nov 16 12:48:10 <hostname> (udev-worker)[459]: sr0: Spawned process 'cdrom_id --lock-media /dev/sr0' [4506] is taking longer than 5s to complete.

Nov 16 12:48:21 <hostname> (udev-worker)[459]: sr0: Spawned process 'cdrom_id --lock-media /dev/sr0' [4506] timed out after 15s, killing.

Nov 16 12:48:31 <hostname> systemd-udevd[448]: sr0: Worker [459] processing SEQNUM=5114 killed

Nov 16 12:48:31 <hostname> systemd-udevd[448]: sr0: Worker [459] terminated by signal 9 (KILL).

Nov 16 12:49:32 <hostname> systemd-udevd[448]: sr0: Worker [3690] processing SEQNUM=5118 is taking a long time

Nov 16 12:51:17 <hostname> (udev-worker)[3690]: sr0: Spawned process 'cdrom_id --lock-media /dev/sr0' [37937] is taking longer than 7s to complete.

Nov 16 12:51:32 <hostname> (udev-worker)[3690]: sr0: Spawned process 'cdrom_id --lock-media /dev/sr0' [37937] timed out after 22s, killing.

Nov 16 12:51:42 <hostname> systemd-udevd[448]: sr0: Worker [3690] processing SEQNUM=5118 killed

Nov 16 12:54:01 <hostname> systemd-udevd[448]: sr0: Worker [3690] terminated by signal 9 (KILL).

Nov 16 12:55:01 <hostname> systemd-udevd[448]: sr0: Worker [41913] processing SEQNUM=5688 is taking a long time

Nov 16 12:57:11 <hostname> systemd-udevd[448]: sr0: Worker [41913] processing SEQNUM=5688 killed

Nov 16 12:58:16 <hostname> systemd-udevd[448]: sr0: Worker [41913] terminated by signal 9 (KILL).

Nov 16 12:59:16 <hostname> systemd-udevd[448]: sr0: Worker [41916] processing SEQNUM=7068 is taking a long time

seth · 2024-11-16 08:31:39

There're some timeouts regarding your optical device (cd/dvd/br)
Do they co-incide w/ the alpm hook timeout?
The offending rule would be /lib/udev/rules.d/60-cdrom_id.rules - is there a bogus disc in the drive?

thebrownmamba · 2024-11-16 09:06:33

I don't have the alpm hook active, and I don't have a physical optical drive either. I do have a QEMU KVM setup that probably has a virtualized optical drive, maybe it's from the virtualization service I have enabled?

seth · 2024-11-16 09:11:46

I don't have the alpm hook active

stat /usr/share/libalpm/scripts/systemd-hook /etc/systemd/do-not-udevadm-trigger-on-update

https://bugs.archlinux.org/task/77789

I don't have a physical optical drive either

stat /dev/sr0

thebrownmamba · 2024-11-16 09:21:41

stat /usr/share/libalpm/scripts/systemd-hook /etc/systemd/do-not-udevadm-trigger-on-update

  File: /usr/share/libalpm/scripts/systemd-hook
  Size: 1503      	Blocks: 8          IO Block: 4096   regular file
Device: 0,29	Inode: 1028562     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-11-16 12:46:33.248807592 +0700
Modify: 2024-11-15 02:49:49.000000000 +0700
Change: 2024-11-16 12:46:30.475474340 +0700
 Birth: 2024-11-16 12:46:30.475474340 +0700
stat: cannot statx '/etc/systemd/do-not-udevadm-trigger-on-update': No such file or directory

Does this mean I actually have the alpm hook active? I have no idea lol I said I don't have the alpm hook active because I don't see an alpm entry in the HOOKS array in /etc/mkinitcpio.conf

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck)

stat /dev/sr0

  File: /dev/sr0
  Size: 0         	Blocks: 0          IO Block: 4096   block special file
Device: 0,6	Inode: 1037        Links: 1     Device type: 11,0
Access: (0600/brw-------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-11-16 12:45:22.146666525 +0700
Modify: 2024-11-16 12:45:22.146666525 +0700
Change: 2024-11-16 12:45:22.146666525 +0700
 Birth: 2024-11-16 12:45:22.146666525 +0700

I have no idea how to read that, but I'm pretty positive I don't have a physical optical drive as I built this PC myself.

seth · 2024-11-16 09:27:40

I don't see an alpm entry in the HOOKS array in /etc/mkinitcpio.conf

That's completely unrelated and irrelevant. The hook exists and isn't muted by /etc/systemd/do-not-udevadm-trigger-on-update (you can "sudo touch" that file to inert the hook)

Physical or not, there's some sr0 which is typically an ATAPI drive.
Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

thebrownmamba · 2024-11-16 09:29:30

Ahh I see.
https://0x0.st/XdzZ.txt

seth · 2024-11-16 09:45:59

Nov 16 12:45:22 majesta kernel: scsi 8:0:0:0: CD-ROM            Realtek  Driver Storage   1.00 PQ: 0 ANSI: 0 CCS
Nov 16 12:45:22 majesta kernel: scsi 8:0:0:0: Attached scsi generic sg2 type 5
Nov 16 12:45:22 majesta kernel: sr 8:0:0:0: [sr0] scsi3-mmc drive: 0x/0x caddy
Nov 16 12:45:22 majesta kernel: sr 8:0:0:0: Attached scsi CD-ROM sr0

Seems to be

Nov 16 12:45:21 majesta kernel: usb 1-6: new high-speed USB device number 5 using xhci_hcd
Nov 16 12:45:21 majesta kernel: usb 1-6: New USB device found, idVendor=0bda, idProduct=1a2b, bcdDevice= 2.00
Nov 16 12:45:21 majesta kernel: usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 16 12:45:21 majesta kernel: usb 1-6: Product: DISK
Nov 16 12:45:21 majesta kernel: usb 1-6: Manufacturer: Realtek

which would be a wifi dongle that need to be moved out of the "install windows drivers" mode, https://archlinux.org/packages/extra/x8 … odeswitch/

thebrownmamba · 2024-11-16 09:57:51

I see, I do have a wifi dongle that I always leave connected. So just to be sure, to rectify this issue I need to use the usb_modeswitch to switch the dongle mode to USB modem? Are there any other additional steps I need to do after that?

Also, alternatively, can I just plug out the dongle instead? As I understand it this issue occurs when the dongle is plugged at boot. Can I just make sure that I don't have the dongle plugged in at boot?

seth · 2024-11-16 14:44:41

As I understand it this issue occurs when the dongle is plugged at boot.

Does it otherwise entter the correct mode right away?
But yes, you'll have to mode-switch it and you can actually create a udev rule (if the modeswitch package doesn't cover the device anyway) for that.

Why is the dongle there itfp?
You don't seem to be needing it and have wlan via an iwlwifi NIC?

thebrownmamba · 2024-11-18 04:52:58

I do experience issues on boot where a blank screen with a single _ on it will show up for up to 30 seconds before the Mobo logo screen pops up, which is to say that this is an extremely and unusually long boot time. Without the dongle the screen doesn't appear anymore and the system boots as normal. I thought it was a hardware degradation issue because this screen and apparent freeze shows up before the Mobo logo screen (BIOS/UEFI logo screen or whatever you call it) so I didn't even think any OS had an effect on it. Another issue that I experienced that in hindsight is caused by the dongle was that PulseAudio on startup would start way longer than usual. Once I boot into my system and open pavucontrol, it would be stuck on "establishing connection to pulseaudio". In hindsight this is most likely caused by the udev being held up by the dongle.

The dongle is there because my motherboard have an on board wifi module on it, but it's one of those modules that you need to set up an antenna that sticks out of the back of the computer and you need to set up the wires for it. I got lazy and figured that since I'm going to use ethernet 100% of the time anyway I didn't even bother setting it up. The module itself technically works but the signal detection is so terrible that it's 100% unusable. Turns out you still need wifi every now and then so I bought a dongle, and I just stick it in there perpetually for convenience.

seth · 2024-11-18 07:26:57

apparent freeze shows up before the Mobo logo screen (BIOS/UEFI logo screen or whatever you call it) so I didn't even think any OS had an effect on it

It probably doesn't - it the dongle is bogus in any way shape or form the UEFI might stall probing it to see whether it's a bootable device.

I just stick it in there perpetually for convenience.

But when you re/plug it there at runtime it generally behaves?
Have you tried another usb port?

thebrownmamba · 2024-11-18 07:31:07

But when you re/plug it there at runtime it generally behaves?

If by behaving you mean it works, it works perfectly fine at runtime. Quite literally plug and play. I have used different USB ports when the system is active, but I haven't tried booting with the dongle on a different port.

Arch Linux

#1 2024-11-16 06:09:27

Timed out for waiting the udev queue being empty on pacman update

#2 2024-11-16 08:31:39

Re: Timed out for waiting the udev queue being empty on pacman update

#3 2024-11-16 09:06:33

Re: Timed out for waiting the udev queue being empty on pacman update

#4 2024-11-16 09:11:46

Re: Timed out for waiting the udev queue being empty on pacman update

#5 2024-11-16 09:21:41

Re: Timed out for waiting the udev queue being empty on pacman update

#6 2024-11-16 09:27:40

Re: Timed out for waiting the udev queue being empty on pacman update

#7 2024-11-16 09:29:30

Re: Timed out for waiting the udev queue being empty on pacman update

#8 2024-11-16 09:45:59

Re: Timed out for waiting the udev queue being empty on pacman update

#9 2024-11-16 09:57:51

Re: Timed out for waiting the udev queue being empty on pacman update

#10 2024-11-16 14:44:41

Re: Timed out for waiting the udev queue being empty on pacman update

#11 2024-11-18 04:52:58

Re: Timed out for waiting the udev queue being empty on pacman update

#12 2024-11-18 07:26:57

Re: Timed out for waiting the udev queue being empty on pacman update

#13 2024-11-18 07:31:07

Re: Timed out for waiting the udev queue being empty on pacman update

Board footer