Re: How do I get back the GRUB menu with the blue background?
Hi David
> Sent: Friday, July 02, 2021 at 10:49 AM
> From: "David" <bouncingcats@gmail.com>
> To: "Stella Ashburne" <rewefie@gmx.com>
> Cc: "debian-user mailing list" <debian-user@lists.debian.org>
> Subject: 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.
That's very kind of you :)
>
> 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:
>
>
> 1) Do you mean "SSD". If not, what is SDD?
>
Yes, I meant to type SSD. It was a typo.
> 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?
No specific instructions were given to the installer at the "install a boot loader" stage. I just accepted the default. If I remember correctly, the installer of Debian Stretch asked the user to specify the exact location that the boot loader was to be installed. With Debian Buster's installer, there was no need to specify your preferred location.
>
> 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?
>
I deleted the entire 100GB of encrypted volumes (LUKS, LVM), meaning none of the encrypted logical volumes was reused.
> >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.
>
Thanks for sharing your experience with me.
> 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.
No it didn't; hene my original post. To the best of my knowledge, the bootloader's files are not installed on encrypted volumes for obvious reasons.
>
>
> 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
>
Thanks for the link, David.
>
> 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.
>
> 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
>
It didn't work. Your tip can be found in Youtube video clips.
> 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.
>
I suspect that the GRUB files in either ESP or /boot are messed up and their corresponding modules don't match.
>
> 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.
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.
> 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.
>
I totally agree with you. That's why I post my request for help so that I can learn how to fix it. Oh by the way, Youtube video clips that show how to fix GRUB issues aren't useful in my case.
> Let us know how you go. Please be sure to reply to the
> list, not me personally, because I am subscribed. Thanks.
>
Understood.
Reply to: