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

[Eric P]

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/