Reinstall grub + BIOS + fully encrypted LUKS partitions, will this work?

Background
My manjaro system is installed to sda1 (root (/), boot (/boot), home (/home) are all on sda1) and swap on sda2.
Both sda1 and sda2 are encrypted with LUKS. And my system uses BIOS and not UEFI (sda has an msdos partition table and there isn’t any /boot/EFI directory on my system).

Currently, everything works fine. I don’t want to mess something when I reinstall grub. So I want to verify in advance that I’m doing things correctly. manjaro is my main workstation.

Maybe I should also mention that I have another disk (sde) with a ubuntu partition and a swap partition on it.
When I start my PC I get to a screen where I need to type the password to un-encrypt sda1. After I put the correct password, I get to the manjaro grub menu where I can choose between manjaro (the default OS) and ubuntu. If I change boot sequence to the ubuntu disk, then ubuntu loads without having to unencrypt sda1 and without entering the manjaro grub menu. I get directly to the ubuntu grub menu).

I tried finding some information about grub-installer with LUKS and BIOS and couldn’t find what I was looking for.

So my main question is:

What should I do in order to fix the boot hole and not find myself locked out because of the LUKS encryption on sda1?

  1. Should I upgrade all packages and then, before I reboot the pc do:

grub-install /dev/sda
grub-install --recheck /dev/sda
update-grub

Or should I first reboot so that the new packages be loaded and then run those 3 commands?

  1. Some people suggested using “sudo grub-install --recheck –no-rs-codes /dev/sda”. How can I know if in order to keep everything as it is, I should or shouldn’t use --no-rs-codes?

  2. Should I do anything special because of the LUKS encryption of the root directory? I read that people that only encrypt /home don’t need to fear anything. But I couldn’t find any reference to people who have their whole system encrypted.

I hope you can give me some advice.

Thank you. :smile:

What do you mean by boot hole?

Why do you want to install an already installed bootloader?

If all you want to do is destroying Ubuntu bootloader

dd if=/dev/zero of=/dev/sdb bs=446 count=1

MAKE SURE SDB IS THE DISK ON WHICH UBUNTU IS INSTALLED!

Before you do anything take a backup of your /dev/sda MBR

Task: Backup MBR and Extended Partitions Schema

Backup /dev/sda MBR, enter:
# dd if=/dev/sda of=/tmp/backup-sda.mbr bs=512 count=1
Next, backup entries of the extended partitions:
# sfdisk -d /dev/sda > /tmp/backup-sda.sfdisk
Copy /tmp/backup-sda.sfdisk and /tmp/backup-sda.mbr to USB pen or somewhere else safe over the network based nas server.

Task: Restore MBR and Extended Partitions Schema

To restore the MBR and the extended partitions copy backup files from backup media and enter:
# dd if=backup-sda.mbr of=/dev/sda# sfdisk /dev/sda < backup-sda.sfdisk
Source: UNIX / Linux: Copy Master Boot Record (MBR) - nixCraft

I assume they are saying that because their boot partition is also encrypted by LUKS, Manjaro’s bootloader wouldn’t be detected at boot.

Because they are using Legacy BIOS, and not UEFI, they don’t have a /boot/EFI to keep separate from the main encrypted partition.


@chfanzil

Have you tried following this?

https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Preparing_the_boot_partition

I think OP should clarify the goal. Everything is working as expected.

My goal is that after I re-install grub, everything will keep working as it’s working now.

By ‘boot hole’ I mean the security hole in grub that got fixed lately with the stable update from 2020-08-16. In the review of the update @philm says :

So I want to re-install grub as @philm said. My system is BIOS-MBR but it’s also fully encrypted.

I’m sorry for not being clear enough. I don’t want to destroy ubuntu bootloader. I simply want to re-install grub like @philm said in his latest update. But I fear that re-installing grub will change something in my setup and I wouldn’t be able do boot manjaro because of the fully encrypted partitions that I have.

I don’t know where, currently, the ‘grub screen that asks for password’ (before the grub menu) is residing in my setup, and I fear I would mess it up when I re-install grub.

