Hello everybody,
On my laptop I have Fedora 39 (not switched yet to F40) installed with disk encryption and BTRFS (followed the SysGuides website).
Today I just did a regular update (not the F40 upgrade) and after the boot the PC is now stuck in grub prompt.
I saw some people having similar issues and it seems there’s a way to still boot into the installed Fedora using some grub commands (ls, cat, insmod, set, etc.)
However in my case where I have a LUKS encrypted drive, how can I perform that?
The LUKS partitions are shown as unknown filesystem.
Please, how can I fix my case and how can I boot back into my Fedora.
I also have a windows partitions which boots correctly so can build a live usb if necessary)
Go ahead an build the LiveUSB. Also, link the website guides you said you followed so we can have a better understanding of the whole process you did.
Once you build the Live USB, you can use it to launch cryptsetup open to open the encrypted partition. This honestly sounds like you had Windows on the same disk, and an update from Windows potentially wrecked your install.
I do have Windows, but I don’t remember having updated windows recently and not even booted into it to begin with… The last thing I did was to update Fedora (regular dnf update - not F40 upgrade) and shutdown. A little bit later when I wanted to use the computer it didn’t boot up.
I do see my Fedora entry in the boot menu but it quickly displays a message I was unable to read just before showing the grub prompt.
I had to record in slowmo with my phone and playback to see it’s the following error:
Then, once I am in the live USB, I know I can unlock the drive and somehow read its content but how can I fix the grub?
I read about chrooting and update the grub… Will try to search around this…
Your installation link shows a fairly complicated, non-standard set up. I’m not a very sophisticated user, but I was under the impression that /boot needed to be on an ext3 or ext4 formatted partition, but you’ve got yours on a btrfs partition. And that entire partition is LUKS-encrypted. Did this system boot prior to the upgrade with no problems? Did you mount your EFI partition to /boot/efi?
I agree that it’s not standard but at the same time it’s still common (LUKS and BTRFS).
I did this installation 2 years ago (F37) and it was working like a charm with no major problems… I also did upgrade to F38 and F39 without issue…
And lastly I just made a regular dnf update (not Fedora version upgrade, so I’m still on F39).
I bet that the issue is not that big and that I still have all my data etc. but I need to figure out the correct way to chroot (having LUKS and BTRFS) and maybe reinstall grub…
I didn’t mean to imply that you had any problems with your disk. In fact, this is easy enough to check by booting a distro live usb and using cryptsetup and mount to look through it.
It also sounds to me like your EFI partition hasn’t been messed up by any particular operation either.
Maybe the thing to do is to go through the steps that anyone would to ensure that a kernel upgrade didn’t fail somewhere in the middle, and, if it did, fix the problems that caused. You’ll probably have to get familiar with some steps involved with cryptsetup along the way. It’s non-standard only in that way, but you’ve elected to travel it that way.
If what you are concerned with is chroot, I recommend you get your Live USB, and from the terminal, mount the block device, then systemd-nspawn -D /path/to-the/luks-xxxx-xx . Simple enough for you to analyze the contents of your LUKS container. If all is good inside, you can even attempt to boot it with systemd-nspawn -Db /path/to-the/luks-xxxx-xx and troubleshoot if you need to.
If you need more info on how to do this or never heard of systemd-nspawn here is a man page for you.
I’ve never used this method for anything. It sure looks intriguing!
One key point to the OP, especially if they’re going to be re-installing grub, the latest kernel, or just rebuilding initramfs—all things that can modify files on the machine EFI partition, is that the EFI partition must be mounted at /boot/efi, so they’ll need to double check that this is being done. It sure looks like it would be from my quick breeze through the man page for systemd-nspawn, but it won’t hurt to make sure it is. And, since they’ll be operating in a container, they’ll need to ensure that the partition can be modified if it’s called for in their repair procedure.
