My install is BTRFS on LUKS following the guide from the wiki.
So I installed the updates that came out today, but didn’t reboot until a few hours later. When I finally did restart, grub informed me that none of the partitions were unmounted and the shutdown procedure failed. So I forced a reboot.
Once I decrypted my partition, I saw this:
Which then went into this:
Would I be ok to delete the oldest snapshot as that’s the one that seems to be causing me issues?
I need this running for work tomorrow, so I’d REALLY appreciate some help.
(I have no experience with btrfs, so this answer may not be useful. At the very least, the paths I’ve put in are not correct)
I’m not an expert, but first up, I’d boot into a live system, check if the disk is running out of space. If free disk space isn’t a problem, then I’d reinstall the kernel.
From the live system, run
pacman -S linux-zen
mkinitcpio -p linux-zen
The preset file is probably put in during kernel installation. If you get an error like
/usr/bin/mkinitcpio: line 265: /etc/mkinitcpio.d/linux-zen.preset: No such file or directory
==> ERROR: Failed to load preset: `/etc/mkinitcpio.d/linux-zen.preset'
then there may be some problem that is out of my limited knowledge.
Here is the preset file, just for reference. You probably don’t need it because I don’t think users are supposed to manually copy paste them.
I’ve been in the EOS live boot digging around, wouldn’t I need to chroot into the install? I chroot’d, but I can’t install a kernel because things aren’t mounted. Do I need to mount all my btrfs subvolumes?
If you think that the mount points are correct, then run the pacman and mkinitcpio commands from my first post. That should create the vmlinuz-linux-zen image which is missing right now.
So I think my issue is mounting btrfs properly. When I mount it to /mnt, I get all the subvolumes under it, and when I arch-chroot /mnt/@ it tells me WARNING: /mnt/@ is not a mount point. This may have undesirable effects.
Aha! The arch wiki isn’t too helpful with this, but the gentoo wiki helped me understand that to mount a subvolume you use the syntax mount - o subvol=<rel-path> <device> <mountpoint>.
I’m back up and running! Wish I could understand what exactly happened that caused all this.
Anyway, once I properly mounted my BTRFS root subvolume with mount -o subvol=@ /dev/mapper/recovery /mnt, I ran arch-chroot /mnt and followed the EOS Wiki article on repairing GRUB and simply ran
Glad you got this sorted out.
If you ever need to chroot again, there are instructions in the Wiki article on how to mount in a live environment; (at the very end ).