@computersavvy, how might one ascertain whether they do? (One of those URIs is 404.) I ask because my brother’s GRUB2 contains it, but mine doesn’t.
Hey @rokejulianlockhart - This might not fully answer your question but my guess is that dead link probably pointed to something like what is now this Fedora doc on using Grub2:
Regarding how to check for multiple EFI partitions, you might be able to just get away with running something like:
sudo blkid
or
lsblk
And looking for mount points with EFI in their names or EFI mentioned in their labels. There’s probably a more concrete way of identifying them, but maybe this helps you.
You could try sudo fdisk -l | grep "EFI System"
I think fdisk uses the type code in the GPT partition table to determine the type it reports - so when it sees C12A7328-F81F-11D2-BA4B-00A0C93EC93B it tells you you have an “EFI System” partition, which is also how the UEFI firmware should identify them.
You also can run lsblk -f which will show something like this.
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
├─nvme0n1p1 vfat FAT16 52B5-5EC4 315.5M 6% /boot/efi
The FSTYPE vfat and FSVER of fat16 with the UUID as XXXX-XXXX should imply it is an ESP.
I don’t think that is correct. The UUID should be unique (both partition UUID and file system UUID), especially when there are multiple ESPs on a single system. Fdisk does clearly show the EFI System partition.
As I say, this is the type code of the partition, not the thing that we usually call “partition UUID”.
In the terminology of the GPT spec, I’m talking about the PartitionTypeGUID, not the UniquePartitionGUID.
That’s a reasonable heuristic, but not guaranteed. It’s unusual these days to use FAT16 partitions for purposes other than the ESP, but nothing in principle stops you having a FAT16 partition for regular file storage, in which case its GPT type code would be something other than C12A7328-F81F-11D2-BA4B-00A0C93EC93B and the UEFI firmware wouldn’t treat it as an EFI system partition.
@pg-tips, via that method, I appear to solely have one.
Because you’re all obviously very knowledgeable about this (and the title), could someone point me to the official and/or most accurate documentation on how to restore the Windows Boot Loader entry to GRUB2’s TUI when solely one EFI partition exists?
I understand how to rebuild the EFI entry:
However, GRUB2 doesn’t appear to locate it, despite me having enabled OSProber:
GRUB_TIMEOUT="15" # Original: GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT="saved"
GRUB_DISABLE_SUBMENU="true"
GRUB_TERMINAL_OUTPUT="gfxterm" # Original: GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="" # Original: GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="false" # Original: GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG="true"
GRUB_GFXMODE="2560x1440,auto"
GRUB_DISABLE_OS_PROBER="false"
Perhaps, the undermentioned is relevant?
RokeJulianLockhart@Beedell:~$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg [sudo] password for RokeJulianLockhart: Generating grub configuration file ... error: ../grub-core/disk/diskfilter.c:530:invalid volume. error: ../grub-core/disk/diskfilter.c:530:invalid volume. error: ../grub-core/disk/diskfilter.c:530:invalid volume. error: ../grub-core/disk/diskfilter.c:530:invalid volume. error: ../grub-core/disk/diskfilter.c:530:invalid volume. error: ../grub-core/disk/diskfilter.c:530:invalid volume. Adding boot menu entry for UEFI Firmware Settings ... done
If this is a little too off-topic, I’ll ask to have it split.
@rokejulianlockhart - Is this the section you need?
Adding other operating systems to the GRUB2 menu
In my experience, it automagically picks up Windows partitions and adds them as an entry. Just make sure you have os-prober available (which I think is default on Workstation).
My bad, I see you tried that already.
So you already have windows installed?
What is the result of running `sudo ls -R /boot/efi ?
If that shows /boot/efi/EFI/Microsoft then windows “should” be found by grub and bootable.
If not then you may need to do a windows recovery process which should install the necessary efi parts for windows.
The drawback is that doing so probably will wipe out the fedora efi pieces so it likely will be necessary to
- backup your fedora efi data (/boot/efi/EFI/)
- perform the windows recovery
- restore the fedora efi data
- boot to a live media then with chroot restore grub booting.
It may be possible to use efibootmgr for part of that.
@computersavvy, it might: I don’t see either of those terms verbatim, but I’d say that “System Volume Information” would indicate Windows:
/boot/efi: EFI mach_kernel System 'System Volume Information' /boot/efi/EFI: BOOT fedora /boot/efi/EFI/BOOT: BOOTIA32.EFI BOOTX64.EFI fbia32.efi fbx64.efi /boot/efi/EFI/fedora: BOOTIA32.CSV BOOTX64.CSV gcdia32.efi gcdx64.efi grub.cfg grubia32.efi grubx64.efi mmia32.efi mmx64.efi shim.efi shimia32.efi shimx64.efi /boot/efi/System: Library /boot/efi/System/Library: CoreServices /boot/efi/System/Library/CoreServices: SystemVersion.plist '/boot/efi/System Volume Information':
/boot/efi/ ├── EFI │ ├── BOOT │ │ ├── BOOTIA32.EFI │ │ ├── BOOTX64.EFI │ │ ├── fbia32.efi │ │ └── fbx64.efi │ └── fedora │ ├── BOOTIA32.CSV │ ├── BOOTX64.CSV │ ├── gcdia32.efi │ ├── gcdx64.efi │ ├── grub.cfg │ ├── grubia32.efi │ ├── grubx64.efi │ ├── mmia32.efi │ ├── mmx64.efi │ ├── shim.efi │ ├── shimia32.efi │ └── shimx64.efi ├── mach_kernel ├── System │ └── Library │ └── CoreServices │ └── SystemVersion.plist └── System Volume Information 8 directories, 18 files
I believe that what you refer to is what I’ve aforecited. No relevant component, accessible from cmd, should be lower-level than it.
When /boot/efi/EFI/Microsoft is missing it means you MUST perform the recovery procedure for windows. I believe that will require a windows boot/install media.
Yes, the System Volume Information seems to mean that windows was there at some point.
My laptop shows this
$ sudo ls -R /boot/efi
/boot/efi:
EFI mach_kernel System 'System Volume Information'
/boot/efi/EFI:
Boot fedora Microsoft
/boot/efi/EFI/Boot:
BOOTIA32.EFI bootx64.efi fbia32.efi fbx64.efi
/boot/efi/EFI/fedora:
BOOTIA32.CSV gcdia32.efi grub.cfg grubenv.rpmsave grubx64.efi mmx64.efi shimia32.efi
BOOTX64.CSV gcdx64.efi grub.cfg.rpmsave grubia32.efi mmia32.efi shim.efi shimx64.efi
/boot/efi/EFI/Microsoft:
Boot Recovery
/boot/efi/EFI/Microsoft/Boot:
BCD BOOTSTAT.DAT en-US fr-FR kd_02_1137.dll kd_07_1415.dll memtest.efi Resources sv-SE
BCD.LOG boot.stl es-ES hr-HR kd_02_14e4.dll kd_0C_8086.dll nb-NO ro-RO tr-TR
BCD.LOG1 cs-CZ es-MX hu-HU kd_02_15b3.dll kdnet_uart16550.dll nl-NL ru-RU uk-UA
BCD.LOG2 da-DK et-EE it-IT kd_02_1969.dll kdstub.dll pl-PL SecureBootRecovery.efi winsipolicy.p7b
bg-BG de-DE fi-FI ja-JP kd_02_19a2.dll ko-KR pt-BR sk-SK zh-CN
bootmgfw.efi el-GR Fonts kd_02_10df.dll kd_02_1af4.dll lt-LT pt-PT sl-SI zh-TW
bootmgr.efi en-GB fr-CA kd_02_10ec.dll kd_02_8086.dll lv-LV qps-ploc sr-Latn-RS
/boot/efi/EFI/Microsoft/Boot/bg-BG:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/cs-CZ:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/da-DK:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/de-DE:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/el-GR:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/en-GB:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/en-US:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/es-ES:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/es-MX:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/et-EE:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/fi-FI:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/Fonts:
chs_boot.ttf jpn_boot.ttf malgun_boot.ttf meiryo_boot.ttf msjh_boot.ttf msyh_boot.ttf segmono_boot.ttf segoe_slboot.ttf
cht_boot.ttf kor_boot.ttf malgunn_boot.ttf meiryon_boot.ttf msjhn_boot.ttf msyhn_boot.ttf segoen_slboot.ttf wgl4_boot.ttf
/boot/efi/EFI/Microsoft/Boot/fr-CA:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/fr-FR:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/hr-HR:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/hu-HU:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/it-IT:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/ja-JP:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/ko-KR:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/lt-LT:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/lv-LV:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/nb-NO:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/nl-NL:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/pl-PL:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/pt-BR:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/pt-PT:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/qps-ploc:
memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/Resources:
bootres.dll en-US es-ES fr-FR
/boot/efi/EFI/Microsoft/Boot/Resources/en-US:
bootres.dll.mui
/boot/efi/EFI/Microsoft/Boot/Resources/es-ES:
bootres.dll.mui
/boot/efi/EFI/Microsoft/Boot/Resources/fr-FR:
bootres.dll.mui
/boot/efi/EFI/Microsoft/Boot/ro-RO:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/ru-RU:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/sk-SK:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/sl-SI:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/sr-Latn-RS:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/sv-SE:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/tr-TR:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/uk-UA:
bootmgfw.efi.mui bootmgr.efi.mui
/boot/efi/EFI/Microsoft/Boot/zh-CN:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Boot/zh-TW:
bootmgfw.efi.mui bootmgr.efi.mui memtest.efi.mui
/boot/efi/EFI/Microsoft/Recovery:
BCD BCD.LOG BCD.LOG1 BCD.LOG2
/boot/efi/System:
Library
/boot/efi/System/Library:
CoreServices
/boot/efi/System/Library/CoreServices:
SystemVersion.plist
'/boot/efi/System Volume Information':
AadRecoveryPasswordDelete ClientRecoveryPasswordRotation
'/boot/efi/System Volume Information/AadRecoveryPasswordDelete':
'/boot/efi/System Volume Information/ClientRecoveryPasswordRotation':
This is the key part that shows windows is installed, and you are missing Microsoft from that
/boot/efi/EFI:
Boot fedora Microsoft
@computersavvy, I do not see why I need to re-invoke bcdeditbcdboot, if that’s what you mean – the EFI entrant exists in the firmware’s GUI bootloader, so it must exist. I have Windows installed, and accessible. Merely not from GRUB2.
I’m sorry, I understood that windows would not boot.
Do you have another ESP beyond the one that fedora uses?
To find which partition a given boot entry is loading from:
Run efibootmgr
Boot0001* Fedora HD(1,GPT,4c4142d9-4e81-476a-93b5-dbdad8bb5f5a,0x800,0x400000)/\EFI\FEDORA\SHIMX64.EFI
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Notice the partition UUID which is 4c4142d9-4e81-476a-93b5-dbdad8bb5f5a. Find the disk partition for this
by running lsblk -p -o +PARTUUID |grep 4c4142d9-4e81-476a-93b5-dbdad8bb5f5a
which gives
├─/dev/nvme0n1p1 259:1 0 2G 0 part /boot/efi 4c4142d9-4e81-476a-93b5-dbdad8bb5f5a
So this entry is booting from /dev/nvme0n1p1.
You can then mount this partition if it not already mounted and examine its contents.
Running bcdedit won’t help if the Windows boot loader isn’t found in the ESP
unless bcdedit can also populate the ESP with the Windows boot loader files.
@computersavvy, not that I know of. I was under the assumption that what we did previously was to determine that. Some documentation online demonstrates that GRUB2 and the Windows Bootloader can share an ESP, but IDK whether Anaconda or Windows’s installer do so: [1]
@vekruse, I meant bcdboot. Apologies. Was late at night.
That process indeed returns a storage device, which is no surprise:
RokeJulianLockhart@Beedell:~$ efibootmgr
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001
Boot0001* Windows Boot Manager HD(3,GPT,dc82be70-547f-4de3-916a-1dddd961cd43,0x1d025800,0x19f000)/\EFI\Microsoft\Boot\bootmgfw.efi57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000000000100000010000000040000007fff0400
Boot0002* Fedora HD(1,GPT,cead81bf-5334-49fa-94eb-7878bdb2b032,0x800,0x12c000)/\EFI\fedora\shimx64.efi0000424f
RokeJulianLockhart@Beedell:~$ lsblk -p -o +PARTUUID |grep dc82be70-547f-4de3-916a-1dddd961cd43
└─/dev/nvme3n1p3 259:10 0 830M 0 part dc82be70-547f-4de3-916a-1dddd961cd43
However, I knew which storage device Windows was installed on. Should I be searching for something specific? Otherwise, I don’t see much how this helps to get this into GRUB.
Interesting. What does fdisk -l say the type of /dev/nvme3n1p3 is ?
Anaconda does this if you select an existing EFI partition for /boot/efi and don’t reformat the partition.
@pg-tips, very, very weirdly, my disk label type is “DOS” (presumably, for MBR): [1]
-
sudo fdisk -l /dev/nvme3n1p3 -
Disk /dev/nvme3n1p3: 830 MiB, 870318080 bytes, 1699840 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x73736572 Device Boot Start End Sectors Size Id Type /dev/nvme3n1p3p1 1920221984 3736432267 1816210284 866G 72 unknown /dev/nvme3n1p3p2 1936028192 3889681299 1953653108 931.6G 6c unknown /dev/nvme3n1p3p3 0 0 0 0B 0 Empty /dev/nvme3n1p3p4 27722122 27722568 447 223.5K 0 Empty Partition table entries are not in disk order.
I haven’t done anything weird, like enable CSM. fdisk must be incorrect.
Ah. I don’t think I did that. I’ve always selected “I would like to make additional space available”, then “Delete all”. What should I retain, instead?
What I do (not necessarily the only way): choose “Manual Partitioning”, and select the existing EFI partition as the thing that will be mounted as /boot/efi, then make sure it’s not set to be reformatted.
This is using the Everything ISO, so with the old-style Anaconda installer. I guess it’s visually a bit different on the browser-based installer for F42 Workstation.
The fact that you’ve got “sub-partitions” inside /dev/nvme3n1p3 makes me wonder if it’s an extended partition on an MBR disk, with multiple logical partitions inside. It is possible to have a UEFI partition on an MBR disk but it’s a pretty edge-case legacy thing and I’m not sure how you’d end up with this on Windows 11, especially without CSM enabled.
I don’t know for sure, but it wouldn’t surprise me if os-prober just doesn’t support this case.
btw, if you mount /dev/nvme3n1p3p1 and examine the contents, do you see an EFI/Microsoft directory with contents like @computersavvy’s in How to add Windows 11 to GRUB? - #8 ?
You should mount /dev/nvme3n1p3 and examine its contents.
@ph-tips, I’ve tried sudo mkdir /mnt/nvme3n1p3 && sudo mount -o ro /dev/nvme3n1p3p1 /mnt/nvme3n1p3, [1] but it returns:
mount: /mnt/nvme3n1p3: fsconfig system call failed: /dev/nvme3n1p3p1: Can't lookup blockdev.
dmesg(1) may have more information after failed mount system call.
I believe that this means I need to specify , [1:1] but IDK what FS an ESP is.-t
Tangential
-
@pg-tips, if I can confirm it is, I’ll file
github.com/MaddieM4/os-prober/issues/new. -
BTW,
/boot/loader/entries[2] just had Linux kernels in it (to confirm).