Re: How do I get back the GRUB menu with the blue background?
On Mon, 5 Jul 2021 at 02:46, Stella Ashburne <rewefie@gmx.com> wrote:
> > Sent: Sunday, July 04, 2021 at 12:01 PM
> > From: "David" <bouncingcats@gmail.com>
> > As I mentioned, I do not know GPT and UEFI systems.
> It's off-topic; I am curious why you do not use GPT/UEFI/Secure Boot?
> Secure Boot has been supported since Debian Buster.
Let's stay on topic.
> What did you mean by "prefix"? Would you like to elaborate?
grub> echo "$prefix"
And read the grub docs.
> > Doing that, grub should attempt to boot the specified files, perhaps
> > giving further error messages as a clue to what might be
> > wrong. Did you try this method?
> No, I didn't.
Let's take a step back, I'd like to set out my view of the
situation.
1) grub is a boot manager. If you give it correct information, it
can boot an operating system. The correct information can
be read from a grub.cfg somewhere, or if that fails, someone can
type the correct information at the grub> prompt.
2) Back in the old days, people had to write their own grub.cfg
file. It was pretty simple, just a few commands to tell grub
what to boot. Because people did this, they were familiar
with those commands, so they weren't scared to type them
at the grub> prompt when they needed to rescue a system.
The grub> prompt even had tab-completion, for exactly
this reason.
3) These days, grub comes with 'grub-update' that generates
a grub.cfg file somewhere. Unfortunately this file contains so
much complicated junk that people can't easily see how to
rescue their system by typing at the grub> prompt. However
it is no harder than the old days, if you know what to type.
4) Knowing what to type is a useful skill. It is easiest to
learn this on a non-broken system.
5) Your original post said that you have a grub> prompt, but
no menu. This means that grub is running on your system
just fine, but it does not know where to look for any grub.cfg
file. So at that point, your system does not need a rescue disk,
grub just needs to be told what to boot.
6) Perhaps something else is broken, but attempting
to boot from the grub> prompt will help to diagnose that.
That is certain, and straightforward. I have given you
the steps to try, but you have not yet reported trying it.
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.
8) Inside grub, the 'root' variable defines the device
root for all filenames specified, including grub.cfg.
It just defines what '/' means at the start of a file
pathname. If full device pathnames are specified
to grub, then 'root' isn't used.
9) I suppose you can use a rescue environment and
chroot to boot your system, but it seems unnecessary
unless you can't boot any other way. But if you have a
broken initrd, you will need to do this.
10) Once booted, you will need to 'grub-install' to fix
the problem of grub.cfg not being found. Because grub
currently can't find any grub.cfg, you need to make sure
that the new one is installed to the correct location, which
needs to be outside your encrypted partition. I would not
be surprised if the /boot in your new installation is not the
same as your boot partition, you should check that.
Check your mountpoints. Does 'lsblk -f' show the boot
partition is mounted at /boot?
Run 'grub-install -v <your_device>'
and look for output like:
grub-install: info: setting the root device to <some_device>
Make sure <some_device> is your unencrypted boot partition.
If it isn't, run 'grub-install' again with the '--boot-directory' option
pointing to your boot partition.
Read 'man grub-install' for documentation of its options.
11) Now you have plenty of suggestions that you could try.
For example:
a) Can you boot from grub> prompt?
b) At grub>, can you check the value of $root to discover
where it is looking for grub.cfg? grub> echo "$root"
c) At grub>, can you find grub.cfg anywhere by the
tab-completion method I described in a prior message?
Where?
d) After booting somehow, if you run 'grub-install -v', what
root device does it use to to save the files that it updates,
as explained above?
e) If you reboot after running 'grub-install', does it work?
f) Is the value of '$root' above the same location that
'grub-install' writes to by default? If not, use its
'--boot-directory' option.
Reply to: