Re: How do I get back the GRUB menu with the blue background?
On Sat 10 Jul 2021 at 11:13:31 (+0200), Stella Ashburne wrote:
> Sent: Monday, July 05, 2021 at 4:52 AM
> From: "David Wright" <deblis@lionunicorn.co.uk>
> >
> > I find the Grub installation prompts in the d-i very confusing.
> > I'm wondering whether your process incorrectly updated grub.cfg
> > in the ESP on the SSD.
> >
>
> I suspected it too because when I installed Debian Testing, I didn't delete both the ESP and /boot partitions that were created by Debian Buster. As a result, after installing Debian Testing successfully and rebooting my machine, there was no blue GRUB menu.
>
> > Bear in mind there are two grub.cfg files.
>
> Where are their locations?
They were in the command lines, viz:
# cat /boot/efi/EFI/debian/grub.cfg
# head /boot/grub/grub.cfg
These are the locations as seen by root in a running system (mine).
> > The
> > second one is the familiar one, so I just give the head:
> >
> > # cat /boot/efi/EFI/debian/grub.cfg
↑ this is the first one ↑ (your snipping is somewhat brutal)
>
> When I issued the above command at the grub> prompt, the response was 'file /boot/efi/EFI/debian/grub.cfg' not found.
That's because you have to tell Grub where to look. A running system
has the /boot partition mounted (obviously) at →/boot←, and the ESP
partition mounted (less obviously) at →/boot/efi←. But Grub has
to be told to look in the appropriate →partition← for each file,
so you'd need something like:
grub> cat (hd0,gpt1)/efi/debian/grub.cfg
and
grub> cat (hd0,gpt2)/grub/grub.cfg
So you have to navigate to it yourself, like:
grub> ls (hd0,gpt2)/
efi/
grub> ls (hd0,gpt2)/efi/
debian/
grub> ls (hd0,gpt2)/efi/debian/
grub.cfg
grub> cat (hd0,gpt2)/efi/debian/grub.cfg
search.fs_uuid f3bf6eef-3c26-4070-b180-fd1914377253 root hd0,gpt4
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
grub>
and this is what I called the "first" grub.cfg, exactly equivalent to:
# cat /boot/efi/EFI/debian/grub.cfg
search.fs_uuid f3bf6eef-3c26-4070-b180-fd1914377253 root hd0,gpt4
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
#
on the running system. (AIUI the change in case of efi/EFI is caused
by the options chosen for mounting the vfat filesystem.)
> > (I only encrypt /[h]ome and swap.) I'm wondering whether your first
> > grub.cfg is pointing to the USB stick that you used in the
> > installation. That would be simple to check.
>
> No.
If you /know/ the answer is "no", then you must know where it /does/ point.
> If you're using UEFI and the partition table scheme is gpt, Debian 10's installer detects that your SSD is using EFI, there's a message on the screen that asks "Force EFI installation to a removable media? Yes or No". My response is always "No".
"If A, then B" does not show "If B, then A". One of the bizarre things
about the d-i is that it still presents that screen when BIOS/MBR
installing on a Pentium III built in 2000. That particular screen is
part of the reason I wrote earlier:
> > I find the Grub installation prompts in the d-i very confusing.
> > If this guess, is correct, it might be possible to confirm it
> > if you get these symptoms:
> >
> > . Booting with the internal drive only: GRUB> prompt.
> > . Booting with the USB stick inserted: something else appears,
> > a blue Grub menu, or a Debian installer splash screen,
> > or even Windows.
>
> I did what you suggested by first inserting the USB stick that contains Debian 10's installer and booting up my machine. There's no blue GRUB menu, whatsoever....
>
> >
> > Of course, the second scenario can only work if the USB's UUID
> > hasn't been recreated by further uses.
>
> Yes, I'm aware of that fact....
I mentioned it only because /you/ know what's been done with your
system, sticks, and everything else in your universe, whereas every
other reader of this post does not. So when you eventually use Grub's
introspective abilities to find out which ESP was used and where it
pointed, that's a factor in interpreting the result: it might point
to nowhere now.
> > ¹ With encrypted systems, you have to bear in mind what can be seen
> > outside and inside the container. This is easy to distinguish
> > with only /home encrypted, as you can inspect things with the
> > normal system tools.
>
> My LUKS-encrypted partition consists of / and swap area. I assume the / contains /home, /var, /usr, etc...
It would be nice to give you a set of Grub commands to manually
boot your system with, so that you could fix up the Grub
configuration.
However, two things put that beyond my capabilities: encrypted
root, and "logical volumes".
As you $prefix was correct, I would start with:
grub> insmod part_gpt
grub> insmod ext2
but I'd guess you also require at least:
grub> insmod crypto
grub> insmod cryptodisk
grub> insmod luks
grub> insmod lvm
Grub needs to find the kernel and initrd, and this should work
as they're on a simple unencypted partition:
grub> set root=(hd0,gpt2)
Now /I/ would be able to type:
grub> linux /vmlinuz-4.19.0-17-amd64 root=LABEL=toto04 ro systemd.show_status=true quiet
grub> initrd /initrd.img-4.19.0-17-amd64
but 'root=LABEL=toto04' wouldn't work for you, and you might try
something like:
grub> linux /vmlinuz-4.19.0-17-amd64 root=/dev/mapper/sda3_crypt ro systemd.show_status=true quiet
or:
grub> linux /vmlinuz-4.19.0-17-amd64 root=/dev/perfect-vg/root ro systemd.show_status=true quiet
or even:
grub> linux /vmlinuz-4.19.0-17-amd64 root=/dev/dm-1 ro systemd.show_status=true quiet
depending whether the encryption is inside the lvm, or vice versa.
I'm assuming from your earlier list:
/dev/perfect-vg/root
/dev/perfect-vg/swap
/dev/dm-1
/dev/dm-2
/dev/mapper/sda3_crypt
/dev/sda1
/dev/sda2
etc, etc....
that Grub has done a whole lot of work for you with those modules.
> > > But I wish to learn how to repair GRUB in a non-destructive way.
https://www.gnu.org/software/grub/manual/grub.html
It does require careful attention. I couldn't help noticing that you
posted the following sequence:
> grub> echo "$prefix"
>
The reply is (hd0,gpt1)/boot/grub
[ … ]
> 7) Inside grub, the 'prefix' variable defines where
> grub finds its own code. That appears to be correct,
> otherwise you would see grub_rescue> prompt.
>
What command can I type at the grub> prompt to look inside grub so as to see the "prefix" variable?
which seems to indicate a certain lack of recall.
Cheers,
David.
Reply to: