[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How do I get back the GRUB menu with the blue background?



On Sun, 4 Jul 2021 at 18:54, Stella Ashburne <rewefie@gmx.com> wrote:
> > Sent: Friday, July 02, 2021 at 10:49 AM
> > From: "David" <bouncingcats@gmail.com>
> > On Thu, 1 Jul 2021 at 23:20, Stella Ashburne <rewefie@gmx.com> wrote:

> > I suggest to boot as you describe above (your step #8) until you reach
> > the 'grub>' prompt. This is actually a very useful prompt but you
> > need to know some tricks to use it. So begin by reading this page:
> > https://www.gnu.org/software/grub/manual/grub/html_node/Naming-convention.html#Naming-convention

> > You can use this method to try to find which device
> > and directory contains your grub directory. It will
> > look something like (hd0,msdos1)/grub and will
> > contain the grub files including your grub.cfg menu.
> > You could then use grub's 'cat' command to inspect
> > the UUIDs it is attempting to use. However that's
> > probably not useful at this time.
>
> I know where GRUB's files are located, viz. in ESP (EFI System Partition) and the /boot partition.

As I mentioned, I do not know GPT and UEFI systems.

However, I would expect that after you have successfully
discovered where grub finds the grub file directory, and the
kernel file and the initrd image, then it should be possible to
execute a manual sequence of commands at the grub prompt like:

grub> insmod part_gpt
grub> insmod ext2
grub> linux ... root= ...
grub> initrd ...
grub> boot

That should boot into your installation. After that you will need to
run 'grub-install', see below.

If the insmod commands fail, that can mean the value of
'prefix' is incorrect. If you specify the full path that grub uses
to refer to each file, then it isn't necessary to specify 'root'
variable.

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?

> Did you know that Debian Buster's installer has a feature called Rescue Mode.
> I made use of it to chroot into /target followed by running apt install --reinstall
> grub-efi and update-grub. It didn't work. As stated earlier, I guess the file and
> modules are messed up in the ESP and /boot partition.

Yes I am aware of that method which can succeed. However
I think you need to also run 'grub-install' in that situation to fix your
problem, because 'update-grub' merely regenerates a grub.cfg file
somewhere.

You should check that target device and boot directory used
by 'grub-install' are correct. Perhaps use -v and --boot-directory
options to make sure that 'grub-install'
does not reference anything inside your encrypted partition.

> Oh by the way, Youtube video clips that show how to fix GRUB
> issues aren't useful in my case.

Without seeing the commands, I don't know what this refers to
or why you would hold this view.


Reply to: