"No bootable devices found" after attempting dual boot

As a word of caution: I am inexperienced and moved some partitions around when attempting to dual boot windows from Fedora, I didn’t take note of what I was doing and so only have my current situation to work from and nothing to work back towards. I know I should have backed up but here we are.

When I try to boot into my Fedora filesystem on my DELL Inspiron 7400 from the boot menu, I receive a No bootable devices found error.

I am currently using Fedora from a live USB.

Output of sudo fdisk -l:

Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: KBG40ZNS512G NVMe KIOXIA 512GB          
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: 3A1641E9-8A61-4571-84A5-5A4B01FE1FEF

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048    1230847   1228800   600M EFI System
/dev/nvme0n1p2   1230848    3327999   2097152     1G Linux filesystem
/dev/nvme0n1p3   3328000  481832959 478504960 228.2G Linux filesystem
/dev/nvme0n1p4 481832960 1000214527 518381568 247.2G Microsoft basic data
GPT PMBR size mismatch (3979243 != 240328703) will be corrected by write.
The backup GPT table is not on the end of the device.

Output of lsblk -f for the relevant drive:

NAME        FSTYPE   FSVER            LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1                                                                                                         
├─nvme0n1p1 exfat    1.0                                    E3FF-EA47                                           
├─nvme0n1p2 ext4     1.0                                    98871ee5-1638-4cce-ad50-8668e8ddca31                
├─nvme0n1p3 btrfs                     fedora_localhost-live 2f90f992-e665-42ac-b8d0-0452f56c3413                
└─nvme0n1p4 exfat    1.0                                    67ED-F63F     

nvme0n1p3 is my Fedora file system which I am attempting to recover.

nvme0n1p4 is a partition I created prior which was supposed to store Windows 10.

To show the contents of /etc/fstab I mounted nvme0n1p3 and other relevant virtual filesystems with

$ mount -t btrfs -o subvol=root,compress=zstd:1 UUID=2f90f992-e665-42ac-b8d0-0452f56c3413 /mnt
$ for dir in sys proc run dev ; do mount --bind /$dir /mnt/$dir ; done 

and entered a chroot environment for the installed OS.

$ chroot /mnt

Current mounted partitions are

$ mount
/dev/nvme0n1p3 on / type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=257,subvol=/root)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,size=3218672k,nr_inodes=819200,mode=755,inode64)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=1048576,mode=755,inode64)
/dev/nvme0n1p2 on /boot type ext4 (rw,relatime,seclabel)
/dev/nvme0n1p3 on /home type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/home)

/boot/efi is not mounted. When I attempt to mount it I get

$ mount /boot/efi
mount: /boot/efi: wrong fs type, bad option, bad superblock on /dev/nvme0n1p1, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

From the chroot environment, the contents of /etc/fstab is:

UUID=2f90f992-e665-42ac-b8d0-0452f56c3413 /                       btrfs   subvol=root,compress=zstd:1 0 0
UUID=98871ee5-1638-4cce-ad50-8668e8ddca31 /boot                   ext4    defaults        1 2
UUID=E3FF-EA47 /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=2f90f992-e665-42ac-b8d0-0452f56c3413 /home                   btrfs   subvol=home,compress=zstd:1 0 0
/dev/disk/by-id/usb-USB_SanDisk_3.2Gen1_01014b4983299e0e5a6c1f9f3d81280741420402818084341748ec522098bd28ad3d0000000000000000000034beffdcff0c520091558107b7ad0543-0:0 /mnt/usb-USB_SanDisk_3.2Gen1_01014b4983299e0e5a6c1f9f3d81280741420402818084341748ec522098bd28ad3d0000000000000000000034beffdcff0c520091558107b7ad0543-0:0 auto nosuid,nodev,nofail,x-gvfs-show 0 0

I have been trying to fix this issue for a while and have attempted the following:

  • nvme0n1p1 (labelled as the EFI partition) was formatted at nfts when the issue initially occurred, following online advice I reformatted this to exfat using Gparted
  • Then I then manually mounted nvme0n1p1 at /boot/efi.
  • Finally I changed the UUID in etc/fstab to match this. This is the current UUID shown for nvme0n1p1.

I am sorry I was out of pocket for some time this last week. The earlier thread on this topic is

I suspect that the issue may be identified by running fdisk -l in the chroot environment. The partition used as /boot/efi should show as EFI System similar to this.

# fdisk -l /dev/sda
Disk /dev/sda: 223.58 GiB, 240065183744 bytes, 468877312 sectors
Disk model: SanDisk SSD PLUS
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: E40A3810-D22D-49F4-99A1-660AC05AA530

Device        Start       End   Sectors  Size Type
/dev/sda1      2048    514047    512000  250M EFI System
/dev/sda2    514048   2562047   2048000 1000M Linux filesystem
/dev/sda3  20994048 335575039 314580992  150G Linux LVM