I guess that the ‘grub screen that asks for password’ is placed somewhere (maybe on sda and not sda1?) and it’s un-encrypted. But I’m not sure how such a thing works with BIOS and LUKS encrypted root partition.

I hope someone can clarify this.

1 Like

see this topic

Are you asking if I’ve tried this when I first installed manjaro?
No. Back then I used the gui installation wizard and I approved the setup that was offered which was full disk encryption with LUKS. I didn’t allocate a special partition for boot and it seems that the wizard itself didn’t allocate one.

If you’re asking if I’ve tried this now. Then no, I haven’t. I understand that these instructions for the preparations of the boot partition, need to executed before the system is installed.
Are you suggesting that I shrink the encrypted partition of sda1, create a new un-encrypted partition (say sda3) and then try to make this the boot partition?

I’m aiming for Primum non nocere. Shrinking an encrypted partition and changing boot to another partition seems like something that if I try will probably make more harm then good. I guess someone more knowledgeable can do it easily, but not me.

Thanks @stephane. This answers questions #1 - I should update grub before reboot.
Unfortunately, the issue that @Florian had there refers to him not typing his password correctly. I can’t understand if his setup uses BIOS (like me) or UEFI.

Do you think we can assume that if his error was only related to not typing his password correctly that the grub re-installation is not going to mess the initial screen where one enters his passpharse to decrypt the root partition? (or we still need to understand if he uses BIOS or UEFI?)

boot on your disk
and returns

inxi -Mxxxza
sudo parted -l
sudo efibootmgr -v
test -d /sys/firmware/efi && echo efi || echo bios

I’m doing this from inside manjaro. I can still boot the OS (because I haven’t updated the latest packages yet)

$ inxi -Mxxxza
Machine:   Type: Desktop Mobo: ASRock model: X470 Master SLI/ac serial: <filter> 
       UEFI [Legacy]: American Megatrends v: P1.10 date: 04/19/2018

There are some disks that contain only media files so I’m not copying their info here in order to keep this post short (sda is where manjaro is, sde is where ubuntu is):

$ sudo parted -l
Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sda: 240GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size    Type     File system  Flags
 1      1049kB  222GB  222GB   primary
 2      222GB   240GB  18.5GB  primary



Model: ATA KINGSTON SUV5001 (scsi)
Disk /dev/sde: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size    Type      File system     Flags
 1      1049kB  103GB  103GB   primary   ext4            boot
 2      103GB   120GB  17.5GB  extended
 5      103GB   120GB  17.5GB  logical   linux-swap(v1)

$ sudo efibootmgr -v
EFI variables are not supported on this system.

$ test -d /sys/firmware/efi && echo efi || echo bios
bios

I noticed the inxi -Mxxxza printed “UEFI [Legacy]”. So it seems that my motherboard is willing to work with UEFI (and/or BIOS?) but that my manjaro install is installed with BIOS? Is that an issue for the grub re-installation?

it mean UEFI possible failback legacy and your disk are MBR ( msdos )
your setup is bios

Do I need to do anything special to deal with grub re-installation if my whole partition is encrypted?

Where does the grub screen that ask for passphrase (before the grub menu) reside?
If it boots at start, it means it’s not encrypted. (could something reside on /sda and without being on /sda1 and not even on /sda2?)

Does the grub re-installation also affect this grub-passphrase-screen?

because your grub come from sde ( flag boot ) not sda …

Does this mean that if I remove the ubuntu disk I won’t be able to boot manjaro?

