Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
[Solved] Bizarre Grub bootloader issues
[Solved] Bizarre Grub bootloader issues
I've been having this problem recently on my debian bullseye installation where in some instances, the grub rescue menu would show up instead of the usual grub. I have used multiple tutorials: https://www.linuxfoundation.org/blog/bl ... 2-on-linux, https://phoenixnap.com/kb/grub-rescue and https://youtu.be/r7meKJsjqfY to try fixing the issue but none seem to work as important commands like the insmod and setting root/loading the kernel all seem to fail(shown in the screenshots). The bizarre thing about this issue is also the fact that it doesn't always happens, perhaps it happens maybe 4 out of 10 times I boot up my system and after failing to solve it through the tutorial methods, I've found that simply restarting my computer once the rescue screen shows up seems to have a chance of making it go away and to load the correct grub. For context, my computer is a dual boot system with windows and now debian on 2 separate hard drives(the one debian resides in is hd0) with an efi partition on each. When I used manjaro a while ago, I installed it the same way as I installed debian and yet only debian seems to have this issue. I am at my wit's end on any solutions as I cannot find any problems similar to mine online and I do not want to give up on debian yet as I am loving it, but it makes me very nervous that my system could suddenly not just boot while I need it for an emergency. I hope I do not have to go back to manjaro/arch again.**inxi + neofetch information screenshots and my grub rescue attempt shown below**
Last edited by adrit123 on 2023-01-09 03:24, edited 3 times in total.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Bizarre Grub bootloader issues
What do you mean by "grub rescue menu" ? What happens exactly ?
The screenshot does not show any grub rescue shell nor menu, only the normal grub shell.
Re: Bizarre Grub bootloader issues
When I boot up my computer sometimes the normal grub shows up but other times the grub shell rescue as shown in the first screenshot appears instead. It is bizarre because it doesn't always happen and yet it does and my solution thus far has always been to restart the computer until the normal grub shows up, I know it is not a permanent solution but I don't know what the problem is.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Bizarre Grub bootloader issues
You are only repeating without providing more information instead of describing exactly what happens on the screen before you typed anything. So I will repeat too: the screenshot does not show a GRUB rescue shell, so your description is inaccurate. The GRUB rescue shell would print the prompt "grub rescue>" instead of the normal prompt "grub>". Also the rescue shell would not have a graphic background picture, unless you manually reverted from normal mode to rescue mode with the command "normal_exit".
Re: Bizarre Grub bootloader issues
Oh, sorry about that I did not know there was a difference as the tutorials I watched to fix the issue all refer it is a "grub rescue". Regardless by your description it is not a grub rescue shell as there is no grub rescue> in the prompt however the text on top says "Minimal bash line scripting is supported" similar to the tutorials I linked. To provide more information, I will attach photos of my lsblk information. For context, my windows is installed on the nvme drive, while debian is on the sda drive. Each drive has an efi system partition(nvme's is nvme0n1) while the sda's is /dev/sda1 which is where grub is installed, however I did notice that /dev/sda1 is not mounted by default.p.H wrote: ↑2023-01-04 07:37You are only repeating without providing more information instead of describing exactly what happens on the screen before you typed anything. So I will repeat too: the screenshot does not show a GRUB rescue shell, so your description is inaccurate. The GRUB rescue shell would print the prompt "grub rescue>" instead of the normal prompt "grub>". Also the rescue shell would not have a graphic background picture, unless you manually reverted from normal mode to rescue mode with the command "normal_exit".
Last edited by adrit123 on 2023-01-04 08:59, edited 3 times in total.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Bizarre Grub bootloader issues
/tmp should not be used as a temporary mount point. Use /mnt instead.
Can you post plain text from the console by copy and paste instead of screenshots ?
/dev/sda1 instead of /dev/nvme0n1p1 should be mounted on /boot/efi. Compare /etc/fstab and the output of blkid. Mounting the wrong EFI partition on /boot/efi does not disrupt the boot process (it does not even have to be mounted for normal operation) but it will cause trouble when reinstalling GRUB after a package update.
When GRUB boots normally and displays the menu, press "c" to launch the shell, run "set" and note the values of $cmdpath and $prefix.
When GRUB does not boot normally and lauches the shell by itself, do the same and compare with the previous values.
If $prefix is different, set it to the exact same value.
Run
Can you post plain text from the console by copy and paste instead of screenshots ?
/dev/sda1 instead of /dev/nvme0n1p1 should be mounted on /boot/efi. Compare /etc/fstab and the output of blkid. Mounting the wrong EFI partition on /boot/efi does not disrupt the boot process (it does not even have to be mounted for normal operation) but it will cause trouble when reinstalling GRUB after a package update.
When GRUB boots normally and displays the menu, press "c" to launch the shell, run "set" and note the values of $cmdpath and $prefix.
When GRUB does not boot normally and lauches the shell by itself, do the same and compare with the previous values.
If $prefix is different, set it to the exact same value.
Run
Code: Select all
configfile $prefix/grub.cfg
Last edited by p.H on 2023-01-04 19:46, edited 1 time in total.
Re: Bizarre Grub bootloader issues
I have edited my /etc/fstab to mount /dev/sda1 on /boot/efi:p.H wrote: ↑2023-01-04 13:31 /tmp should not be used as a temporary mount point. Use /mnt instead.
Can you post plain text from the console by copy and paste instead of screenshots ?
/dev/sda1 instead of /dev/nvme0n1p1 should be mounted on /boot/efi. Compare /etc/fstab and the output of blkid. Mounting the wrong EFI partition on /boot/efi does not disrupt the boot process (it does not even have to be mounted for normal operation) but it will cause trouble when reinstalling GRUB after a package update.
When GRUB boots normally and displays the menu, press "c" to launch the shell, run "set" and note the values of $cmdpath and $prefix.
When GRUB does not boot normally and lauches the shell by itself, do the same and compare with the previous values.
If $prefix is different, set it to the exact same value.
RunCode: Select all
source $prefix/grub.cfg
Code: Select all
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 476.9G 0 disk
├─sda1 8:1 0 476M 0 part /boot/efi
├─sda2 8:2 0 14.9G 0 part [SWAP]
├─sda3 8:3 0 279.4G 0 part /home
└─sda4 8:4 0 111.8G 0 part /
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 250M 0 part
├─nvme0n1p2 259:2 0 128M 0 part
├─nvme0n1p3 259:3 0 308G 0 part
├─nvme0n1p4 259:4 0 50G 0 part
├─nvme0n1p5 259:5 0 990M 0 part
├─nvme0n1p6 259:6 0 16G 0 part
└─nvme0n1p7 259:7 0 1.5G 0 part
Code: Select all
objdump --section=.sbat --full-contents bootx64.efi
Code: Select all
Contents of section .sbat:
d3000 73626174 2c312c53 42415420 56657273 sbat,1,SBAT Vers
d3010 696f6e2c 73626174 2c312c68 74747073 ion,sbat,1,https
d3020 3a2f2f67 69746875 622e636f 6d2f7268 ://github.com/rh
d3030 626f6f74 2f736869 6d2f626c 6f622f6d boot/shim/blob/m
d3040 61696e2f 53424154 2e6d640a 7368696d ain/SBAT.md.shim
d3050 2c312c55 45464920 7368696d 2c736869 ,1,UEFI shim,shi
d3060 6d2c312c 68747470 733a2f2f 67697468 m,1,https://gith
d3070 75622e63 6f6d2f72 68626f6f 742f7368 ub.com/rhboot/sh
d3080 696d0a73 68696d2e 7562756e 74752c31 im.shim.ubuntu,1
d3090 2c556275 6e74752c 7368696d 2c31352e ,Ubuntu,shim,15.
d30a0 342d3075 62756e74 75392c68 74747073 4-0ubuntu9,https
d30b0 3a2f2f77 77772e75 62756e74 752e636f ://www.ubuntu.co
d30c0 6d2f0a
Last edited by adrit123 on 2023-01-04 15:28, edited 1 time in total.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Bizarre Grub bootloader issues
image1.jpg shows the expected output when GRUB did not load its main config file /boot/grub/grub.cfg : default font, no background picture, black background. The only unusual part is the line "error: Command failed." after the output of "set".
Conversely, image0.jpg shows the expected output when GRUB loaded the standard main config file : unicode font, background picture. There are more environment variables because the new ones are created by the config file.
The screenshot in the original post puzzles me because it shows a background picture and text in unicode font as if the config file was loaded, but not the new variables and values set by it.
Suggesting to using the "source" command was a mistake because it won't show the menu even if the file is successfully loaded. The "configfile" command should be used instead. Also you can type some commands to check the config file can be read :
I do not think that the remaining Ubuntu files in the EFI partition of the NVMe SSD is relevant here, because it is always Debian's GRUB which is launched.
Conversely, image0.jpg shows the expected output when GRUB loaded the standard main config file : unicode font, background picture. There are more environment variables because the new ones are created by the config file.
The screenshot in the original post puzzles me because it shows a background picture and text in unicode font as if the config file was loaded, but not the new variables and values set by it.
Suggesting to using the "source" command was a mistake because it won't show the menu even if the file is successfully loaded. The "configfile" command should be used instead. Also you can type some commands to check the config file can be read :
Code: Select all
ls $prefix/
cat $prefix/grub.cfg
Re: Bizarre Grub bootloader issues
The ls $prefix/ command shows:
I have also attached a pastebin of the results of the bootinfoscript which includes the information shown by the $prefix/grub.cfg and more: app.php/pastebin/?mode=view&s=11.
From asking other forums, I have been told that the reason behind this problem could be due to having 2 EFI partitions on separate disks, causing bios to be confused as it randomly loads one on every boot, in this case would I need to delete one of the partitions and move grub to the other one? I also have to mention that when I first installed debian with the unofficial live cd version, I did not know about booting the live cd in uefi mode, so could that also be a source of error?
Code: Select all
x_86_64-efi/ locale/ fonts/ unicode.pf2 grubenv grub.cfg
From asking other forums, I have been told that the reason behind this problem could be due to having 2 EFI partitions on separate disks, causing bios to be confused as it randomly loads one on every boot, in this case would I need to delete one of the partitions and move grub to the other one? I also have to mention that when I first installed debian with the unofficial live cd version, I did not know about booting the live cd in uefi mode, so could that also be a source of error?
Re: Bizarre Grub bootloader issues
After deleting the efi partition from the /dev/sda drive, the stubborn issue still persists, I do not know what the problem is but I am wondering if it could be due to the way the system was installed or perhaps debian itself does not work well on my hardware.
Re: Bizarre Grub bootloader issues
Update to the situation: With the suggestions of some forums, I moved back grub and all the bootloader information back to the nvme0n1 drive and deleted the efi partition on the sda drive to ensure only one efi partition exists across both drives. However, the issue still persists. The good news is I have made a new discovery, when the shell screen shows up, I found out that if I typed "exit" the usual grub screen will pop up and the shell prompt will exit. This has brought me a little relief but the shell popping up in the first place at random still is an issue.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Bizarre Grub bootloader issues
It shows grub.cfg, so what about the next suggested commands (cat and configfile on $prefix/grub.cfg) or "normal" ?
I do not see anything suspicious in the bootinfoscript report.
It was unlikely that the dual EFI partitions caused the issue. All available information show that GRUB is launched from the correct location.
The GRUB menu ? "exit" terminates GRUB, and the UEFI firmware selects another boot loader. It is a bit weird that GRUB is selected again. What is the output of "efibootmgr -v" in Debian ?
Re: Bizarre Grub bootloader issues
Efibootmgr -v displays:p.H wrote: ↑2023-01-05 22:26It shows grub.cfg, so what about the next suggested commands (cat and configfile on $prefix/grub.cfg) or "normal" ?
I do not see anything suspicious in the bootinfoscript report.
It was unlikely that the dual EFI partitions caused the issue. All available information show that GRUB is launched from the correct location.The GRUB menu ? "exit" terminates GRUB, and the UEFI firmware selects another boot loader. It is a bit weird that GRUB is selected again. What is the output of "efibootmgr -v" in Debian ?
Code: Select all
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,0000
Boot0000* UEFI BC511 NVMe SK hynix 512GB CN05N917313305T0E 1 PciRoot(0x0)/Pci(0x1d,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,68fb3aaf-45e8-4bbd-bb44-87c445b9b84c,0x800,0x7d000)/File(\EFI\Boot\BootX64.efi)N.....YM....R,Y.
Boot0001* debian HD(1,GPT,68fb3aaf-45e8-4bbd-bb44-87c445b9b84c,0x800,0x7d000)/File(EFI\debian\grubx64.efi)
Boot0002* Windows Boot Manager HD(1,GPT,68fb3aaf-45e8-4bbd-bb44-87c445b9b84c,0x800,0x7d000)/File(\Efi\debian\grubx64.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Bizarre Grub bootloader issues
The next boot entry ("Windows boot manager") also points to /efi/debian/grubx64.efi, this explains why GRUB is run again after exit.
However the Debian and Windows boot entries are not normal. The Debian entry should point to /efi/debian/shimx64.efi if grub-efi-amd64-signed and shim-signed arer installed, which is the default, and the Windows entry should point to /efi/microsoft/boot/bootmgfw.efi. Did you mess with EFI boot entries and/or bcdedit under Windows ?
PS. Please do not quote the whole previous post, it is useless and wastes space.
However the Debian and Windows boot entries are not normal. The Debian entry should point to /efi/debian/shimx64.efi if grub-efi-amd64-signed and shim-signed arer installed, which is the default, and the Windows entry should point to /efi/microsoft/boot/bootmgfw.efi. Did you mess with EFI boot entries and/or bcdedit under Windows ?
PS. Please do not quote the whole previous post, it is useless and wastes space.
Re: Bizarre Grub bootloader issues
Yes i did edit the efi boot entry for debian and changed the bcdedit boot order for the windows boot entry. How should I change them to be correct?
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Bizarre Grub bootloader issues
Note that using grubx64.efi in boot entries won't work if secure boot is enabled unless you added Debian's key to the firmware allowed list. grubx64.efi is signed with Debian's key so boot entries must point to shimx64.efi which is signed with Microsoft's key, the only one allowed by most UEFI firmwares by default. Then shimx64.efi will load grubx64.efi and check Debians's signature. If secure boot is disabled you do not have to bother about it, booting directly with grubx64.efi should work fine.
I guess you can restore the original boot entry for Windows with bcdedit. It will make Windows bootable on its own again without going through the GRUB menu.
You can re-create the proper boot entry for Debian by reinstalling GRUB with "grub-install" (no argument needed).
However I am afraid that neither will fix the issue, and "exit" will not relaunch GRUB any more but launch Windows instead. As for the issue, I have never seen this error message when executing correct commands and have no clue. Just a wild guess, I have seen weird issues caused by the tpm module, so it may be worth a try to remove it and retry to load the menu.
I guess you can restore the original boot entry for Windows with bcdedit. It will make Windows bootable on its own again without going through the GRUB menu.
You can re-create the proper boot entry for Debian by reinstalling GRUB with "grub-install" (no argument needed).
However I am afraid that neither will fix the issue, and "exit" will not relaunch GRUB any more but launch Windows instead. As for the issue, I have never seen this error message when executing correct commands and have no clue. Just a wild guess, I have seen weird issues caused by the tpm module, so it may be worth a try to remove it and retry to load the menu.
Code: Select all
rmmod tpm
configfile /boot/grub/grub.cfg
Re: Bizarre Grub bootloader issues
I typed in rmmod tpm and the configfile commands when the black grub prompt boots up and it changes it to the normal grub, however afterwards I discovered that it may have potentially caused issues such as my wifi to stop working. At this point, I believe Debian on my laptop is far more trouble than its worth and will switch back to either Manjaro or Arch linux. Nonetheless, thank you for being patient and helping me with my problems even if it wasn't fully solved in the end.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: [Solved] Bizarre Grub bootloader issues
I do not see how disabling the tpm module in GRUB would affect the wifi. Maybe the root cause affects both GRUB and the wifi.
If the laptop is very recent (less than ~2 years), maybe Debian stable is too old for it.
You could try installing Arch/Manjaro in dual boot with Arch GRUB as the primary boot loader and test whether
- Arch GRUB has the same issue
- Debian has the wifi issue when booting it from Arch GRUB
If the laptop is very recent (less than ~2 years), maybe Debian stable is too old for it.
You could try installing Arch/Manjaro in dual boot with Arch GRUB as the primary boot loader and test whether
- Arch GRUB has the same issue
- Debian has the wifi issue when booting it from Arch GRUB
Re: [Solved] Bizarre Grub bootloader issues
I have this same issue.
It has been a long chaotic couple of days of trying to solve it and I think it might be a bios issue. Bios is picking up bootmgfw.efi, shimx64.efi and grub64.efi. If you set the entry (say grub64.efi) in the bios it will boot to a normal grub screen and all is well, but on reboot it quite often drops to grubs command line. It is almost like it is rearranging the boot entries (which are both named the same on the bios screen) after boot. Weirdly I have fairly much the same setup as the original poster (1 nvme with w11 on it and an ssd with debian 11 on it). I have had the same problem with efi partitions on both disks and have resorted to using the w11 efi partition but to no avail. I don't use secure boot, although I activated it at one point to see whether I could get it to stick to using shimx64.efi but to no avail.
Personally, I would like to delete shimx64.efi but I haven't been able to find any reference to the effects and that is a little blunt.
Next step is to load D11 using the W11 bootloader and spent some time with my family.
It has been a long chaotic couple of days of trying to solve it and I think it might be a bios issue. Bios is picking up bootmgfw.efi, shimx64.efi and grub64.efi. If you set the entry (say grub64.efi) in the bios it will boot to a normal grub screen and all is well, but on reboot it quite often drops to grubs command line. It is almost like it is rearranging the boot entries (which are both named the same on the bios screen) after boot. Weirdly I have fairly much the same setup as the original poster (1 nvme with w11 on it and an ssd with debian 11 on it). I have had the same problem with efi partitions on both disks and have resorted to using the w11 efi partition but to no avail. I don't use secure boot, although I activated it at one point to see whether I could get it to stick to using shimx64.efi but to no avail.
Personally, I would like to delete shimx64.efi but I haven't been able to find any reference to the effects and that is a little blunt.
Next step is to load D11 using the W11 bootloader and spent some time with my family.
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: [Solved] Bizarre Grub bootloader issues
What do you mean by "picking up" ?
What do you mean by "set the entry in the BIOS" ?
Can you post the output of
Code: Select all
efibootmgr -v
If you suspect shim is the culprit, you can wipe /boot/efi/EFI/debian and reinstall GRUB without shim with
Code: Select all
grub-install --no-uefi-secure-boot
Or you can delete shimx64.efi, delete the EFI boot entry which points to it and replace it with a boot entry pointing to grubx64.efi.
Or rename/move it and replace it with a copy of grubx64.efi renamed as shimx64.efi.