#997844 grub2-common: GRUB_THEME setting broken when used with encrypted disks

Package:
grub2-common
Source:
grub2
Description:
GRand Unified Bootloader (common files for version 2)
Submitter:
ಚಿರಾಗ್ ನಟರಾಜ್
Date:
2023-04-01 18:24:02 UTC
Severity:
normal
#997844#5
Date:
2021-10-25 19:08:31 UTC
From:
To:
Dear Maintainer,

My setup is as follows. I have 2 storage disks, one SATA HDD and one M.2 NVME SSD. Both disks are encrypted, and the layout is as follows:

NAME                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                       8:0    0   1.8T  0 disk
└─sda1                    8:1    0   1.8T  0 part
  └─sda1_crypt          254:3    0   1.8T  0 crypt
    └─Crypto--Data-Home 254:4    0   1.8T  0 lvm   /home
nvme0n1                 259:0    0 465.8G  0 disk
├─nvme0n1p1             259:1    0   476M  0 part  /boot/efi
├─nvme0n1p2             259:2    0   477M  0 part  /boot
└─nvme0n1p3             259:3    0 464.8G  0 part
  └─nvme0n1p3_crypt     254:0    0 464.8G  0 crypt
    ├─Crypto-Root       254:1    0 425.6G  0 lvm   /
    └─Crypto-Swap       254:2    0  29.8G  0 lvm   [SWAP]

That is, the NVME SSD is split into 3 partitions: one for /boot/efi, one for /boot, and one encrypted partition which provides both / and swap through LVM partitions. The HDD is quite simple — just one giant encrypted partition with a single LVM partition inside (mainly for consistency). That's the setup.

Okay, so here's the issue. I don't normally view the GRUB menu (I have a hidden timeout and I normally go straight to my plymouth splash screen), but I'd like it to look nice if I ever have to open it up. Accordingly, I set a theme by putting GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt" in /etc/default/grub. I even get the appropriate output when I run sudo update-grub (also reflected by the /boot/grub/grub.cfg attached by reportbug):

Generating grub configuration file ...
Found theme: /usr/share/grub/themes/starfield/theme.txt
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.14.0-3-amd64
Found initrd image: /boot/initrd.img-5.14.0-3-amd64
Found linux image: /boot/vmlinuz-5.14.0-2-amd64
Found initrd image: /boot/initrd.img-5.14.0-2-amd64
Adding boot menu entry for EFI firmware configuration
done

However, the menu still takes on the default look (blue menu, no background image, etc). What I realized is that GRUB doesn't seem to copy the background image into /boot/grub/, and since the disk isn't yet decrypted, it can't access the background image at the place it's looking for it.

This feels like a bug because there is every indication (including from update-grub2) that a theme will be used, but then the theme silently fails.

I'd be happy to answer any questions or provide further info if required.

Sincerely,

Chiraag

#997844#10
Date:
2023-04-01 18:20:54 UTC
From:
To:
On Mon, 25 Oct 2021 15:08:31 -0400  =?utf-8?b?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=  <debbugs@chiraag.me> wrote:
 > Package: grub2-common
 > Version: 2.04-20
 > Severity: normal
 > X-Debbugs-Cc: debbugs@chiraag.me
 >
 > Dear Maintainer,
 >
 > My setup is as follows. I have 2 storage disks, one SATA HDD and one
M.2 NVME SSD. Both disks are encrypted, and the layout is as follows:
 >
 > NAME                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
 > sda                       8:0    0   1.8T  0 disk
 > └─sda1                    8:1    0   1.8T  0 part
 >   └─sda1_crypt          254:3    0   1.8T  0 crypt
 >     └─Crypto--Data-Home 254:4    0   1.8T  0 lvm   /home
 > nvme0n1                 259:0    0 465.8G  0 disk
 > ├─nvme0n1p1             259:1    0   476M  0 part  /boot/efi
 > ├─nvme0n1p2             259:2    0   477M  0 part  /boot
 > └─nvme0n1p3             259:3    0 464.8G  0 part
 >   └─nvme0n1p3_crypt     254:0    0 464.8G  0 crypt
 >     ├─Crypto-Root       254:1    0 425.6G  0 lvm   /
 >     └─Crypto-Swap       254:2    0  29.8G  0 lvm   [SWAP]
 >
 > That is, the NVME SSD is split into 3 partitions: one for /boot/efi,
one for /boot, and one encrypted partition which provides both / and
swap through LVM partitions. The HDD is quite simple — just one giant
encrypted partition with a single LVM partition inside (mainly for
consistency). That's the setup.
 >
 > Okay, so here's the issue. I don't normally view the GRUB menu (I
have a hidden timeout and I normally go straight to my plymouth splash
screen), but I'd like it to look nice if I ever have to open it up.
Accordingly, I set a theme by putting
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt" in
/etc/default/grub. I even get the appropriate output when I run sudo
update-grub (also reflected by the /boot/grub/grub.cfg attached by
reportbug):
 >
 > Generating grub configuration file ...
 > Found theme: /usr/share/grub/themes/starfield/theme.txt
 > Found background image:
/usr/share/images/desktop-base/desktop-grub.png
 > Found linux image: /boot/vmlinuz-5.14.0-3-amd64
 > Found initrd image: /boot/initrd.img-5.14.0-3-amd64
 > Found linux image: /boot/vmlinuz-5.14.0-2-amd64
 > Found initrd image: /boot/initrd.img-5.14.0-2-amd64
 > Adding boot menu entry for EFI firmware configuration
 > done
 >
 > However, the menu still takes on the default look (blue menu, no
background image, etc). What I realized is that GRUB doesn't seem to
copy the background image into /boot/grub/, and since the disk isn't
yet decrypted, it can't access the background image at the place it's
looking for it.
 >
 > This feels like a bug because there is every indication (including
from update-grub2) that a theme will be used, but then the theme
silently fails.


I noticed this bug as well with a freshly installed copy of bookworm.
(Using a d-i testing snapshot from March 26 2023). I did a pretty
standard amd64 with gnome desktop install, but with the root filesystem
encrypted ("guided, use entire disk". /boot is unencrypted, but with
the splash image in /usr/share, grub can't access it and thus there's
no theming; just the ugly blue default grub screen. Seems like the only
way to work around it is to copy a png file into /boot/grub.