FS#54655 - [mkinitcpio-busybox] Boot failure after upgrade to 1.26.1
Attached to Project:
Arch Linux
Opened by Dario Giovannetti (kynikos) - Saturday, 01 July 2017, 07:31 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 26 October 2017, 03:11 GMT
Opened by Dario Giovannetti (kynikos) - Saturday, 01 July 2017, 07:31 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 26 October 2017, 03:11 GMT
|
Details
Today I upgraded the system on a laptop (an old Acer
1810TZ), and among the changes there was
'mkinitcpio-busybox' 1.25.1-2 -> 1.26.1-1 (x86_64).
After performing the upgrade, which automatically triggers the initramfs image regeneration, the system doesn't boot anymore, this is what is displayed after the boot loader stage: starting version 232 ERROR: resume: hibernation device '/dev/mapper/grp-swap' not found ERROR: device '/dev/mapper/grp-root' not found. Skipping fsck. mount: you must specify the filesystem type You are now being dropped into an emergency shell. sh: can't access tty; job control turned off [rootfs ]# If I downgrade mkinitcpio-busybox back to 1.25.1-2 and recreate the image, the system boots again normally. I have performed the same package update on other machines successfully, only on this laptop it generates this problem. Other package versions: linux 4.11.7-1 mkinitcpio 23-1 systemd 232-8 |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Thursday, 26 October 2017, 03:11 GMT
Reason for closing: Fixed
Additional comments about closing: mkinitcpio-busybox 1.27.2-1 seems to have fixed this
Thursday, 26 October 2017, 03:11 GMT
Reason for closing: Fixed
Additional comments about closing: mkinitcpio-busybox 1.27.2-1 seems to have fixed this
I have the same package versions as you.
I'm using LUKS with LVM, so the workaround to getting the system to boot so that you can downgrade the package is the following:
- Use `blkid` to find the LUKS volume containing the real root.
- `cryptsetup luksOpen $luksvolume luks` will prompt for the password.
- `mount $lvmroot /new_root` will mount the real root in the proper place
- Use CTRL-d to exit the recovery shell and booting will continue normally.
HOOKS="base udev autodetect modconf block keymap encrypt lvm2 resume filesystems keyboard fsck shutdown"
@kynikos Is it the same case for you? Can you confirm that in the emergency shell, you can see your disks (/dev/sd*) but no mapper at all (i.e. not even /dev/dm-0)? If so can you also paste your /proc/cmdline?
P.S. I also use the encrypt hook for my LUKS-encrypted root partition as well but I cannot reproduce your issue. I am not using LVM but that doesn't seem relevant to me (for it's LVM on LUKS).
*EDIT*: wrong guess. I just set the resume device, and the laptop boots.
cryptdevice
cryptdev
resolved
lsblk -f
sda
`-sda1 crypto_LUKS <UUID>
cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz root=UUID=<uuid> rw cryptdevice=UUID=<uuid>:root cryptkey=rootfs:/path/to/key resume=UUID=<uuid> quiet
My speculation is resolve_device() somehow failed with some corner cases. That's why I asked for the three variables, which might reveal how/when it failed. With cases like this it would be more helpful if you can provide your exact UUIDs so that others might test with them and see if they can reproduce the issue.
My lsblk is also:
sda
`-sda1 crypto_LUKS
I confirm I get stuck at the encrypt hook too, I don't see any mapped devices in the emergency console either, including any /dev/dm-#.
My /proc/cmdline is:
BOOT_IMAGE=/vmlinuz-linux root=/dev/mapper/grp-root rw cryptdevice=/dev/sda1:lvm cryptkey=rootfs:/boot/root_keyfile resume=/dev/mapper/grp-swap quiet
Note that I don't use UUIDs there.
In the emergency shell, only 'cryptdevice' is set for me, I don't see any 'cryptdev' or 'resolved' variables.
One thing that I see is that ralessi and I are both using a root keyfile, in my case it's because I'm using GRUB cryptodisk, to avoid having to type the passphrase twice, if it matters.
init.log.fail-full-boot (9 KiB)
init.log.ok (6.5 KiB)
Otherwise, I have the same settings as @kynikos. It may be worth mentioning that I haven't used UUIDs on my second laptop which boots fine.
Also it doesn't tell why the `read` to split cryptdevice= fail anyway, especially when the variable itself seems fine either case.
In any case, if removing cryptkey= from the cmdline helps, you can consider moving the keyfile to the fallback path /crypto_keyfile.bin instead. It should save you from entering the paraphrase twice.
> BOOT_IMAGE=/vmlinuz-linux root=/dev/mapper/internal-root rw cryptdevice=UUID=4571e505-026c-4012-bd64-a08c0929142d:lvm cryptkey=rootfs:/lvm_keyfile resume=/dev/mapper/internal-swap quiet
My system stopped booting after this update. I managed to use an archlinux iso to boot the system and mounted the LVM volumes.
I though the problem was kernel related and attempted to reinstall the kernel manually. At the initramfs build stage I noticed an error being displayed to the effect that the lvm2 hook has no build function.
I tried rebooting after image generation and it dropped me to a shell and poking around it looks like there's no LVM support present in the initramfs.
Plus, the LVM hook hasn't been changed in over 1 year:
https://git.archlinux.org/svntogit/packages.git/log/trunk/lvm2_hook?h=packages/lvm2
How to reproduce the bug, or a related one?
Just tried to install my machine. I have only one machine, and it is written from memory since I had to use a public PC:
1) Intsall arch from scratch on a BIOS PC.
2) Use the following HD partitioning: A seperate primary boot partition. A seperate primary partition for swap. An extended partition, with one logical partition to have all the LVM2 filesystems. Within the LVM2 make a seperate root LV, tmp LV, usr LV and home LV.
3) Install base and the extlinux boot loader. With dependency packages such as systemd-sysvcomapt, of course.
4) Mark the usr filesystem ro in /etc/fstab.
5) For the mkinitcpio.conf use HOOKS="base systemd sd-lvm2 fsck". Again, this is written from memory. I hope I didn't forgot something. And yes, this is with a systemd configuration. Not the classical one.
6) Finish the installation.
7) Reboot
Yes, no encryption is mentioned. I am aware of it.
Then it isn't related to this bug.
I don't see any bug or other problem in your comment, so I don't know where to direct you.
I installed mkinitcpio-busybox-1.27.2-1 today, regenerated the boot system and the root partition is found as before.
I got hit by an unrelated bug and the encrypt hook can't read the keyfiles on initramfs so I need to input my boot password 3 times(boot,lvm, boot partition in the real system) now, but the partitions are found correctly.