My Fedora installation has removed Windows 10 from the boot menu

Ask Fedora
1

My Fedora installation has removed Windows 10 from the boot menu. I had installed Fedora after my Windows 10 installation. Can this be somehow recovered? Any help on this topic would be greatly appreciated.
[srini@workhorse ~]$ blkid

/dev/sda1: UUID="19AE-7865" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="db747b88-7fe1-49a8-8dd1-5b0fc482b84c"
/dev/sda2: UUID="e73bad11-2b7c-45ef-976d-f7090da92a21" TYPE="swap" PARTUUID="3c6e6bb4-6092-43fc-8d14-819f305bcc12"
/dev/sda3: LABEL="Windows 10" BLOCK_SIZE="512" UUID="182D72FD72C82E50" TYPE="ntfs" PARTUUID="cb13d011-480a-4ada-be25-f7082d487fe4"
/dev/sda5: LABEL="ThePit" BLOCK_SIZE="512" UUID="0C50A7C650A7B53C" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="00e32420-ff25-4151-ab54-666347030486"
/dev/sda6: UUID="752b5f1f-0a11-47f5-b8f8-0b48aff5f99d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d33faf39-bd37-4b01-a201-9f6cfacb6f69"
/dev/zram0: LABEL="zram0" UUID="91afbb3a-0e40-4f46-a774-f1aa4750c543" TYPE="swap"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
[srini@workhorse ~]$ efibootmgr
Timeout: 5 seconds
BootOrder: 3000,0000,2001,2002,2004
Boot0000* Fedora
Boot0001* Fedora
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot3000* Internal Hard Disk or Solid State Disk
[srini@workhorse ~]$
2

Welcome to askfedora.

Looking at the disk partitions it seems strange.
Windows normally installs (windows 8 and later) with 4 partitions.

# fdisk -l
Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: INTEL SSDPEKNW512G8                     
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: 406E2318-D071-4F12-A55C-75C1711D624E

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     534527    532480   260M EFI System
/dev/nvme0n1p2    534528     567295     32768    16M Microsoft reserved
/dev/nvme0n1p3    567296  199752334 199185039    95G Microsoft basic data
/dev/nvme0n1p4 998473728 1000214527   1740800   850M Windows recovery environment
/dev/nvme0n1p5 199753728  200859647   1105920   540M Linux filesystem
/dev/nvme0n1p6 200859648  610459647 409600000 195.3G Linux LVM
/dev/nvme0n1p7 610459648  612098047   1638400   800M Linux filesystem

Partitions 1-4 above are the default which windows created on my disk. I then, from within win10, used disk manager to shrink the ntfs partition leaving space to create partitions 5-7 for linux.

It is possible that with the changes you made to the partitioning that you broke windows and it will not boot. It is also possible that if you formatted the efi partition it will no longer be able to boot.

You have used partition 2 as swap and microsoft reserves that for ‘something’. I believe it is part of the boot process.

3

@computersavvy I have shared the details for fdisk command below:
[srini@workhorse ~]$ sudo fdisk -l
[sudo] password for srini:
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: TOSHIBA MQ01ABD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: CEC29536-BB2D-48E7-ADF1-42F7E203BF4A

Device Start End Sectors Size Type
/dev/sda1 2048 1260339 1258292 614.4M EFI System
/dev/sda2 1261568 26427391 25165824 12G Linux swap
/dev/sda3 210976768 420591615 209614848 100G Microsoft basic data
/dev/sda5 420591616 1953521663 1532930048 731G Microsoft basic data
/dev/sda6 26427392 210976767 184549376 88G Linux filesystem

Partition table entries are not in disk order.

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

Disk /dev/loop0: 97.86 MiB, 102612992 bytes, 200416 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: 97.74 MiB, 102486016 bytes, 200168 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: 197.14 MiB, 206716928 bytes, 403744 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/loop3: 55.36 MiB, 58052608 bytes, 113384 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/loop4: 20 KiB, 20480 bytes, 40 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
[srini@workhorse ~]$

4

While I am not fully versed on the microsoft disk structure, I believe that partition 2 (microsoft reserved) is actually part of the boot process and can be viewed as somewhat equivalent to /boot in linux. Using that space as swap likely is the cause of losing the ability for windows to boot. Fedora (both 33 & 34) uses zram (seen as zram0 above by fdisk -l) for swap so the physical swap partition is not needed except for the hibernation process.

I also note that you removed partition 4, which is the microsoft recovery partition, so even if you could boot the recovery process is not available for use.

As a recovery procedure I would suggest that you remove the swap partition then using windows install media do a recovery of windows. Once windows is able to boot then you would need to do a recovery of fedora so it would allow booting both.

I have never needed nor done a repair on grub, but suspect that if you were to boot to the live media, then mount and chroot into the installed linux partition that a “dnf reinstall grub*” may work. I am sure others may be able to give better instructions, but it seems relatively easy to recover.