1

I am running Parabola Linux (libre fork of Arch) on a laptop with an nvme SSD. I ran a full system update yesterday and since then I have been getting the following error on boot:

Image of initramfs error.

It appears to be an initramfs issue: it seems to not be able to find the root partition by UUID. I have checked lsblk and verified that the UUID is correct. I have also tried going in with an arch-chroot and re-running mkinitcpio, but still get the same error. I have also checked the initram image with lsinitcpio, to verify that it includes the nvme modules (it does). The fallback initramfs image seems to give the same error. The keyboard also doesn't work in the rootfs prompt, which suggests the issue is due to modules not being loaded correctly.

Does anyone have any idea what the issue might be here and how to resolve it?

Neither grub.cfg nor /etc/fstab were touched during the system update, so I am at a complete loss as to what may have happened here.

Update:

I made a custom initcpio hook to try to debug the issue, as suggested by frostschutz in the comments. This shows the output of several other commands during boot:

Boot output with custom initcpio hook.

It seems fairly conclusive from this that udev is not doing it's job and is not loading any kernel modules during the initcpio phase. The modules loaded in the initramfs are the correct version for the kernel, as evidenced by the fact that a couple have been loaded (which I explicitly requested in mkinitcpio.conf).

Does anyone have any idea why udev is now suddenly not working, following the system update? I believe some changes were made to udev during the update (I think it changed to a different udev package?).

Improve this question
13
  • 1
    In the initramfs shell, cat /proc/partitions (storage detected at all?), ls -l /dev/disk/by-uuid/ (which uuid present?), cat /proc/cmdline (kernel parameters as expected?), lsmod (modules loaded?). If no modules loaded, uname -a vs ls /lib/modules, do kernel versions match? Commented Feb 15 at 12:15
  • @frostschutz the keyboard actually doesn't seem to work in the rootfs shell. That actually might be important and I will add it to the question. Maybe there is some underlying issue with udev? Commented Feb 15 at 12:26
  • 1
    You could add a custom hook that runs the debug commands suggested above. Or just make a simple change, e.g. remove keymap from HOOKS, re-run mkinitcpio and see if the message running hook [keymap] goes away. That's one quick way to check if you're booting the right file at all. If it stays, you're loading some wrong/old initramfs file somehow Commented Feb 15 at 12:38
  • 2
    Perhaps nvme module is missing? Try modprobe nvme if it shows any error? (From outside you could perhaps use lsinitcpio for a full list of included files.) Commented Feb 15 at 20:53
  • 1
    You might be able to add --debug options to /usr/lib/initcpio/hooks/udev. But unless you broke it yourself with some custom rules or configs, I'm afraid I can't help much in this area, or it might be a problem with your distro. If you can make it boot by loading some modules, go with that for now. If there is an error when loading modules, that might be interesting too. Good luck Commented Feb 15 at 21:34

1 Answer 1

Reset to default
0

I'm posting this as an answer, since it did work and allow me to boot:

I simply added nvme to the list of modules that are explicitly loaded in mkinitcpio.conf. That seemed to load the nvme module and allowed the system to find the root partition, and from there the system seemed to boot more-or-less normally.

However, this seems like a bit of a dirty fix. It would be great to figure out what is causing udev to not load any modules at all during the initcpio phase, after the system update.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.