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

[Andres Salomon]

On Mon, 25 Oct 2021 15:08:31 -0400 
=?utf-8?b?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?= 
<debbugs at chiraag.me> wrote:
 > Package: grub2-common
 > Version: 2.04-20
 > Severity: normal
 > X-Debbugs-Cc: debbugs at 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.