bugGNU GRUB - Bugs: bug #58278, grub-probe does not always detect...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58278: grub-probe does not always detect crypt container; missing background image

Submitter:  Eric P <buggybugs>
Submitted:  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: 
Open/Closed:  Open Release:  2.02
Release:  Reproducibility:  None
Planned Release:  None

Thu 30 Apr 2020 04:08:21 PM UTC, original submission:  

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.

Eric P <buggybugs>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by buggybugs (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code