GNU 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 |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
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
Powered by Savane 3.13-02a9.
Corresponding source code
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):
On the desktop (not working):
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:
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.
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:
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.