You are not logged in.
I have a dual boot setup with Arch and Windows 11 that has been working without a problem for years. But recently Windows updated to feature version 24H2 and since then, each time I boot Windows, it completely removes the grub EFI entry, so I have to boot from the Arch install medium and reinstall grub. A quick search will reveal this is a common problem with many different suggested solutions, but none I tried works for me. This is what I tried without luck:
1. On Windows, disable System Protection.
2. On Windows disable Fast Startup
3. On Windows use bcdedit to change boot path to where the GRUB EFI binary is (\EFI\Linux\grubx64.efi)
4. On Linux use efibootmgr to disable the Windows boot entry, and then change the boot order so the (disabled) Windows boot entry is the first one.
None of these have worked. My PC has 3 disks, and I suspect Windows might be getting confused about on which disk boot should be stored, and reinstalling it on every boot. Because bcdedit points to Volume3 (sorry for the spanish text):
C:\Windows\System32>bcdedit
Administrador de arranque de Windows
----------------------------------
Identificador {bootmgr}
device partition=\Device\HarddiskVolume3
path \efi\microsoft\boot\bootmgfw.efi
description Windows Boot Manager
locale es-ES
inherit {globalsettings}
default {current}
resumeobject {6c4efd50-1477-11ef-96e4-a405a135b237}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 30
[...]
But it should be on Volume0!:
C:\Windows\System32>diskpart
Microsoft DiskPart versión 10.0.26100.1150
Copyright (C) Microsoft Corporation.
En el equipo: DESKTOP-R8PPA8R
DISKPART> list volume
Núm Volumen Ltr Etiqueta Fs Tipo Tamaño Estado Info
----------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 SYSTEM FAT32 Partición 512 MB Correcto Oculto
Volume 1 C NTFS Partición 222 GB Correcto Arranque
Volume 2 NTFS Partición 675 MB Correcto Oculto
Volume 3 D Steam NTFS Partición 931 GB Correcto
If I try using bcdedit to point the boot manager to Volume0, it refuses, stating "Incompatible request":
C:\Windows\System32>bcdedit /set {bootmgr} device partition=\Device\HarddiskVolume0
Error al establecer los datos del elemento.
Solicitud no compatible.
Anyway I managed to set it by assigning Volume 0 a driver letter using diskpart, and then using bcdedit to set the boot path to that letter, but that did neither work, and on the next Windows boot, the variable was reset to Volume3. So I am out of ideas.
Any suggestion other than deleting Windows?
Offline
couple of possibilities:
as you have several drives - do you have multiple ESP or do you use just one ESP for everything?
how do you boot windows? do you chain it from grub or directly via boot selection from uefi?
what gpt guid is/are the ESP? on linux run
lsblk -f -o +PARTTYPE
how do you recreate the grub entry? do you reinstall grub completely or do you run efibootmgr by hand?
Offline
couple of possibilities:
as you have several drives - do you have multiple ESP or do you use just one ESP for everything?
Single ESP. BTW in my previous post I wrote that I suspect Windows is confused and tries to use Volume3 as boot volume, but that is on a disk with a single partition and no EFI files is copied there.
how do you boot windows? do you chain it from grub or directly via boot selection from uefi?
Tried both approaches, same result, as soon as I boot Windows, the Grub entry is deleted, no matter if I boot from Grub chainloading or directly from the UEFI firmware menu.
what gpt guid is/are the ESP? on linux run
lsblk -f -o +PARTTYPE
I cannot use the machine right now, will post this later.
how do you recreate the grub entry? do you reinstall grub completely or do you run efibootmgr by hand?
I do a full reinstall: boot from the arch install medium, mount partitions (root, boot, home), perform the arch-chroot, and from inside the chroot run:
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=Linux
# grub-mkconfig -o /boot/grub/grub.cfg
I suppose the grub-mkconfig is not needed, but doesn't hurt AFAIK.
Offline
The lsblk:
jalon ~ $ lsblk -f -o +PARTTYPE
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS PARTTYPE
sda
├─sda2 vfat FAT32 SYSTEM 1237-E36C 278,3M 45% /boot c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─sda5 ext4 1.0 0f0cd336-8c57-4cd4-8264-dfe43c8b4824 12,3G 79% / 0fc63daf-8483-4772-8e79-3d69d8477de4
└─sda6 ext4 1.0 f14d9e38-78ee-4494-8ba8-c564a34a3591 108,7G 66% /home 0fc63daf-8483-4772-8e79-3d69d8477de4
sdb
├─sdb1 e3c9e316-0b5c-4db8-817d-f92df00215ae
├─sdb2 ntfs 3270E75870E720F9 ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
└─sdb3 ntfs 5CD2AC0FD2ABEC08 de94bba4-06d1-4d40-a16a-bfd50179d6ac
nvme0n1
├─nvme0n1p1 e3c9e316-0b5c-4db8-817d-f92df00215ae
└─nvme0n1p2 ntfs Steam 5E947A3D947A17AB ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Linux is installed on sda, Windows on sdb, and there's also nvme0n1 that is shared for Windows and Linux and has mostly Steam games.
Offline
so with only one esp on the linux drive it make sense that windows sees it as a different drive number - because same as with windows drive specifiers are not fixed: on linux sda and sdb can swap at every boot
on windows the drive numbers can be different at each boot (the only guaranteed is that the system drive will be drive letter C)
a possible issue could be that you boot across drive boundaries - but both grub and windows should be able to deal with that
please post the outout of
efibootmgr -vu
after installing grub with working boot entry and again after "removed" entry after windows boot - I'm curious if the boot entry gets deleted or just reordered
Offline
I suppose the '-u' switch above is a typo (at least my efibootmgr complains when I put it), so this is with only '-v':
jalon ~ $ efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001
Boot0000* Linux HD(2,GPT,370bee85-c904-432b-925b-97a2fd4b41ce,0x800,0x100000)/\EFI\LINUX\GRUBX64.EFI
dp: 04 01 2a 00 02 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 85 ee 0b 37 04 c9 2b 43 92 5b 97 a2 fd 4b 41 ce 02 02 / 04 04 32 00 5c 00 45 00 46 00 49 00 5c 00 4c 00 49 00 4e 00 55 00 58 00 5c 00 47 00 52 00 55 00 42 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
Boot0001* Windows Boot Manager HD(2,GPT,370bee85-c904-432b-925b-97a2fd4b41ce,0x800,0x100000)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI0000424f
dp: 04 01 2a 00 02 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 85 ee 0b 37 04 c9 2b 43 92 5b 97 a2 fd 4b 41 ce 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 49 00 43 00 52 00 4f 00 53 00 4f 00 46 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 4d 00 47 00 46 00 57 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
And this is after Windows removes the grub entry (note the two "Lexar USB..." are from the Ventoy stick I use to boot Arch install medium):
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0001,0002,0003
Boot0001* Windows Boot Manager HD(2,GPT,370bee85-c904-432b-925b-97a2fd4b41ce,0x800,0x100000)/\EFI\Microsoft\Boot\bootmgfw.efi0000424f
dp: 04 01 2a 00 02 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 85 ee 0b 37 04 c9 2b 43 92 5b 97 a2 fd 4b 41 ce 02 02 / 04 04 46 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 66 00 74 00 5c 00 42 00 6f 00 6f 00 74 00 5c 00 62 00 6f 00 6f 00 74 00 6d 00 67 00 66 00 77 00 2e 00 65 00 66 00 69 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot0002* UEFI: Lexar USB Flash Drive 3.00, Partition 1 PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(1,0)/HD(1,MBR,0xc0eee9e6,0x800,0x732b800)0000424f
dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 02 01 / 01 01 06 00 00 00 / 01 01 06 00 00 08 / 01 01 06 00 03 00 / 03 05 06 00 01 00 / 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 b8 32 07 00 00 00 00 e6 e9 ee c0 00 00 00 00 00 00 00 00 00 00 00 00 01 01 / 7f ff 04 00
data: 00 00 42 4f
Boot0003* UEFI: Lexar USB Flash Drive 3.00, Partition 2 PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x8,0x0)/Pci(0x0,0x3)/USB(1,0)/HD(2,MBR,0xc0eee9e6,0x732c000,0x10000)0000424f
dp: 02 01 0c 00 d0 41 03 0a 00 00 00 00 / 01 01 06 00 02 01 / 01 01 06 00 00 00 / 01 01 06 00 00 08 / 01 01 06 00 03 00 / 03 05 06 00 01 00 / 04 01 2a 00 02 00 00 00 00 c0 32 07 00 00 00 00 00 00 01 00 00 00 00 00 e6 e9 ee c0 00 00 00 00 00 00 00 00 00 00 00 00 01 01 / 7f ff 04 00
data: 00 00 42 4f
Offline
No, -u was not a typo, and -v is now default, so efibootmgr -u is what they were wanting, but the info is there anyway, so no need to repost.
Offline
I have arch and win10 on the same drive with a shared esp and chain windows from grub
and although windows keeps re-adding itself to both the boot entries as well as the fallback path ESP/efi/boot/bootx64.efi it does not touch the grub entry
a possible idea that forms in my head: as you use a shared esp but across multiple drives it could be that either some stuff during early boot or later at userland modifies some settings - but its hard to tell if its windows doing that or something within the uefi implementation
from the given layout there seem no easy way to add an esp to the windows drive without dealing with partition and filesystem resizing
Offline
This is quite frustrating, because this setup has been working for years (until the 24H2 update), and none of the solutions I have seen in many post with the same or similar issue work.
About if it is Windows or something in the UEFI implementation, it is in fact hard to know for sure, but as this has been triggered by a Windows update...
BTW in case it helps, the motherboard is an Asus Prime X570-P
Offline
Hi.
I stumbled upon your post in quite a hectic attempt to fix this annoying issue. I reply (for myself in the future, or maybe it'll help someone with the same problem).
My case was more dramatic, because I decided to give Grub2Win a try and it died during installation (possibly due to files conflicts, because I had regular Grub installed already)
leaving my laptop with "disk error" .
I booted to Windows from bios using /EFI/Boot/bootx64.efi file and started experimenting with bcedit.exe. I found that Grub2Win was modifying {bootmgr}
path to it's own and it was booting Grub2Win each time, so I set {bootmgr} path to \grub\x86_64-efi\grub.efi' (from my EFI partition) and it always starts Grub now, which has chainloading of Windows boot manager
added by os-prober:
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows --class os $menuentry_id_option 'osprober-efi-0A30-68DA' {
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root 0A30-68DA
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
Seems to work. Don't know for how long, might be till the next Windows update
Offline
I did experience the same problem after upgrading Windows to 24H2.
I am dual booting Arch and Windows 11, each system having their own physical disk with its own ESP. When I installed 24H2, the Windows disk ESP contained only the files for booting Windows, and the Arch ESP only the file for grub.
What finally made the Arch entry survive Windows reboots was copying the files from the Windows ESP to the Arch ESP.
See https://superuser.com/questions/1885003 … fi/1885141 details.
Offline
Never trust Windows. Use separate disks.
Offline
Never trust Windows. Use separate disks.
Use separate computers... unfortunately this issue occurs even with separate disks and all.
As for the exact circumstances, it's unclear... it's not like you can check Windows sourcecode to figure it out either.
The linked solution... is still quite mysterious, it should not change anything at all, but who knows what Windows is doing there.
If consolidating EFI partitions is the solution, then perhaps using separate disks is the problem (for Windows, anyway).
Offline
FossLover wrote:Never trust Windows. Use separate disks.
Use separate computers... unfortunately this issue occurs even with separate disks and all.
As for the exact circumstances, it's unclear... it's not like you can check Windows sourcecode to figure it out either.
The linked solution... is still quite mysterious, it should not change anything at all, but who knows what Windows is doing there.
If consolidating EFI partitions is the solution, then perhaps using separate disks is the problem (for Windows, anyway).
You're right. But for someone who has to use Adobe Premiere Pro or After Effects, this doesn't seem like a viable suggestion. I think at this point, Arch developers need to take concrete steps regarding signatures, just like in Fedora and Debian-based distros.
Offline
Arch developers need to take concrete steps regarding signatures
That has nothing to do with the OP. And I disagree
Jin, Jîyan, Azadî
Offline
Since he starts removing the boot entry windows i change completely my laptop setup and i use only Arch,
Offline