Btrfs on luks: unable to boot

As a second episode in my attempt to perform an EOS btrfs install on my quite old, pre-uefi 2010 laptop upgraded with ssd (I wonder whether/how bios is able to see ee gpt partition as bootable), I find myself stuck at system booting.

What I have tried so far in several installation attempts:

  • gpt partition table (as per @2000 btrfsonluks article and related thread)
    • 8M unformatted bios_boot flag, residual space btrfs partition in Luks crypto
    • bootloader installed either on MBR or in / partition
  • dos partition table
    • single btrfs partition in Luks crypto
    • bootloader installed on MBR
    • (optionally) boot flagged btrfs partition
  • hybrid mbr
    • same layout as with gpt approach
    • printf ‘\200\0\0\0\0\0\0\0\0\0\0\0\001\0\0\0’ | dd of=/dev/sda bs=1 seek=462 as suggested in archwiki to add a bootable type 0 to the second MBR partition slot
    • parted /dev/sdx disk_toggle pmbr_boot marking the gpt partition within the hybrid mbr as bootable (as would be in fdisk > entering the protective/hybrid MBR > a to toggle bootable flag > w to write changes to disk)
    • toggling within fdisk the legacy_bios bootable flag on the 8M partition
    • regenerating Grub configuration after every change via grub-mkconfig -o /boot/grub/grub.cfg
    • reinstalling Grub via grub-install --target=i386-pc --debug /dev/sda, whose output produced no errors

In all these cases, the result has been an unbootable system, stopping even before any GRUB menu appears and greeting the puzzled user with a bios window showing the available devices to boot (the only ssd I have on this laptop) and the message of Samsung SSD is failed when attempting to select it.

Knowing the SSD isn’t actually failed and trying to get out of this pit, I leveraged on Endeavour live usb stick used for installation and “chainload” the system from there, via the Boot existing OS menu.
While it normally fails in booting, bringing me back to the starting Live Grub menu, editing that entry from hd 0 0 to hd 1 0 it magically boots the system, letting me to open the crypto and leading me to the installed Grub menu.
From there, entering in Grub command mode, I tried to understand what does the bootloader see, getting this apparent mess (for some reason - maybe it’s normal - all the hd entries are duplicated, and I have only 1 ssd on this laptop):

grub> ls
(hd0) (hd0,msdos2)
(hd1) (hd1,gpt2) (hd1,gpt1)
(hd2) (hd2,msdos2)
(hd3) (hd3,gpt2) (hd3,gpt1)
(crypto0)
(proc)

In front of this riddle wrapped in a mystery inside an enigma I stand now, without much more options left in my limited knowledge.
Does all this make any sense to any of you? I am truly open to any kind of alternative to get out of this block and finalize the installation (’m not particularly fond of gpt if not needed, so an old mbr partitioning, with a little help in making it bootable with btrfs on luks, would be totally fine), so I might move on and go back using this old companion of mine.

Thanks as usual for your patience in reading and for any spark of light you might bring!

I would simply use plain old BIOS/MBR with compatibility mode.
One /boot partition, plus one single big partition for the rest (and maybe swap, depends on your needs).
So before installation,

  1. create the two partitions (e.g. with cfdisk)
  2. format /boot to ext4 or btrfs or any other filesystem supported by GRUB
  3. luks-format the other partition and unlock it
  4. format the luks partition with btrfs
  5. install.

Now, I don’t know how exactly the installer works and if it can auto-unlock the LUKS partition. I used to do this manually by adding the appropriate line to /etc/crypttab and adapting /etc/fstab, but it’s been a long time since I last used encryption on / so don’t take my words for granted :wink:

1 Like

sorry for late reply, @torvic9 but only yesterday had the chance to experiment a bit…after some attempts with grub (following @ricklinux Everything About Grub! post), I decided your approach with good old bios/mbr is definitely the best in my case.
I confirm Calamares handles it gracefully, and it’s even able to correctly perform encryption on both boot partition and main btrfs volume.

thanks for your advice!

1 Like