[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?


I see that you've not had any replies, so I'll attempt to assist.
Even though I have no experience with GPT and UEFI, I have
used LUKS and LVM.

Thank you for making some effort to provide a detailed
description of your situation.

Please note that I have several questions (1, 2, 3) interleaved
below, followed by some suggestions at the end.

On Thu, 1 Jul 2021 at 23:20, Stella Ashburne <rewefie@gmx.com> wrote:

> The partition table scheme is GPT and UEFI with Secure Boot is enabled.
> I do not use legacy BIOS with master boot record.

> Below is the partition layout of my SDD:

1) Do you mean "SSD". If not, what is SDD?

> 536.9MB EFI system partition (ESP)
> 511.7MB /boot (unencrypted)
> 100GB encrypted logical volumes (contains 99GB of / partition, 1GB of swap area.Debian Buster was installed on this partition)
> 16MB Microsoft reserved area (automatically created by Microsoft Windows' installer)
> 100GB Microsoft Windows 10

> 1. Debian Buster's 64bit installer (version 10.10) was used to create the EFI System Partition (ESP), the /boot partition and the encrypted logical volumes. Installation was successful and I was able to boot into the GRUB menu with a blue background. It had an entry named Debian GNU/Linux.

> 2. Next I installed Microsoft Windows 10 and the installation was successful.

> 3. I rebooted into Debian and used sudo os-prober to add the Microsoft Windows' entry to GRUB followed by sudo update-grub

> 4. Dual-boot of Debian and Windows was possible


> Problem(s) happened after I did the following:

> 5. With a USB stick containing the latest weekly build of Debian Testing (Bullseye), I booted into the Debian's installer screen and deleted the 100GB encrypted logical volumes.

> 6. As a result, 100GB of free space was made available. I configured it to have two encrypted logical volumes: 99GB of the / partition, 1GB of swap area.

> 7. Debian Testing was installed on the 100GB partition. Installation was successful.

> 8. However, I am now unable to boot into the GRUB menu with the blue background. Instead all I have is a black screen with the word grub> _ (The underscore is actually the position of the cursor)

There's a couple of things that might have gone wrong here.
Exactly what is unclear at this stage.

2) Can you tell us, during your step 7, what instructions did you
give to the installer at the "install a boot loader" stage?

3) And during the partitioning stages, can you tell us which existing
devices (LUKS, LVM) did you attempt to reuse unchanged, and which
did you recreate?

>From my own experience, attempting to install into a pre-existing
LVM logical volume on a LUKS physical volume, I did once see some
unexpected failures. This might have been my error, or perhaps
the installer might have some buggy behaviour in this kind of
situation. I have not had time to investigate properly.

If, in the installer, you were to start again from the device
partition, and freshly create the LUKS device and the LVM
logical volumes from scratch, then I would expect that to work.

However if you were attempting to re-use any of these then
I am less confident, after seeing possible failure myself.
Even so, this might not be anything to do with your issue, and
I suggest doing some inspection at the grub prompt before
giving up on your existing installation and redoing it
from scratch.

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:

The first trick is this command:
grub> set pager=1
It makes the help command more usable.
grub> help

The next trick is to use tab-completion, as described in
that documentation, as a way of getting grub to show you
which devices and files it is aware of.

For example, if you type:
grub> ls (
and then press the tab key, grub should respond with
a list of the devices it is aware of.

Then each of those devices can be explored using the naming
syntax as described in the documentation.

For example, if one of your devices is (hd0,msdos1),
you can type:
grub> ls (hd0,msdos1)/
and then press the tab key, to see what files grub
can see in the root directory of that device.

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.

When you find your grub.cfg, that is progress, and you
can try booting from that menu.
grub> configfile (hd0,msdos1)/path/to/grub.cfg

However I expect that will not succeed,
because the default grub.cfg by default uses UUID to
identify all devices. And because you reinstalled (your
step #7) you probably have different UUIDs now.

If you report your findings back here when you reach that
stage, then it might be possible to make further progress,
by guiding you how to manually boot from grub>.

The easier scenario will be that we just need to persuade
grub to boot, and then you can run grub-install. Things will
be more difficult if the installer has not properly initialised
your initrd for LUKS.

The other approach is for you to do a complete repeat of
your step 7, and this time create all device manager layers
from scratch as I explained above.

That approach might be simpler for everyone, but less educational.

Let us know how you go. Please be sure to reply to the
list, not me personally, because I am subscribed. Thanks.

Reply to: