- 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
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
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.