My system was a clone made onto an SSD disk from an HDD disk, and it sometimes showed weird behavior, like freezing and making file-system (btrfs) read-only. So, I decided to reformat the whole disk (including Windows) and re-install everything from scratch, but this time using EFI, not MBR, which was the case in the former setup. My laptop is Acer E5-475. It supports UEFI in the BIOS settings, as well as TPM and Secure Boot.
First, I installed Windows 11 on a partition on the SSD and then installed Fedora 39 using a USB stick on another partition. I used enough free space and allowed Fedora to make the required partitions automatically.
Everything went fine. Partitions selected, install started, and after some time, the boot loader and post-install scripts executed, and install finished without an issue. However, after rebooting the system, there is no Fedora or GRUB menu to select Fedora from. There is only Windows Boot Manager, which directly boots up Windows 11.
I tried creating partitions manually during install, using a different file system (e.g. ext4 instead of BTRFS), using a different burn tool to prepare the install media (e.g. Ventoy instead of Fedora Media Writer), but the result didn’t change.
I was tempted to try Ubuntu instead of Fedora to install alongside Windows, but I prefer Fedora and i think it’s faster than Ubuntu. So, before going forward with further actions (e.g. reformatting the disk as MBR and re-installing Windows and then Fedora using MBR media), I thought it might be good idea to ask here, just in case someone can shed some light on this or share an eye-opening related experience.
Hmm.
A couple of possibilities come to mind.
- Did you set the bios to boot uefi only before starting the reinstall? Doing so would ensure that all installed OSes are in uefi mode for booting.
- Are you certain windows installed in uefi mode? (windows normally creates and uses at least 4 partitions on a device during uefi install)
- Are you certain fedora installed in uefi mode?
Windows also normally only creates a 100 - 250 MB efi partition while fedora creates a 600 MB efi partition
Please boot from the install media then run lsblk -f and sudo fdisk -l and post the results here so we can see exactly what happened with the reinstall and how the drive is now partitioned.
Here’s the bios boot menu when I boot up the system with USB installation media plugged in:
Jeff,
1- check
2- check
3- check
And the results.
lsblk -f:
[root@localhost-live ~]# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
loop0
squash 4.0
loop1
ext4 1.0 Anaconda
2074eb84-624c-4790-83b6-8f3e4a82ae85
├─live-rw
│ ext4 1.0 Anaconda
│ 2074eb84-624c-4790-83b6-8f3e4a82ae85 1.6G 78% /
└─live-base
ext4 1.0 Anaconda
2074eb84-624c-4790-83b6-8f3e4a82ae85
loop2
└─live-rw
ext4 1.0 Anaconda
2074eb84-624c-4790-83b6-8f3e4a82ae85 1.6G 78% /
sda
├─sda1
│ vfat FAT32 8066-492A
├─sda2
│
├─sda3
│ ntfs 7070CD8B70CD588C
├─sda4
│ ntfs 0EC08D57C08D45C5
├─sda5
│ ntfs 669EB5979EB55FEB
├─sda6
│ ntfs AE38CCDF38CCA7A3
├─sda7
│ ext4 1.0 008d705d-42b2-44d6-ad84-af0fd32d7a2e
├─sda8
│ vfat FAT16 06C9-C2F7
└─sda9
btrfs fedora_localhost-live
ec07e400-2006-4779-8add-4f083221d0f3
sdb iso966 Jolie Fedora-WS-Live-38-1-6
2023-04-13-22-15-10-00
├─sdb1
│ iso966 Jolie Fedora-WS-Live-38-1-6
│ 2023-04-13-22-15-10-00 0 100% /run/initramfs/live
├─sdb2
│ vfat FAT16 ANACONDA
│ EEB5-E40F
└─sdb3
sr0
zram0
[SWAP]
fdisk -l:
[root@localhost-live ~]# fdisk -l
Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Lexar SSD NS100
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: gpt
Disk identifier: 2FFB9C84-8E4C-4FB2-9578-181CAED3323A
Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 239615 32768 16M Microsoft reserved
/dev/sda3 239616 223707135 223467520 106.6G Microsoft basic data
/dev/sda4 223707136 225279999 1572864 768M Windows recovery environment
/dev/sda5 225280000 511999999 286720000 136.7G Microsoft basic data
/dev/sda6 512000000 716799999 204800000 97.7G Microsoft basic data
/dev/sda7 716800000 718897151 2097152 1G Linux filesystem
/dev/sda8 718897152 719316583 419432 204.8M EFI System
/dev/sda9 719316992 1000214119 280897128 133.9G Linux filesystem
GPT PMBR size mismatch (4100491 != 15124991) will be corrected by write.
Disk /dev/sdb: 7.21 GiB, 7743995904 bytes, 15124992 sectors
Disk model: Silicon-Power8G
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: gpt
Disk identifier: 596BFE18-6CFC-4880-BA94-298703C7C362
Device Start End Sectors Size Type
/dev/sdb1 64 4075983 4075920 1.9G Microsoft basic data
/dev/sdb2 4075984 4099827 23844 11.6M EFI System
/dev/sdb3 4099828 4100427 600 300K Microsoft basic data
Disk /dev/loop0: 1.85 GiB, 1987653632 bytes, 3882136 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
Disk /dev/loop1: 7.57 GiB, 8128561152 bytes, 15876096 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
Disk /dev/loop2: 32 GiB, 34359738368 bytes, 67108864 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
Disk /dev/mapper/live-rw: 7.57 GiB, 8128561152 bytes, 15876096 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
Disk /dev/mapper/live-base: 7.57 GiB, 8128561152 bytes, 15876096 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
Disk /dev/zram0: 8 GiB, 8589934592 bytes, 2097152 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Any thing unusual going on in the results here?
Part of the results for fdisk -l were in red, which is shown below again, just in case:
GPT PMBR size mismatch (4100491 != 15124991) will be corrected by write.r eystemh
Sorry, I didn’t understand what you just wrote 
Well does it work if you change bios boot order to use grub boot? I bet windows is default top boot now so that’s why no options to choose where to boot
There is only Windows Boot Manager (which loads windows). There is no Grub menu to select other OS from.
Apparently there two ESP partition on one disk, and some UEFI implementation may not like that. Some UEFI implementations may even aggressively remove entries which are no found on the first ESP.