As you can see sda1 is identified as the efi boot partition there and so you may need to flag /dev/nvmeon1p1 as the boot partition before the bios can use it for booting. That also can be done using gparted. Notice the flags for sda1 in the image below. If the device is mounted it will be locked and cannot be altered, but can be unmounted then altered with gparted.

The output for fdisk -l for the relevant drive is as follows:

Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: KBG40ZNS512G NVMe KIOXIA 512GB          
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: 3A1641E9-8A61-4571-84A5-5A4B01FE1FEF

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048    1230847   1228800   600M EFI System
/dev/nvme0n1p2   1230848    3327999   2097152     1G Linux filesystem
/dev/nvme0n1p3   3328000  481832959 478504960 228.2G Linux filesystem
/dev/nvme0n1p4 481832960 1000214527 518381568 247.2G Microsoft basic data
GPT PMBR size mismatch (3979243 != 240328703) will be corrected by write.
The backup GPT table is not on the end of the device.

Would the size mismatch error have anything to do with the issue?

Gparted shows nvme0n1p1 as the EFI System Partition:

Following your advice I have attempted to manually mount nvme0n1p1 at/boot/efi only to discover that /boot/efi does not exist.

# mount UUID=7EC6-8CB0 /boot/efi
mount: /boot/efi: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.

Could I create the /boot/efi directory or is there more to it than that?

Please show the output of ls /boot when you are in the chroot environment.
Note that the main file system has the /boot mount point, but only after you mount the /boot partition will the mount point for /boot/efi exist. This is why my earlier instructions involved first mounting the root file system at /mnt then after doing the chroot to /mnt I suggested using mount -a to complete mounting the entire system properly

I would suspect that a simple use of sudo gdisk /dev/nvme0n1 while booted to the live media (without mounting any partitions from the main [nvme0n1] drive) would be able to fix that. I noticed that you had the btrfs partition mounted when you had gparted open, and one cannot have any partitions mounted from the device where one is using gdisk.

While gdisk is open, use ‘p’ to display (print) the partition table, and ‘w’ to write it out and exit. This should fix that particular complaint.

After doing this we may have to go back and fix grub.

Here is the output of ls /boot from within the chroot environemnt.

config-6.0.16-300.fc37.x86_64                            initramfs-6.1.6-200.fc37.x86_64.img  System.map-6.0.16-300.fc37.x86_64
config-6.1.6-200.fc37.x86_64                             initramfs-6.1.9-200.fc37.x86_64.img  System.map-6.1.6-200.fc37.x86_64
config-6.1.9-200.fc37.x86_64                             loader                               System.map-6.1.9-200.fc37.x86_64
efi                                                      lost+found                           vmlinuz-0-rescue-5b4503d63784478397e67ecae70cce45
grub2                                                    symvers-6.0.16-300.fc37.x86_64.gz    vmlinuz-6.0.16-300.fc37.x86_64
initramfs-0-rescue-5b4503d63784478397e67ecae70cce45.img  symvers-6.1.6-200.fc37.x86_64.gz     vmlinuz-6.1.6-200.fc37.x86_64
initramfs-6.0.16-300.fc37.x86_64.img                     symvers-6.1.9-200.fc37.x86_64.gz     vmlinuz-6.1.9-200.fc37.x86_64

I have executed sudo gdisk /dev/nvme0n1 as instructed, unfortunately the error in the size mismatch still persists. If this is not relevant to the issue regarding the access of the installed OS I would be happy to revisit it later.

As you can see /boot (when mounted) has the efi subdirectory mount point.
Was that after you did the ‘mount -a’ command?

The content there is exactly as I would have expected it to be.

You are correct that the size mismatch is not likely applicable to the booting error.

At this point I suggest the following.

  1. boot to the live image.
  2. create the chroot environment and chroot into it
  3. ensure that all file systems are mounted with mount -a
  4. Verify that all are properly mounted with the mount command. You should see /, /boot, /boot/efi, /home, and the 4 others (proc, sys, run, dev)
  5. if the result of #4 is correct then (and only then) do the following.
    a. rm /boot/grub2/grub.cfg and rm /boot/efi/EFI/fedora/grub.cfg
    b. dnf reinstall grub* shim*
  6. Once that has completed run efibootmgr and post the result here.

After posting the result of efibootmgr we can see what it may tell you about possible boot problems.

1 Like

All file systems are properly mounted and /boot/grub2/grub.cfg has been removed.
However /boot/efi/EFI/fedora/grub.cfg does not exist and so cannot be removed.

# rm /boot/efi/EFI/fedora/grub.cfg
rm: cannot remove '/boot/efi/EFI/fedora/grub.cfg': No such file or directory

That is fine.

Without that file fedora cannot boot so we need to continue and recreate the file properly.

First show the result of ls -R /boot. Then if that looks ok to us you may continue with the command in step 5.b. and lets see what now happens.

Output of ls -R /boot

# ls -R /boot
/boot:

That tells me you may not have performed steps 3 & 4.

What about the output of mount?
And did you run mount -a as root? (steps 3 & 4 above)

The ls -R /boot command should return something like this if all the file systems are properly mounted.

$ sudo ls -R /boot
/boot:
config-6.1.11-200.fc37.x86_64				 lost+found
config-6.1.12-200.fc37.x86_64				 memtest86+-5.31
config-6.1.13-200.fc37.x86_64				 symvers-6.1.11-200.fc37.x86_64.gz
efi							 symvers-6.1.12-200.fc37.x86_64.gz
elf-memtest86+-5.31					 symvers-6.1.13-200.fc37.x86_64.gz
extlinux						 System.map-6.1.11-200.fc37.x86_64
grub2							 System.map-6.1.12-200.fc37.x86_64
initramfs-0-rescue-730854f859414ee8ab2aff2cbe878557.img  System.map-6.1.13-200.fc37.x86_64
initramfs-6.1.11-200.fc37.x86_64.img			 vmlinuz-0-rescue-730854f859414ee8ab2aff2cbe878557
initramfs-6.1.12-200.fc37.x86_64.img			 vmlinuz-6.1.11-200.fc37.x86_64
initramfs-6.1.13-200.fc37.x86_64.img			 vmlinuz-6.1.12-200.fc37.x86_64
loader							 vmlinuz-6.1.13-200.fc37.x86_64

/boot/efi:
EFI  mach_kernel  System

/boot/efi/EFI:
BOOT  fedora

/boot/efi/EFI/BOOT:
BOOTIA32.EFI  BOOTX64.EFI  fbia32.efi  fbx64.efi

/boot/efi/EFI/fedora:
BOOTIA32.CSV  gcdia32.efi  grub.cfg	 grubx64.efi  mmx64.efi  shimia32.efi
BOOTX64.CSV   gcdx64.efi   grubia32.efi  mmia32.efi   shim.efi	 shimx64.efi

/boot/efi/System:
Library

/boot/efi/System/Library:
CoreServices

/boot/efi/System/Library/CoreServices:
SystemVersion.plist

/boot/extlinux:
cat.c32     cpuid.c32	   dmitest.c32	 host.c32	  ldlinux.c32	linux.c32    pci.c32	   reboot.c32	 vesainfo.c32
chain.c32   cpuidtest.c32  elf.c32	 ifcpu64.c32	  lfs.c32	ls.c32	     pcitest.c32   rosh.c32	 vesamenu.c32
cmd.c32     debug.c32	   ethersel.c32  ifcpu.c32	  libcom32.c32	lua.c32      pmload.c32    sanboot.c32	 vpdtest.c32
cmenu.c32   dhcp.c32	   gfxboot.c32	 ifmemdsk.c32	  libgpl.c32	mboot.c32    poweroff.c32  sdi.c32	 whichsys.c32
config.c32  dir.c32	   gpxecmd.c32	 ifplop.c32	  liblua.c32	memdisk      prdhcp.c32    sysdump.c32	 zzjson.c32
cptime.c32  disk.c32	   hdt.c32	 kbdmap.c32	  libmenu.c32	meminfo.c32  pwd.c32	   syslinux.c32
cpu.c32     dmi.c32	   hexdump.c32	 kontron_wdt.c32  libutil.c32	menu.c32     pxechn.c32    vesa.c32

/boot/grub2:
fonts  grub.cfg  grubenv  i386-pc  themes  x86_64-efi

/boot/grub2/fonts:
unicode.pf2

/boot/grub2/i386-pc:
multiboot2.mod	relocator.mod

/boot/grub2/themes:
breeze	system

/boot/grub2/themes/breeze:
progress_bar2_c.png  progress_bar_hl_c.png  unifont-bold-16.pf2     unifont-regular-16.pf2
progress_bar_c.png   theme.txt		    unifont-regular-14.pf2  unifont-regular-32.pf2

/boot/grub2/themes/system:

/boot/grub2/x86_64-efi:
multiboot2.mod	relocator.mod

/boot/loader:
entries

/boot/loader/entries:
730854f859414ee8ab2aff2cbe878557-0-rescue.conf		      730854f859414ee8ab2aff2cbe878557-6.1.12-200.fc37.x86_64.conf
730854f859414ee8ab2aff2cbe878557-6.1.11-200.fc37.x86_64.conf  730854f859414ee8ab2aff2cbe878557-6.1.13-200.fc37.x86_64.conf

Thank you very much for your help and time but I am afraid I must prioritise my time over the recovery of the filesystem. I have used chroot to back up all important files and so have decided to clean install fedora from here. Thanks again for all your help.

At this point it seems the best option.

Lesson to learn from this.

  1. Install windows first.
  2. Use the windows disk manager to shrink the windows file system and allow free space for the install
  3. Install fedora into the now free space on the drive without relocating partitions.

Fedora normally has no issues with an install done in the above order, but the bios+fedora+windows install may conflict if partitions are relocated.