Grub trashed after Win-10 2004 "feature" update

The Manjaro Grub boot loader got “trashed” on my system after the latest Win10 (2004) update. I wonder if anyone else had this problem. I was able to “repair” grub using a generic (non Manjaro) procedure. However I’m (pleasantly) surprised it worked, since my boot disk (and partitions) is an “nvme0n1p5” and I installed the new-grub on /dev/sda. I am NOT a linux (or Manjaro) expert and used a standard Ubuntu/Mint recovery process. The system is a dual boot UEFI box with an SSD system disk (split for Win10 and Manjaro/KDE) and a split HDD for data partitions. When I set up the system I followed the procedures for setting up a Win10/Manjaro dual boot UEFI system with the recommended partitioning scheme. It always booted fine…until the Win10-2004 update was applied. Then just “grub rescue” prompt. I Once I located the Manjaro root partition via a series of “ls” commands I performed the following steps:
(1) set prefix=(hd2,gpt6)/boot/grub
(2) set root=(hd2,gpt6)
(3) ls /
(4) insmod normal
(5) normal
(6) boot into Manjaro
(7) sudo update-grub
(8) sudo grub-install /dev/sda
(9) close terminal window and re-boot. Is there a better (and simpler) way to recovery from this ?

Welcome at the forum, @WalterNeff

These two statementents are disturbing. The command grub-install /dev/sda is installing grub in the MBR for BIOS systems and totally unappropriate for an UEFI sytem with a gpt parted disk.

https://wiki.manjaro.org/index.php?title=GRUB/Restore_the_GRUB_Bootloader

Please provide output of

sudo parted -l
efibootmgr -v
ls -la /boot
1 Like

If you installed grub with the command sudo grub-install /dev/sda/ then you are using CSM mode (BIOS/MBR mode). This kind of thing is probably going to happen with every feature update of Windows.

The other option to fix when it happens is to boot from a Manjaro installation USB, chroot your system (i.e manjaro-choot -a) and reinstall grub from there.

With UEFI is a little bit easier. Windows feature update is still going to change the default boot entry to itself. But you can just select the Manjaro entry in EFI boot menu to boot to your Manjaro and fix the thing

1 Like

Your problem probably comes from a firmware setting - enabling CSM or BIOS/MBR boot.

Such setting will almost always result in Manjaro being installed in BIOS/MBR mode.

The recommended path is to disable CSM - never revert to CSM - install Manjaro - assign a separate EFI partition for Manjaro - then Windows can do what ever they feel like. The worst which can then happen is Windows changing the boot order in the firmware.

Addendum: first of all I don’t think the 2004 update caused this. I think I DID when I told windows to clean out temp files. (??). So the end result is now that “boot/efi” is now tagged onto the 100 meg Win10 boot part and my dedicated 512 boot part is dormant. I should have studied the Wiki procedures…FIRST. My bad.

sudo parted -l:

