how to repair your luks/btrfs setup when you accidentally broke the grub bootloader

Say you, like my dumb ass from last night, just fucked up your boot when mess­ing with your BIOS. You did one of those fancy LUKS/BTRFS se­tups with your fancy sub­vol­umes and shit, ^{[1] Link to foot­note 1} and as it turns out, every sin­gle boot re­pair ISO seems to think that’s some type of im­pos­si­ble wiz­ardry, so you’re on your own. Here’s what you can do:

Boot into a live USB and get into a ter­mi­nal. Ideally, it should have a dis­tro that lets you ob­tain arch-chroot, ei­ther built-in or through in­stalling it. Mine was­n’t built in, but it ran on Debian so I could do some apt install-type shit.

First, find your drive with lsblk -f. You’re go­ing to want to pay at­ten­tion to what­ever drive is ob­vi­ously the one you run your OS on—if it’s LUKS en­crypted, it will look like a sin­gle, big blob—and note the /dev/sdX that it’s at­tached to.

Once you noted that, type in this shit, in or­der, re­plac­ing /dev/sdX with what­ever your ac­tual drive is:

cryptsetup open /dev/sdaX luks
# put in your password, ofc
mkdir /tmp/temp_mnt
mount /dev/mapper/luks /tmp/temp_mnt
cat /tmp/temp_mnt/@/etc/fstab

If you did it right, you should see a bunch of shit rel­e­vant to how your setup pre­vi­ously was. (If your live USB in­cludes an ac­tual DE, you can also open /tmp/temp_mnt/@/etc/fstab in a text ed­i­tor.) With some stuff gener­i­cized, here’s an ex­am­ple of what a LUKS/BTRFS setup might look like:

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/mapper/luks 
UUID=W0WNVMB3R5	/         	btrfs     	rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvolid=256,subvol=/@	0 0

# /dev/sda2
UUID=W0WNVMB3R5	/boot     	ext2      	rw,relatime	0 2

# /dev/sda1
UUID=W0WNVMB3R5 /boot/EFI 	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/mapper/luks 
UUID=W0WNVMB3R5	/home     	btrfs     	rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvolid=257,subvol=/@home	0 0

The rel­e­vant stuff is, in or­der from top-left-ish to bot­tom-right-ish of each en­try, the de­vice (looks ei­ther like /dev/mapper/luks or /dev/sdaX), the di­rec­tory those are mapped to (/, /boot, etc), and your mount op­tions, sep­a­rated by com­mas (rw,relatime, among other, much longer en­try op­tions). Using those three things, per-en­try, you’ll be do­ing some­thing sim­i­lar to this:

mount [DEVICE] /mnt/[MOUNT DIRECTORY] -o [OPTIONS]

## EXAMPLE (using the fstab sample entry from above)

mount /dev/mapper/luks /mnt/ -o rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvolid=256,subvol=/@

mount /dev/sda2 /mnt/boot -o rw,relatime

mount /dev/sda1 /mnt/boot/EFI -o rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

mount /dev/mapper/luks /mnt/home -o rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvolid=257,subvol=/@home

Check first that you did­n’t fuck it up, ide­ally by pok­ing through it man­u­ally with a file man­ager. Only when you do that, and you know you did it all cor­rectly, should you con­tinue. (I take no re­spon­si­bil­ity for if you break any­thing!)

Assuming you have arch-chroot (install it if nec­es­sary; when us­ing a Debian live­boot, arch-install-scripts will be the pack­age you need to look for), all you need to do now is

arch-chroot /mnt
grub-install
grub-mkconfig -o /boot/grub/grub.cfg

Restart the com­puter, and it should just work. If it does­n’t, you ei­ther messed up a step, or your prob­lem is way worse than a cooked boot­loader.

That con­cludes the ac­tual guide. If it sounded ex­tremely gen­eral, it’s be­cause I don’t know which spe­cific LUKS/BTRFS setup you, specif­i­cally, use, but /etc/fstab does, so it’s fine.

Okay, cool? Cool. I get to com­plain about Lenovo now.

So I got a re­place­ment key­board for my lap­top; it works great, it has a back­light when my old one did­n’t, I’m happy. For rea­sons I do not know, that key­board’s down key sud­denly stopped work­ing. No other key, just the down key. This is not only not a rare event that comes from my spe­cific new fancy-pants key­board be­ing bro­ken, but an ex­tremely known prob­lem with my lap­top, that, again, for rea­sons un­ex­plained, is solved by re­set­ting your BIOS.

Problem: I just re­set my BIOS. I did not think about the why this would be a prob­lem, but as it turns out, in not first turn­ing off an ex­tremely spe­cific set­ting to make my lap­top “Windows 8 Compatible”, ^{[2] Link to foot­note 2} this means I have shot my boot­loader di­rectly in the fuck­ing face. Apparently, in or­der to be com­pat­i­ble with Windows 8, it has to nuke all the shit that let me use UEFI on an Arch Linux build!

This op­tion is on by de­fault, and be­cause re­set­ting BIOS set­tings is bound to a hotkey, you can press it with­out ever know­ing that the BIOS did, in fact, de­stroy your boot­loader as a re­sult.

So, ef­fec­tively, I had to do all this, all in the name of a key­board “fix” that should­n’t even work in the first place, and be­cause this shit’s al­ways a pro­pri­etary black box, I don’t even get to know why. There is no log­i­cal rea­son why that should have fixed it, es­pe­cially when I had­n’t gone into the BIOS at any point be­tween me putting in the key­board, with func­tion­ing ar­row keys, and that one spe­cific ar­row key break­ing, and be­cause this pro­pri­etary shit’s al­ways a black box, I never will.

Man. I wanted time to mess with some more stuff on this blog that night, too…