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.
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.
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
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
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:
- Replicate your existing install (partitions/disks/OS’s) in a new VM
- Snapshot the VM
- 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.
- 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?
In an effort to better understand my system, I recently grabbed an old Thinkpad and installed Arch using luks encrypted lvm2 containers. The process is quite similar between uefi and bios and you’ll probably have a better idea about the ideas involved in your re-installation of grub and your system in general. Just a thought…
in case you need to chroot
sudo su cryptsetup luksOpen /dev/sdaX crypto ( here volume mapper encrypted ) cryptsetup luksOpen /dev/sdaY swap ( case out encrypted ) mount /dev/mapper/crypto /mnt mount /dev/sda1 /mnt/boot/efi ( if you need Efi ) mount -t proc proc /mnt/proc mount -t sysfs sys /mnt/sys mount -o bind /dev /mnt/dev mount -t devpts pts /mnt/dev/pts/ chroot /mnt
I’m going to settle for that.
I have taken a backup with clonezilla (though I’m not sure it will be able to restore encrypted partitions and MBR without extra problems). I have backups of my data. But I don’t currently have the time to mess with re-installation of the OS or to try and solve future errors that might arise with clonezilla.
I’m going to leave this for later.
I did update my machine with latest updates (without re-installing grub) and everything is fine.
I don’t know if I should mark this as the solution to my original question (since it doesn’t solve the question itself), but this ends my inquiry regarding that issue for the time being.