Kernel update failed due to low battery, vmlinuz-linux not found

not sure if I managed to stumble into a MAC. :unamused:
My laptop went into hibernation during an update and now vmlinuz-linux can’t be found.
To make matters worse, my system runs on a LUKS partition with BTRFS.
After successfully decrypting the master key and going past GRUB menu I’m getting

Booting ‘EndeavourOs, on linux'

error: no such cryptodisk found, perhaps a needed disk or cryptodisk module is not loaded.
Loading kernel linux …
error: file /@/boot/vmlinuz-linux' not found.
Loading initial ramdisk
error: you need to load the kernel first.

Press any key to continue...

          Failed to boot both default and fallback entries.

Press any key to continue...-

After some intense experience quite some while ago I’d prefer to proceed very carefully.
Any suggestions?
Thank you very much!

arch-chroot in using these instructions(find the section for btrfs):

Then run pacman -S linux from within the chroot.

Hi, thanks for the quick reply!
I’ve to assume the system is hibernating since the battery was drained.
So, I’m not sure if it’s safe to mount the FS externally.

It should be fine. On Linux, hibernation typically writes your memory to swap.

Also, I am not sure you have a lot of alternatives. Even if you wanted to rollback a snapshot, you would still need to mount that FS.

I’m stuck with this:

-> Running build hook: [resume]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback. img'
==> Image generation successful
(4/5) Check if user should be informed about rebooting after certain system package upgrades.
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down 
(5/5) Checking which packages need to be rebuilt 
fatal library error, lookup self

the mounts look like this:

[root@EndeavourS /1# mount
/dev/mapper/TEMPVOL on / type brts (rw, relatime, ssd, space_cache=v2, subvolid=256, subvol=/@)
/dev/mapper/TEMPVOL on /var/log type btrfs (rw, relatime, ssd, space_cache=v2, subvoltd=259, subvol=/@log)
/dev/mapper/TEMPVOL on /var/cache type btrfs (rw, relatime, ssd, space_cache=v2, subvolid=258, subvol=/@cache)
/dev/mapper/TEMPVOL on /home type btrfs (w,relatime, ssd, space_cache=v2, subvolid=257, subvol=/@home )
/dev/nvme0n1p1 on /boot/efi type vfat (rw, relatime, fmask=0022, dmask=0022, codepage=437, iocharset=ascii, shortname-mixed,utf8,errors=remount-ro)
/dev/mapper/TEMPVOL on /swap type btrfs (w, relatime, ssd, space_cache=v2, subvolid=263, subvol=/@swap) proc on /proc type proc (w, nosud, nodev, noexec, relatime ) sys on /sys type sysfs (ro, nosutd, nodev, noexec, relatime) efivarfs on /sys/firmware/eft/eftvars type efivarfs (rw, nosutd, nodev, noexec, relatime)
udev on /dev type devtmpfs (w, nosutd,relatime,size=3931328k, nr_inodes=982832, mode=755, inode64) devpts on /dev/pts type devpts (rw, nosuid, noexec, relatime, gid=5, mode=620, ptmxmode=000 )
Schlevel shortcuts
shm on /dev/shm type tmps (rw, nosuid, nodev, relatime, inode64) run on /run type tmpfs (w, nosuid, nodev, relatime, mode=755, inode64)
Alternative sino piche
tmp on /tmp type tmpfs (rw, nosuid, nodev, inode64)
airootfs on /etc/resolv.conf type overlay (w, relatime, lowerdtr=/run/archtso/airootfs,upperdtr=/run/archtso/cowspace/perststent_EOS_202311/x86_64/upperdtr,workdir=/run/arcl istent_EOS_202311/x86_64/workdir,uuid=on)
[root@EndeavourOs /1#

systemd is definitely up and running,

These aren’t important. They always fail in a chroot.

Ok, I dared to try to boot the original system, and basically it looks good now! :slight_smile:
But this is peculiar:

Booting ´EndeavourOs, on linux'
error: no such cryptodisk found, perhaps a needed disk or cryptodisk module Is not loaded.
Loading kernel linux
Loading initial ramdisk

Press any key to continue...

There’s some timeout, I don’t need to press any key.
I’m sorry to say, I’m not entirely sure, but maybe this is old?
So the “error: no such …” part of the original posting has nothing to do with the update-mishap?

Is your system encrypted?

If not, comment out the crypto line in /etc/default/grub and run sudo grub-mkconfig -o /boot/grub/grub.cfg

I’m sorry for the mess, I misread the line and overlooked “If not” …
It is commented out!
So does the reverse conclusion apply and I should activate this line since the system is encrypted?
Edit: tried that and it didn’t change anything.

Thanks for your help!
I ran into another problem, which is on Grub’s side, but I’ll open a separate thread for this since the kernel works now.
On a side-note: I also checked with the BTRFS-people and someone strongly recommended to erase the hibernation image, as to not accidentally resume from this flawed hibernation.
I did that by rewriting the swapfile using `mkswap´ with its original UUID, which apparently worked.
Thanks again, Michael.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.