FS#72834 - [mkinitcpio] kernel update wipes vmlinuz/initramfs at begin of update and re-creates at the very end

Attached to Project: Arch Linux
Opened by Pawel Kraszewski (PKraszewski) - Thursday, 25 November 2021, 06:20 GMT
Last edited by Jelle van der Waa (jelly) - Monday, 18 September 2023, 17:44 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version 6.0.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

Update of kernel images wipes vmlinuz/initrd at begin of update and re-creates them at the very end. On lower end devices, when updating multiple packages at once it creates prolonged time when the device has no working boot files and in the case of power loss or premature update termination can leave an unaware user with an unbootable system.

Steps to Reproduce:

1. Start `pacman -Suy` on older device (preferably with spinning rust disks)
2. As soon as packages finish downloading, `initramfs-*` and `vmlinuz-*` files of kernels being updated are deleted.
3. Update takes long time due to lower specs/DKMS/slow disk
4. New `initramfs-*` and `vmlinuz-*` are created as a last step of update, *IF* it gets this far (for example, there were no errors in DKMS, no conflicting files, space didn't run out)

Proposed solution:

1. Don't delete `initramfs-*` and `vmlinuz-*` in advance
2. Generate `initramfs-*.new` and `vmlinuz-*.new`
3. Upon verification of correctness, atomically swap old and new files
4. Delete old files

Best regards
This task depends upon

Closed by  Jelle van der Waa (jelly)
Monday, 18 September 2023, 17:44 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/m kinitcpio/mkinitcpio/issues/210
Comment by Giancarlo Razzolini (grazzolini) - Saturday, 27 November 2021, 21:16 GMT
Main problem with this approach is that the kernel package might be updated, but if you swap back the old vmlinux and initramfs, you'll end up with a non bootable system too. I have a hook for running this on post-hook, not pre, but there are other bugs that that approach entails.
Comment by Pawel Kraszewski (PKraszewski) - Monday, 29 November 2021, 10:40 GMT
I'd say it would still be easier to boot with a fallback kernel (that is, probably loading all the necessary modules from initramfs) to a mismatched system than to boot a system with no kernel at all ;)

If that needs a loving, helping hand of a person new to Arch, but doing some custom, embedded Linux and BSD based deployments for living for almost a decade - I'm into it. I'm curious what the "other bugs" you mentioned are - except running out of /boot space, which I have also fallen into ;). Is uppose some vmlinuz--initramfs--/lib/modules mismatches?

Additionally, I've just fallen into a sister problem of this: beacuse you have only one verion of kernel at a time (plus LTS if you are smart, as post-mortem I am now), if the new kernel doesn't play well with your hardware, you have no easy way back. I was just bitten by this - Arch's 5.15 Nouveau doesn't like my GT216GLM, which left my work laptop slighly unusable - I know, old crap, but the employer won't give me a newer one. The "boot to previous kernel" option is painfully missing.
Comment by Giancarlo Razzolini (grazzolini) - Wednesday, 01 December 2021, 11:51 GMT
I'm going to do some revamp of the mkinitcpio alpm hooks soon. There's a PR to merge the commands into one and I'm going to try to move it from PreTransaction, to Post. Regarding having older kernels around, there isn't much we can do about it, since that's the way the distro kernels are done. Having said that, you might want to take a look into the new UEFI stubs functionality of mkinitcpio: https://linderud.dev/blog/mkinitcpio-v31-and-uefi-stubs/. It makes keeping older kernels (with their initramfs's) around, very simple.
Comment by Pawel Kraszewski (PKraszewski) - Wednesday, 01 December 2021, 13:25 GMT
Quite a lecture, thank you.

I'm all in for tests of the PR you mentioned. I have quite diverse set of hardware to test it on - From C2D oldies, through Haswell i7 grownups up to Xeon Silver freshmen.

Loading...