URL: <https://savannah.gnu.org/bugs/?58278>
Summary: grub-probe does not always detect crypt container; missing background image Project: GNU GRUB Submitted by: buggybugs Submitted on: Thu 30 Apr 2020 04:08:21 PM UTC Category: Installation Severity: Major Priority: 5 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: Open/Closed: Open Release: Release: 2.02 Discussion Lock: Any Reproducibility: None Planned Release: None _______________________________________________________ Details: Hello. I have near-identical Debian Buster setups on two computers, a desktop and a laptop. What's puzzled me for a long time now is that although both boot successfully, on my laptop the GRUB boot menu has, as it should, a pretty themed background (Debian logo), but on the desktop I only get a plain text screen with no background. I wouldn't know how to change the theme, so I know I didn't do it. It's been like that since I installed the OSes. Today I decided to investigate. The difference is not due to video mode failures: they both appear to be running in a proper video mode (1920x1080), with the skinny font, as opposed to falling back to 80-column mode and ASCII VGA font. (When I physically move the laptop SSD and boot it on the desktop machine, GRUB shows its background image, as it should. So I know the difference is not hardware compatibility.) So I read online that maybe this could be due to the file `/etc/default/grub`, specifically the line `#GRUB_TERMINAL=console`. But the two files are byte-for-byte identical on the two installations: that particular line is commented out, as it should be. So I started poking around looking for differences between the two. On the laptop I see a file `/boot/grub/.background_cache.png`, which contains the background in question. On the desktop, that file is not present. In the file `/boot/grub/grub.cfg`, I see differences in a section that mentions the background image. On the laptop (working): ### BEGIN /etc/grub.d/05_debian_theme ### insmod part_msdos insmod ext2 set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 b2b1c8fd-6cd7-4dc1-85fe-86de97b1e801 else search --no-floppy --fs-uuid --set=root b2b1c8fd-6cd7-4dc1-85fe-86de97b1e801 fi insmod png if background_image /grub/.background_cache.png; then set color_normal=white/black set color_highlight=black/white else set menu_color_normal=cyan/blue set menu_color_highlight=white/blue fi ### END /etc/grub.d/05_debian_theme ### On the desktop (not working): ### BEGIN /etc/grub.d/05_debian_theme ### insmod ext2 set root='hd0' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0 --hint-efi=hd0 --hint-baremetal=ahci0 3ced5547-a505-4289-91cf-e876f58a9a91 else search --no-floppy --fs-uuid --set=root 3ced5547-a505-4289-91cf-e876f58a9a91 fi insmod png if background_image /usr/share/desktop-base/futureprototype-theme/grub/grub-4x3.png; then set color_normal=white/black set color_highlight=black/white else set menu_color_normal=cyan/blue set menu_color_highlight=white/blue fi ### END /etc/grub.d/05_debian_theme ### The desktop system *seems to refer directly to the file in /usr.* Which I believe is wrong, because that partition is not accessible to GRUB. It's in a dmcrypt container. I investigated the mentioned file `/etc/grub.d/05_debian_theme`, which seems to generate that portion of the config file, and I see this section: # Step #5: Check if GRUB can read the background image directly. # If so, we can remove the cache file (if any). Otherwise the backgound # image needs to be cached under /boot/grub/. if is_path_readable_by_grub "${1}"; then rm --force "${BACKGROUND_CACHE}.jpeg" \ "${BACKGROUND_CACHE}.png" "${BACKGROUND_CACHE}.tga" elif cp "${1}" "${BACKGROUND_CACHE}.${reader}"; then set -- "${BACKGROUND_CACHE}.${reader}" "${2}" "${3}" else return 5 fi I don't understand shell syntax very well, but it sounds logical to me, what it's doing there. (Except, the background is ten lousy kilobytes: why not cache it unconditionally?) I investigated the mentioned function `is_path_readable_by_grub` in `/usr/share/grub/grub-mkconfig_lib`. This part doesn't appear to be Debian-specific. is_path_readable_by_grub () { path="$1" # abort if path doesn't exist if test -e "$path" ; then : ;else return 1 fi # abort if file is in a filesystem we can't read if "${grub_probe}" -t fs "$path" > /dev/null 2>&1 ; then : ; else return 1 fi # ... or if we can't figure out the abstraction module, for example if # memberlist fails on an LVM volume group. if abstractions="`"${grub_probe}" -t abstraction "$path"`" 2> /dev/null ; then : else return 1 fi if [ x$GRUB_ENABLE_CRYPTODISK = xy ]; then return 0 fi for abstraction in $abstractions; do if [ "x$abstraction" = xcryptodisk ]; then return 1 fi done return 0 } So, seems to me that it does do some kind of check for encryption. Sounds good. So why is it failing? I manually ran the mentioned command `grub-probe -t abstraction /usr` on both systems, as root. On the working system, the output is: cryptodisk luks gcry_rijndael gcry_rijndael gcry_sha256 lvm Sounds good. On the non-working system, that command gives an *empty* output. On both systems, the exit status of the command is 0. So that is definitely wrong, because they are BOTH encrypted, and grub-probe is failing to report that. There is a small configuration difference between the two systems I didn't mention. Although both have their root partition inside a dmcrypt container, with /boot separate; on the working laptop, the encrypted partition is inside an LVM container. Whereas when I set up the desktop, I opted to skip that additional layer. (The quoted sections of the `grub.cfg` files do mention something slightly different about partitions, but I don't quite understand it.) Anyway, seems to me that the test for "abstractions" is buggy in some way. If this problem is limited to missing background images, I wouldn't make a fuss, but that seems to be a general utility function, so maybe other, more critical things could break due to it. (By the way, on the desktop, I tried manually copying in the file `.background_cache.png`, and manually editing `/boot/grub/grub.cfg` to correct the path to be identical to that on the laptop. However, still no background image was displayed. I noticed while diffing the files that the font path is also different: the laptop has the line `font="/grub/unicode.pf2"`, but the desktop says `font="/usr/share/grub/unicode.pf2"` (again, useless path inaccessible to the boot loader). This is despite the fact that the font file is present/cached, at both `/boot/grub/unicode.pf2`, and `/boot/grub/fonts/unicode.pf2`, on both systems, and does by appearances load. Correcting both the background path and the font path still did not produce any background image. Maybe manual changes to `/boot/grub/grub.cfg` do not take effect. I don't know. I got scared and undid my changes.) So, I have a bug and a mystery, and also a support request. Sorry. I hope someone can extract some sense from this. Thank you. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?58278> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/