Post History
Early in boot, after triggering uevents but before the encrypt hook (decrypting drives) my system takes a very long time, over a minute. Actually, I bet it takes 90 seconds which is the typical def...
#3: Post edited
by
matthewsnyder
·
2024-06-14T23:40:45Z (5 months ago)
- Early in boot, after `triggering uevents` but before the encrypt hook (decrypting drives) my system takes a very long time, over a minute. Actually, I bet it takes 90 seconds which is the typical default for how long systemd will wait on something before timing out.
- I get no error message, just a delay. After the encrypt hook everything runs normally.
- I think this must be the initramfs because my actual drive is not unlocked at that point. In `/etc/mkinitcpio.conf` I have:
- ```
- HOOKS=(base udev keyboard autodetect modconf block encrypt lvm2 filesystems resume fsck)
- ```
- This used to not be a problem, but began 1 months ago or so after an update. I am on Arch with 6.6.32-1-lts kernel.
What's the problem? How do I troubleshoot it?
- Early in boot, after `triggering uevents` but before the encrypt hook (decrypting drives) my system takes a very long time, over a minute. Actually, I bet it takes 90 seconds which is the typical default for how long systemd will wait on something before timing out.
- I get no error message, just a delay. After the encrypt hook everything runs normally.
- I think this must be the initramfs because my actual drive is not unlocked at that point. In `/etc/mkinitcpio.conf` I have:
- ```
- HOOKS=(base udev keyboard autodetect modconf block encrypt lvm2 filesystems resume fsck)
- ```
- This used to not be a problem, but began 1 months ago or so after an update. I am on Arch with 6.6.32-1-lts kernel.
- What's the problem? How do I troubleshoot it?
- ---------
- Additional troubleshooting information will be added below.
- ```
- $ systemd-analyze time
- Startup finished in 2min 23.672s (kernel) + 17.010s (userspace) = 2min 40.683s
- graphical.target reached after 17.010s in userspace.
- ```
- But in `systemd-analyze blame` output the top one is just 8sec for the network, so it does not appear to look at the kernel.
#2: Post edited
by
matthewsnyder
·
2024-06-14T23:35:47Z (5 months ago)
- Early in boot, after `triggering uevents` but before the encrypt hook (decrypting drives) my system takes a very long time, over a minute. Actually, I bet it takes 90 seconds which is the typical default for how long systemd will wait on something before timing out.
- I get no error message, just a delay. After the encrypt hook everything runs normally.
I think this must be the initramfs because my actual drive is not unlocked at that point.This used to not be a problem, but began 1 months ago or so after an update.- What's the problem? How do I troubleshoot it?
- Early in boot, after `triggering uevents` but before the encrypt hook (decrypting drives) my system takes a very long time, over a minute. Actually, I bet it takes 90 seconds which is the typical default for how long systemd will wait on something before timing out.
- I get no error message, just a delay. After the encrypt hook everything runs normally.
- I think this must be the initramfs because my actual drive is not unlocked at that point. In `/etc/mkinitcpio.conf` I have:
- ```
- HOOKS=(base udev keyboard autodetect modconf block encrypt lvm2 filesystems resume fsck)
- ```
- This used to not be a problem, but began 1 months ago or so after an update. I am on Arch with 6.6.32-1-lts kernel.
- What's the problem? How do I troubleshoot it?
#1: Initial revision
by
matthewsnyder
·
2024-06-14T23:33:43Z (5 months ago)
Initramfs: "triggering uevents" suddenly takes a really long time
Early in boot, after `triggering uevents` but before the encrypt hook (decrypting drives) my system takes a very long time, over a minute. Actually, I bet it takes 90 seconds which is the typical default for how long systemd will wait on something before timing out. I get no error message, just a delay. After the encrypt hook everything runs normally. I think this must be the initramfs because my actual drive is not unlocked at that point. This used to not be a problem, but began 1 months ago or so after an update. What's the problem? How do I troubleshoot it?