How to recover grub with LUKS encrypted LVM partitions after motherboard replaced

dual-bootgrub2lvmuefi

I had dualboot Windows 10 and Kali Linux x64 (Linux distribution based on Debian 9 x64) on my Lenovo X280 notebook with EFI bios. Windows 10 uses BitLocker with password (not TPM). Linux uses LUKS encryption. I have Kali /boot partition created separately. I had to replaced motherboard in service. After this only Windows boots. Grub was missing. So I tried reinstall grub from Live system (from USB flash drive):

  1. I manually encrypted LUKS partitions:
    cryptsetup luksOpen /dev/nvme0n1p4 disk
    
  2. I mounted partitions:
    mount /dev/mapper/sk1-system /mnt
    mount /dev/nvme0n1p5 /mnt/boot
    mount /dev/nvme0n1p1 /mnt/boot/efi
    for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt$i; done
    
  3. Install and update grub:
    chroot /mnt
    grub-install /dev/nvme0n1 
    update-grub
    

After it grub was installed successfully, but after power on notebook I see black screen with LUKS password, when I enter correct password I see only Windows Boot Manager in Grub menu, not Kali Linux.

My drive is partitioned this way:

nvme0n1:
nvme0n1p1: EFI
p2: MS Reserved Partition
p3: Windows 10 (BitLocker)
p4: crypto_LUKS partition it contains:
LVM:
/dev/mapper/sk1-system
/dev/mapper/sk1-swap
p5: Kali /boot partition (ext4)
p6: DATA (NTFS)
p7: WinRE_DRV

My grub.cfg

My fstab file

What way I can add boot item for Kali Linux too please? And what way I skip black screen with LUKS password request before grub screen please? (Before motherboard replace I see grub screen directly).

Best Answer

Reading your grub.cfg file, the part that is the immediate cause of the first LUKS password request is this:

cryptomount -u 99cc765bd11945e7a922436c76cfd505
set root='lvmid/vlNbhc-Fecj-bwew-vg7J-nnuy-3aCy-zl395m/Co88vm-3aMx-939B-ehD7-ijFW-Hw7p-z3gWUW'

So, it looks like update-grub is preparing to read something from a LVM-based filesystem. What might that be?

font="/usr/share/grub/unicode.pf2"

Oh, it wants to read a font file from /usr/share/grub directly.

According to the comments, this part comes from /etc/grub.d/00_header file. If GRUB internal feature test variable feature_default_font_path were set to y, then the entire block would be skipped, avoiding the LUKS password prompt here.

Another similar block is immediately after ### BEGIN /etc/grub.d/05_debian_theme ### comment: it also makes sure the encrypted disk will be mounted, in order to...

if background_image /usr/share/desktop-base/kali-theme/grub/grub-16x9.png; then
  set color_normal=white/black
  set color_highlight=black/white

... load a background image for the GRUB menu from /usr/share/desktop-base/.

The remaining blocks (and the corresponding configuration snippet files in /etc/grub.d/) don't seem to depend on access to encrypted disks.

So, to get rid of the extra LUKS prompt before the GRUB menu, you'd need to either disable the graphical menu and fall back to a plainer appearance of GRUB, or look into /etc/grub.d/00_header and /etc/grub.d/05_debian_theme, find out what configuration options they provide. Then you could copy the appropriate files and use the appropriate options in /etc/default/grub to make GRUB find the necessary fonts and images from another location, so GRUB won't need to read an encrypted disk just to display a menu.

It looks like you could copy the font file from /usr/share/grub/unicode.pf2 to e.g. /boot/grub/unicode.pf2 and then set GRUB_FONT=/boot/grub/unicode.pf2 in /etc/default/grub.

Likewise, you could copy the background file from /usr/share/desktop-base/kali-theme/grub/grub-16x9.png to /boot/grub/grub-16x9.png and then set GRUB_BACKGROUND=/boot/grub/grub-16x9.png in /etc/default/grub.

After doing these configurations, you could run update-grub and verify that your regenerated GRUB configuration should now be quite a bit simpler, and contain no cryptmount commands any more.

Related Question