Re: How do I get back the GRUB menu with the blue background?
On Sun 11 Jul 2021 at 11:31:09 (-0500), David Wright wrote: > On Sat 10 Jul 2021 at 11:13:31 (+0200), Stella Ashburne wrote: > > 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". > [ … ] Just for the record, I installed bullseye rc2 with encrypted root on a couple of spare partitions (/boot on a borrowed ESP, and root over an unencrypted bullseye rc1). > 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) If this doesn't work, use single quotes. > 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, Actually, this does work, as Grub doesn't have to actually find the root filesystem: the initrd contains its partition UUID in cryptroot/crypttab, and when that partition is unlocked, the LABEL becomes visible. So, assuming you know the LABEL you gave it at this stage in the installation: ┌┤ [!!] Partition disks ├─┐ │ │ │ You are editing partition #1 of Encrypted volume (sda5_crypt). No │ │ existing file system was detected in this partition.│ │ │ │ Partition settings: │ │ │ │Use as: Ext4 journaling file system│ │ │ │Mount point: / │ │Mount options:defaults │ │Label:viva05 │ │Reserved blocks: 5% │ │Typical usage:standard │ │ │ │Erase data on this partition │ │Done setting up the partition│ │ │ ││ │ │ └─┘ (viva05 in this instance), you can just plug that in. You can even give the device mapper's name for the unlocked partition: > grub> linux /vmlinuz-4.19.0-17-amd64 root=/dev/dm-N ro > systemd.show_status=true quiet This works if you can deduce the value of N; that's simple for me as there's only one partition involved (I didn't configure swap), so it's simply dm-0. You could use trial and error to work out the value, too. It only takes a couple of minutes to type in the Grub commands using dm-0, dm-1 etc each time, and seeing whether the kernel finds the root filesystem. If not, reboot. However, I don't intend getting into LVMs any time soon as I'll be overwriting the partition above with unencrypted 11.0 whenever it's released. So I'm no help there. Cheers, David.
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" > > > > 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
Re: How do I get back the GRUB menu with the blue background?
Attention: David Hello, I wish to add some info that might be of interest to you: grub> ls (hd0,gpt1)/ efi/ Note: (hd0,gpt1) contains ESP (EFI System Partition) grub> ls (hd0,gpt2)/ lost+found/ efi/ config-4.19.0.17-amd64 vmlinuz-4.19.0.17-amd64 grub/ System.map-4.19.0.17-amd64 initrd.img-4.19.0.17-amd64 Note: (hd0,gpt2) is the /boot partition The version of the kernel in Debian Testing is 5.10.0-7-amd64 whereas that of Debian Buster is 4.19.0.17-amd64. I'm surprised that even though installation of Debian Testing was successful, the version of config-, vmlinuz- System.map and initrd.img- in grub is of the older Debian Buster. Do you think the problem of the missing GRUB menu can be fixed if the older version of config-, vmlinuz- System.map and initrd.img- can replaced with those of Debian Testing? What do you think? Best regards
Re: How do I get back the GRUB menu with the blue background?
Hello David I didn't expect a rather lengthy reply from you. > Sent: Tuesday, July 06, 2021 at 9:29 AM > From: "David" > To: "debian-user mailing list" > Subject: Re: How do I get back the GRUB menu with the blue background? > > > grub> echo "$prefix" > The reply is (hd0,gpt1)/boot/grub > > 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. > Frankly, I don't know the exact commands to type to boot from the grub> prompt. > 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? > > 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. > How can I tell if I've a broken initrd? > 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. Thanks for the mini-tutorial. > 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? > After typing lsblk -f at the grub> prompt, the error message was can't find command 'lsblk' > Run 'grub-install -v ' > and look for output like: > grub-install: info: setting the root device to > After typing grub-install -v (hd0,gpt2), the error message was can't find command 'grub-install' > Make sure 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. > (hd0,gpt2) is my un-encrypted boot partition > a) Can you boot from grub> prompt? > No > b) At grub>, can you check the value of $root to discover > where it is looking for grub.cfg? grub> echo "$root" > hd0,gpt1 > c) At grub>, can you find grub.cfg anywhere by the > tab-completion method I described in a prior message? > Where? At the grub> prompt, I typed gr and pressed the TAB key. There was no output or suggestions. > > 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? I'm unable to boot (frankly what commands to type to boot at the grub> prompt ?) > > e) If you reboot after running 'grub-install', does it work? > Unable to answer your question (e) because of (d) > f) Is the value of '$root' above the same location that > 'grub-install' writes to by default? If not, use its > '--boot-directory' option. > Unable to answer your question (f) because of (d)
Re: How do I get back the GRUB menu with the blue background?
Hi David > Sent: Monday, July 05, 2021 at 4:52 AM > From: "David Wright" > To: debian-user@lists.debian.org > Subject: Re: How do I get back the GRUB menu with the blue background? > > > 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? > The > second one is the familiar one, so I just give the head: > > # cat /boot/efi/EFI/debian/grub.cfg When I issued the above command at the grub> prompt, the response was 'file /boot/efi/EFI/debian/grub.cfg' not found. > (I only encrypt /Home 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'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 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 > > ¹ 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... Best wishes.
Re: How do I get back the GRUB menu with the blue background?
On Mon, 5 Jul 2021 at 02:46, Stella Ashburne wrote: > > Sent: Sunday, July 04, 2021 at 12:01 PM > > From: "David" > > 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 ' and look for output like: grub-install: info: setting the root device to Make sure 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.
Re: How do I get back the GRUB menu with the blue background?
On Sun 04 Jul 2021 at 10:53:43 (+0200), Stella Ashburne wrote:
> 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.
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.
Bear in mind there are two grub.cfg files. Here are mine. The
second one is the familiar one, so I just give the head:
# 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
#
# head /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
#
The UUID in the first grub.cfg is correctly pointing to:
$ ls -Glg /dev/disk/by-uuid/f3bf6eef-3c26-4070-b180-fd1914377253
lrwxrwxrwx 1 10 Jul 4 08:00
/dev/disk/by-uuid/f3bf6eef-3c26-4070-b180-fd1914377253 -> ../../sda4
$
which is an unencrypted¹ buster filesystem that includes /boot.
(I only encrypt /Home 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. I think I made this
mistake once, which is why I had a set of Grub commands (gleaned off
the web) to boot Windows, as it happened, from a GRUB> prompt, viz:
GRUB> insmod fat
GRUB> set root=(hd0,gpt1)
GRUB> chainloader (${root})/efi/Microsoft/Boot/bootmgfw.efi
GRUB> boot
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.
Of course, the second scenario can only work if the USB's UUID
hasn't been recreated by further uses.
¹ 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. I don't know what Grub's and initrd's view
of that world looks like (my initrds don't contain any encryption
stuff).
Cheers,
David.
Re: How do I get back the GRUB menu with the blue background?
Hi > Sent: Sunday, July 04, 2021 at 12:01 PM > From: "David" > To: "debian-user mailing list" > Subject: Re: How do I get back the GRUB menu with the blue background? > > > 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. > 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. > What did you mean by "prefix"? Would you like to elaborate? > 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. > > 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. > Thanks for your tip. I shall try it. > > You should check that target device and boot directory used > by 'grub-install' are correct. > How do I go about doing it? > Perhaps use -v and --boot-directory > options to make sure that 'grub-install' > does not reference anything inside your encrypted partition. > I don't know how to use the -v and --boot-directory options. Would you like to show me please? > > > Without seeing the commands, I don't know what this refers to > or why you would hold this view. > Sorry for the confusion. I looked up some Youtube video clips to see if they could provide me some tips on how to fix my issue.
Re: How do I get back the GRUB menu with the blue background?
Hi > Sent: Sunday, July 04, 2021 at 2:42 PM > From: "deloptes" > To: debian-user@lists.debian.org > Subject: Re: How do I get back the GRUB menu with the blue background? > > > I had similar issue on some of the machines. Try with the bios boot from > device (some F key). > Thanks for your suggestion. However it didn't work
Re: How do I get back the GRUB menu with the blue background?
Stella Ashburne wrote: > I discovered that reinstalling GRUB and then ran update-grub didn't help > at all. The issue still persists. With my limited technical knowledge, the > only way for me to get back the GRUB menu with the blue background is to > reinstall Debian. I had similar issue on some of the machines. Try with the bios boot from device (some F key). Because you have installed Windows after Debian it could be it has overwritten the EFI partition or the boot order. Once I had to delete the EFI partition and reinstall which solved it, but in your case it might be that the EFI now loads the windows first which might be set in the BIOS or in the EFI. I don't have dual boot, but when I boot from USB stick I have to F9 (HP EliteBook) once so that the bios find the usb and then again F9 which shows the debian boot option.
Re: How do I get back the GRUB menu with the blue background?
On Sun, 4 Jul 2021 at 18:54, Stella Ashburne wrote: > > Sent: Friday, July 02, 2021 at 10:49 AM > > From: "David" > > On Thu, 1 Jul 2021 at 23:20, Stella Ashburne 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.
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" > To: "Stella Ashburne" > Cc: "debian-user mailing list" > 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 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.
Re: How do I get back the GRUB menu with the blue background?
Hi > Sent: Friday, July 02, 2021 at 8:58 AM > From: "deloptes" > To: debian-user@lists.debian.org > Subject: Re: How do I get back the GRUB menu with the blue background? > > > As this is a fresh installation, why don't you just wipe everything linux > partitions and install again the way you want it. > That was what I did. But I wish to learn how to repair GRUB in a non-destructive way. > Alternatively boot into a usb or live cd or installer, mount the volumes and > chroot into (there are many howtos) > > I use something like following where SYSTEM is the target ppath > > mount --make-unbindable -obind /proc/ $SYSTEM/proc/ && \ > mount --make-unbindable -obind /dev/ $SYSTEM/dev/ && \ > mount --make-unbindable -obind /dev/pts $SYSTEM/dev/pts && \ > mount --make-unbindable -obind /run $SYSTEM/run && \ > mount --make-unbindable -obind /sys $SYSTEM/sys/ && \ > > chroot $SYSTEM su - > > when you are there reinstall grub and run update-grub > I discovered that reinstalling GRUB and then ran update-grub didn't help at all. The issue still persists. With my limited technical knowledge, the only way for me to get back the GRUB menu with the blue background is to reinstall Debian.
Re: How do I get back the GRUB menu with the blue background?
Stella Ashburne wrote: > 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) > > After reading some stuff on the internet, please tell me if my > understanding of the following is correct: > > Grub's UEFI Stub is located in EFI System Partition (ESP) while its second > stage modules are in the /boot partition. /boot also contains Grub's > config file. It would appear that the bootloader in ESP is not updated to > match the modules in the /boot partition or it could be that > /boot/grub/grub.cfg is missing. > > Below's my attempt at getting back the Grub menu with the blue background: > > A. I used Debian Bullseye's weekly installer to boot up my machine and > chose Rescue mode. As this is a fresh installation, why don't you just wipe everything linux partitions and install again the way you want it. Alternatively boot into a usb or live cd or installer, mount the volumes and chroot into (there are many howtos) I use something like following where SYSTEM is the target ppath mount --make-unbindable -obind /proc/ $SYSTEM/proc/ && \ mount --make-unbindable -obind /dev/ $SYSTEM/dev/ && \ mount --make-unbindable -obind /dev/pts $SYSTEM/dev/pts && \ mount --make-unbindable -obind /run $SYSTEM/run && \ mount --make-unbindable -obind /sys $SYSTEM/sys/ && \ chroot $SYSTEM su - when you are there reinstall grub and run update-grub I hope this helps
Re: How do I get back the GRUB menu with the blue background?
Hi 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 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 Ok. > 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: https://www.gnu.org/software/grub/manual/grub/html_node/Naming-convention.html#Naming-convention 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
How do I get back the GRUB menu with the blue background?
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: 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) After reading some stuff on the internet, please tell me if my understanding of the following is correct: Grub's UEFI Stub is located in EFI System Partition (ESP) while its second stage modules are in the /boot partition. /boot also contains Grub's config file. It would appear that the bootloader in ESP is not updated to match the modules in the /boot partition or it could be that /boot/grub/grub.cfg is missing. Below's my attempt at getting back the Grub menu with the blue background: A. I used Debian Bullseye's weekly installer to boot up my machine and chose Rescue mode. B. After entering the encrypted passphrase, below were some relevant messages on the screen: [beginning of message] Enter a device you wish to use as your root file system. Device to use as root file system: /dev/perfect-vg/root /dev/perfect-vg/swap /dev/dm-1 /dev/dm-2 /dev/mapper/sda3_crypt /dev/sda1 /dev/sda2 etc, etc Assemble a RAID system Do not use a root file system [end of message] I highlighted /dev/sda1 and pressed Enter. I was given four choices one of which was to Execute a shell in the installer environment. I highlighted it and pressed Enter. There was a message on the screen stating that /dev/sda1 would be mounted as "/target", that the tools of the installer environment would be available for use and that I could use chroot to "chroot /target". There was a small grey box at the bottom of the screen. I tried the following options: ~# "chroot /target" /bin/sh: "chroot /target" not found ~# chroot /target chroot: can't execute "/bin/sh". No such file or directory ~# apt install --reinstall grub-efi /bin/sh: apt: not found I am stuck with the above as my technical knowledge of Linux is limited and appreciate your help with the above matter.