Now that I inquire deeper, and look at the flags that parted -l prints, I also see a boot flag on another drive which stores media files.
Model: ATA Hitachi HTS54101 (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  946GB   946GB   primary   ntfs         boot
 2      946GB   1000GB  54.5GB  extended
 5      946GB   1000GB  54.5GB  logical

Could this be a relic of an old OS that was once on this disk before I attached it to my current PC?
How can I know which partition (sde1 of ubuntu or sdc1 that stores only media files) is responsible for the grub passphrase screen?

My setup uses UEFI, if that’s any help.

Thanks @Florian! I wanted to ask you this after I read your post but I didn’t get to it.
It does help because now I know I have a different situation and must understand how BIOS + full disk encryption works on my setup.

I did some checking. I disconnected sdc and sde and tested few things. Then reconnected them and tested again.
It seems that whenever sda is the first boot priority (on my motherboard), then I get to grub passphrase screen. If sdc and sde are disconnected, I can still get to the grub passphrase screen. So (I guess) I can assume that whatever triggers the grub passphrase screen is located somewhere on sda.

I’m still left with the question, how is re-installing grub (to sda? sdc? sde?) is going to affect my system’s decryption/passphrase screen.

Please note my comment here. This might not be as big of a vulnerability as it first appears.

If you still want to fix the vulnerability, you’ve got a bit of a complex setup that not a lot of users are likely to have experience with.

To be sure about how something will work on your system without changing it, I’d recommend creating a VM and testing the changes there:

  1. Install virtualbox
  2. Replicate your existing install (partitions/disks/OS’s) in a new VM
  3. Snapshot the VM
  4. Attempt to re-install grub

If you bork the VM, you can revert to a snapshot, while gaining knowledge of what not to do without impacting your actual system.

If you encounter specific errors, you can report back here and we can try to assist with those.

Notes:

  • With your system being encrypted, it is especially important to have a backup of your data in the event that it becomes inaccessible. That way if things go awry, at the very least you’ll be able to re-setup your system without losing that.
  • Fixing this vulnerability is not something that needs to be rushed. You can continue to update your system to future updates without re-installing grub and your system should continue to function like normal. You can take all the time you need to research/prepare for re-installing grub until you’re confident you can do so without losing data

Thank you for your idea and for confirming that it’s OK to update the other packages without re-installing grub!

I tried your idea of creating a VM:

I copied and converted my sda disk (the one with the root partition and the swap partition) to a qcow2 file and tried loading it in virt-manager.

I get to the passphrase entry screen where I’m being asked to enter my passphrase:

SeaBIOS (version ?-20200516_175120-fekuxinnars2)
Machine UUID ea196e19-ABCD-ABCD-ABCD-ABCDEFGHIJKL

iPXE (http://ipxe.org) 01:00.0 CA00 PCI2.10 PnP PMM+12345678+12345678 CA00

Booting from Hard Disk...
GRUB loading..
Welcome to GRUB!

Atempting to decrypt master key...
Enter passphrase for hd0.msdos1 (bZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ):

(bZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ is the root partition on sda1)

(Normaly I wouldn’t get the first 3 line that begin with “SeaBIOS” “Machine UUID” and “iPXE”. I guess it’s related to virt-manager’s BIOS setup. In my un-virtualized setup I see the motherboard’s BIOS screen that then disappears and then I get to the “Booting from Hard Disk… GRUB loading… Welcome to GRUB!..” screen.)

When I enter my passphrase I then get to the grub menu where I can choose between manjaro and ubuntu (I can’t really choose ubuntu because I only cloned sda and not sde and the other disks). After few seconds I get an error message saying:

mount/openswap_keymount: no filesystem type specified
Device /dev/disk/by-uuid/bYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY does not exist or access denied.
unmount: can't unmount openswap_keymount: Invalid argument
Error: resume: hibernation device '/dev/mapper/luks-bZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ' not found
Error: device '/dev/mapper/luks-bZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ' not found.
 Skipping fsck
mount: /new_root: no filesystem type specified.
You are now being dropped into an embergency shell
sh: can't access tty; job control turned off
[rootfs ]#

bYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY is the swap partition (sda2)
bZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ is the root partition (sda1)

By the way, I can’t type anything after “[rootfs ]#”. I thought I’ll be able to get more info.
I can miss-type my passphrase at the beginning and then get to a grub_rescue command line, but I don’t know if that helps.

Does this mean it’s impossible to clone a LUKS-encrypted disk and run it in a virtual machine for testing?