Hi,
I am revisiting this issue because the other related topics are closed for new comments and I don’t know if I am allowed to comment in English in the still-open German topic. I am hoping that my findings presented here would be of use to people who are capable of fixing this issue.
The initramfs was not created correctly
Like a lot of other users, my system fails to boot after a system upgrade on 27 July. The initqueue hook keeps searching for the root device inside /dev/disk/by-uuid/. But when I looked at /dev/disk/ inside the emergency / maintenance shell, I can see only by-diskseq/, by-id/, and by-path/, all of which contain only symlinks to /dev/sr0, the CDROM drive. Also, the USB memory stick is only listed as /dev/bus/usb/002/002; there is nothing inside /dev/block/ that is associated with the memory stick. Hence I was unable to mount the USB stick to save any runtime data such as /run/initramfs/rdsosreport.txt or /proc/*/*or the /dev/ and /sys/ trees, etc.
The reason that the system could not list the root device or USB stick is that the initramfs is missing a lot of nuts and bolts:
[liveuser@eos-2026.04.27 ~]$ sudo lsinitrd --verbose /mnt/efi/ac4f7b94238e4b1c87e45b5e2ea1908f/6.18.41-1-lts/initrd | eos-sendlog
https://dpaste.com/GZ9DFJJC8
The early CPIO image does not contain any kernel modules (drivers). Even the kernel/x86/microcode/GenuineIntel.bin doesn’t seem to be correct judging by its file size.
I don’t know enough to modify the dracut configuration files to ensure the necessary drivers are added. Some users like @71387 are lucky with their modifications while others like @SdW weren’t so lucky as they described in A start job is running for /dev/disk/ running for 5min+.
One second before the nightmare
Here is the system upgrade that broke my system:
[liveuser@eos-2026.04.27 ~]$ grep --colour=never '^\[2026-07-27T16' /mnt/var/log/pacman.log | eos-sendlog
https://dpaste.com/FAM5GRCAL
Is it possible that one or more of the updated packages (such as glibc, libgcc, libasan or even binutils) caused dracut-111 to create a corrupted initramfs? Maybe we need a statically-linked dracut to reduce sensitivity to other packages.
By the way, I ran 2 more system upgrades after this by running
[liveuser@eos-2026.04.27 ~]$ sudo arch-chroot /mnt
[root@EndeavourOS /]# pacman -Syuv
[root@EndeavourOS /]# reinstall-kernels
Here is the 2nd system upgrade. There was a fatal error, but that happened after reinstall-kernels.
[liveuser@eos-2026.04.27 ~]$ grep --colour=never '\[2026-07-29T14' /mnt/var/log/pacman.log | eos-sendlog
https://dpaste.com/DULM5WK4H
Here is the 3rd system upgrade. Some hooks were skipped and the (same?) fatal error after reinstall-kernels.
[liveuser@eos-2026.04.27 ~]$ grep '\[2026-07-31T17' /mnt/var/log/pacman.log | eos-sendlog
https://dpaste.com/243FSNS6W
Unfortunately, both upgrades did not fix the initqueue looping problem.
dracut and systemd (and linux-lts) packages corrupted?
Is it possible that a corrupted initramfs was created because these packages are corrupted? Missing dracut and systemd scripts or missing kernel modules.
[liveuser@eos-2026.04.27 ~]$ pacman --sysroot /mnt -Ss systemd | eos-sendlog
https://dpaste.com/8ZU2HUBKX
[liveuser@eos-2026.04.27 ~]$ pacman --sysroot /mnt -Ss dracut | eos-sendlog
https://dpaste.com/9LR7VW7M8
The packages are ok, except for one altered file in the systemd package. Is there a pacman flag to find that filename and the modification that was made?
[liveuser@eos-2026.04.27 ~]$ pacman --sysroot /mnt --query --check --check \
kernel-install-for-dracut systemd systemd-libs systemd-resolvconf systemd-sysvcompat \
lib32-systemd dracut linux-lts linux-lts-headers |& eos-sendlog
https://dpaste.com/AC7GWEGDS
I thought of another angle, the dates when the packages were upgraded:
[liveuser@eos-2026.04.27 ~]$ grep kernel-install-for-dracut /mnt/var/log/pacman.log | grep 1.14.2-1
[2026-01-17T10:20:22+0800] [ALPM] upgraded kernel-install-for-dracut (1.14.1-2 -> 1.14.2-1)
[liveuser@eos-2026.04.27 ~]$ grep dracut /mnt/var/log/pacman.log | grep 111_eos-1
[2026-05-29T10:56:31+0800] [ALPM] upgraded dracut (109_eos-1 -> 111_eos-1)
[liveuser@eos-2026.04.27 ~]$ grep systemd /mnt/var/log/pacman.log | grep 261.2-1
[2026-07-25T10:01:17+0800] [ALPM] upgraded systemd-libs (261.1-1 -> 261.2-1)
[2026-07-25T10:01:18+0800] [ALPM] upgraded systemd (261.1-1 -> 261.2-1)
[2026-07-25T10:01:23+0800] [ALPM] upgraded lib32-systemd (261.1-1 -> 261.2-1)
[2026-07-25T10:01:23+0800] [ALPM] upgraded systemd-resolvconf (261.1-1 -> 261.2-1)
[2026-07-25T10:01:23+0800] [ALPM] upgraded systemd-sysvcompat (261.1-1 -> 261.2-1)
[liveuser@eos-2026.04.27 ~]$ grep linux-lts /mnt/var/log/pacman.log | grep 6.18.40-1
[2026-07-26T11:05:52+0800] [ALPM] upgraded linux-lts (6.18.39-1 -> 6.18.40-1)
[2026-07-26T11:05:55+0800] [ALPM] upgraded linux-lts-headers (6.18.39-1 -> 6.18.40-1)
[2026-07-27T16:38:32+0800] [ALPM] upgraded linux-lts (6.18.40-1 -> 6.18.40-2)
[2026-07-27T16:38:35+0800] [ALPM] upgraded linux-lts-headers (6.18.40-1 -> 6.18.40-2)
The dracut and systemd were upgraded before 26 July 2026. linux-lts-6.18.40-1 boots up successfully. This means dracut-111 and systemd-261.2-1 were able to create a working initramfs when linux-lts was upgraded from 6.18.39-1 to 6.18.40-1 but build a corrupted initramfs when upgrading to 6.18.40-2 and later.
I stop here because I run out of ideas.