You are not logged in.
Pages: 1
Since yesterday I am having a bunch of problems which I managed to solve except one. When I boot, the screen "hangs" for about 30 seconds on "Triggering uevents..." after that it loads fine.
The only instances about this I can find on the internet are about nvidia (adding nomodeset to the kernel params) but I have an AMD gpu, besides, it never did this before.
I also tried to downgrade the kernel (as it happened after a kernel update) but that didn't help either. I also did a loglevel=7 boot (https://0x0.st/8KdM.log), but apparently the logs only start after this event? As there is no mention of this anywhere.
Thing is, I do not know what the system is supposed to be doing at that point, so it is difficult to pinpoint where to look for a solution. I get this is probably part if udev but how do I pinpoint when, where and how?
Offline
I get this is probably part if udev but how do I pinpoint when, where and how?
Try to set in /etc/udev/udev.conf:
udev_log=debug
and reboot. Then check journal with
journalctl -b -u systemd-udevd
Offline
Check man udevadm for query and info options on which events/devices are at play.
Offline
Try to set in /etc/udev/udev.conf:
udev_log=debug
and reboot. Then check journal with
journalctl -b -u systemd-udevd
Did this. I will post the full log tomorrow if needed. I am about to go to bed and writing this from my phone. I looked at the log and there is one point that takes 5 minutes (I said 30 seconds in my OP but it seems to take longer each time)
The line that takes this long reads: "cleaning idle workers" and happens almost at the end.
Thanks sofar and goodnight.
Offline
SO, I tried again today and the time it was stuck on "triggering uevents' was shorter again, but still around 20 seconds I am guessing. So it seems inconsistent.
This is the log from yesterday (5 minutes) : https://0x0.st/8PK9.log
And this is the log from today: https://0x0.st/8PK_.txt
I am not seeing anything out of the ordinary, but I might be wrong. If anyone can glance over it for me, please?
Offline
What device corresponds to "0:74"? Is that a PCID? It's consistently the last one that activates after a long delay in both boot sequences. Does `udevadm info -t` provide anything that you can relate back to "0:74"?
Feb 05 18:19:15 arch systemd-udevd[452]: Cleanup idle workers
Feb 05 18:24:00 arch systemd-udevd[452]: 0:74: Device is queued (SEQNUM=5175, ACTION=add)
Feb 05 18:24:00 arch systemd-udevd[452]: 0:74: Device ready for processing (SEQNUM=5175, ACTION=add)
Feb 05 18:24:00 arch systemd-udevd[452]: Successfully forked off '(udev-worker)' as PID 1053.
Offline
SO, I tried again today and the time it was stuck on "triggering uevents' was shorter again, but still around 20 seconds I am guessing.
It stuck in initramfs, right? "Triggering uevents..." likely is printed by udev initcpio hook. What is in /etc/mkinitcpio.conf and any files in /etc/mkinitcpio.conf.d/*?
Offline
Thank you both for the replies and trying to help. During the day the problems increased as at some point sound stopped working and there were extensive lag spikes. I dtarted to duspect a hardware problem so I tried a live usb which worked fine. As I need this pc to work I needed a solution quick. I had an ssd lying around with windows on it so I stuck that in and for now I can work. I guess I'll just reinstall Arch clean next week. Again thanks for your time.
Offline
Pages: 1