Model: ATA WDC WD10EZEX-22M (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 465GB 465GB ntfs Basic data partition msftdata
2 465GB 1000GB 535GB ext4 Linux Data partition

Model: Samsung SSD 970 EVO Plus 250GB (nvme)
Disk /dev/nvme0n1: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 154GB 154GB ntfs msftdata
2 154GB 154GB 537MB ntfs hidden, diag
3 154GB 163GB 8590MB linux-swap(v1) swap
4 163GB 163GB 105MB fat32 boot, esp
5 163GB 164GB 537MB fat32 msftdata
6 164GB 217GB 53.7GB ext4
7 217GB 250GB 32.8GB ext4

efibootmgr -v:

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0004,0000
Boot0000* Windows Boot Manager HD(4,GPT,7664fa8f-4072-11ea-9d92-c89cdd3d0d24,0x12f77000,0x32000)/File(\E
FI\MICROSOFT\BOOT\BOOTMGFW.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.}…
Boot0001* manjaro HD(5,GPT,d675279f-72e8-44c6-8713-b90e6e7c5382,0x12fa9000,0x100000)/File(\EFI\MANJ
ARO\GRUBX64.EFI)
Boot0004* UEFI OS HD(5,GPT,d675279f-72e8-44c6-8713-b90e6e7c5382,0x12fa9000,0x100000)/File(\EFI\BOOT
\BOOTX64.EFI)…BO

ls -la /boot :

total 143276
drwxr-xr-x 5 root root 4096 Aug 28 09:07 .
drwxr-xr-x 19 root root 4096 Aug 21 11:50 …
drwx------ 4 root root 4096 Dec 31 1969 efi
drwxr-xr-x 5 root root 4096 Aug 29 16:14 grub
-rw-r–r-- 1 root root 31556172 Aug 28 09:07 initramfs-5.4-x86_64-fallback.img
-rw-r–r-- 1 root root 9840430 Aug 28 09:06 initramfs-5.4-x86_64.img
-rw-r–r-- 1 root root 31553780 Aug 28 09:07 initramfs-5.7-x86_64-fallback.img
-rw-r–r-- 1 root root 9484798 Aug 28 09:07 initramfs-5.7-x86_64.img
-rw-r–r-- 1 root root 31636588 Aug 28 09:07 initramfs-5.8-x86_64-fallback.img
-rw-r–r-- 1 root root 9494917 Aug 28 09:07 initramfs-5.8-x86_64.img
-rw-r–r-- 1 root root 3161088 Jun 16 12:50 intel-ucode.img
-rw-r–r-- 1 root root 21 Aug 22 09:34 linux54-x86_64.kver
-rw-r–r-- 1 root root 21 Aug 22 09:57 linux57-x86_64.kver
-rw-r–r-- 1 root root 20 Aug 22 07:34 linux58-x86_64.kver
drwxr-xr-x 2 root root 4096 May 31 09:38 memtest86+
-rw-r–r-- 1 root root 6494528 Aug 28 09:06 vmlinuz-5.4-x86_64
-rw-r–r-- 1 root root 6681184 Aug 28 09:06 vmlinuz-5.7-x86_64
-rw-r–r-- 1 root root 6751936 Aug 28 09:06 vmlinuz-5.8-x86_64

I totally agree…I don’t understand why the system is booting into the menu normally. I DO know that its using the Win10 boot parition since the old 512 /efi/boot partion is now tagged as “msftdata”.

I think you were lucky that this command did most likely just overwrote only the MBR (with boot.img) and sectors #34ff (with core.img) [both no problem for gpt]. The UEFI firmware ignored the content, anyhow.

If from your three efi entries 0001, 0004, 0000 only two are working I would delete the one not being needed to avoid confusion, later-on.

It seems that the “Boot004” entry is bogus. It doesn’t show up in the Grub Menu but DOES show up in the BIOS boot priority list. How do I get rid of it ?
Ultimately I would like to restore the original /UEFI/BOOT partition and restore all this “boot stuff” back to the way it was. Can I even do that safely ?
Thanks for those commands. They helped me understand things a bit better.

The exact syntax can be deducted from the manual of efibootmgr:

man efibootmgr

https://linux.die.net/man/8/efibootmgr

Removing orphaned entries is safe.

Example (edited):

efibootmgr -b 0004 -B

would remove boot entry 0004.

No, to delete an entry you select it with -b NUM and delete it with -B:

sudo efibootmgr -b 4 -B
1 Like

Are you sure? I have no efi partition so I cannot test it but acc. to the referenced manual -B xxxx is a vaild syntax… :thinking:

Yeah, I’m sure. If you look closely, -b parameter has a value, while -B doesn’t

I’m sure you are right, I was just assuming the synopsis allows a value for -B:

Must be a typo. In the options part it is without value.

Anyway I know this just because I literally did it yesterday and first I tried your way and when it failed I have to put it the other way :smile:

Fact check: This is true.

So how is the new grub installed ? I looked in part #4 (via windows) which got flagged with boot,esp (that used to be part. #5…now its msftdata) but there are only 2 dirs. /boot and /Microsoft (No Manjaro). Also the bogus “Boot004” entry just takes me to Grub Rescue. The BIOS entries just show Boot0001 (Manjaro) and Boot0004 (Grub rescue). No win10. Yet the Grub Menu has an entry for “Windows Boot Manager” (which boots Win10). Did I create some UEFI/MBR hybrid here ? My guess is that if I ever want to re-set and re-build the UEFI/Boot properly I’ll need to get rid of the “mystery grub” first, re-build the 512M (boot, esp) part. and re-install grub via the Wiki. instructions.

It’s still a bit unclear what your specific procedure of fixing grub did to your system.

You have Windoze and Manjaro on the same disk but it seems you have two efi partitions, this is in principle a good starting point if one is dedicated to Windoze and one dedicated to Manjaro as in this case it reduces the risk Windoze updates could damage your Manjaro grub install. The boot and efi flag should be set to the efi partition you are using for booting. To make it a bit easier maybe try to eliminate efi entries which are no longer relevant.

As long as you can boot Windoze from Manjaro’s grub I won’t touch the system as it seems to be OK, then. When a future update of Windoze makes problems you normally can restore grub bootloader from a live iso, this is not too difficult, there is a tutorial here in the forum.