I've been cleaning up my laptop by unmounting all the drives and now when I turn on my system, it says no boot media found. I've triple booted with windows 10, Kali linux and ubuntu. With ubuntu and windows 10 in standard hard drive and kali in SSD. Have I messed up my uefi boot partition? The UEFI boot partition was setted up in standard hard disk before. I have turned on the UEFI boot in my bios setting. How could I restore my boot again? And also I tried to add the UEFI boot menu in bios. But it shows "no media found". Can't add the boot menu.
1 Answer
What went wrong
Just unmounting filesystems should not have any persistent effect at all, since everything gets mounted according to kernel boot options, initramfs settings and /etc/fstab contents at every boot.
You changing the BIOS boot settings is the more likely reason in my opinion. Also, some UEFI firmwares will "helpfully" clear UEFI boot settings referring to disks that are no longer detectable, to prevent cluttering up the settings NVRAM with obsolete boot variables. So if you physically removed the disks from the laptop and then powered up the laptop with no disks installed, this may have been the cause.
UEFI boot variables
Native UEFI boot style requires that certain UEFI boot variables are set correctly. If you have just switched your system boot style from legacy BIOS to UEFI, that is unlikely to be the case. If those variables don't exist, UEFI firmware only looks for a specific fallback/removable media bootloader file on either the EFI System Partition (ESP for short) or on any accessible FAT partition on removable media. On 64-bit x86 hardware, this bootloader file name will be \EFI\BOOT\bootx64.efi relative to the root of the FAT partition in question.
So, if there are no UEFI boot variables and no \EFI\BOOT\bootx64.efi on the disk, then that disk is not bootable in UEFI native style. Very simple. And if there is currently no disk with such a file available, you'll get the No media found error.
The UEFI boot variables can specify other bootloaders, and the directory structure expected on the ESP partition is designed to allow multiple bootloaders to coexist.
For example, most Linux distributions will place their UEFI bootloaders at \EFI\<name of distribution>\shimx64.efi (if supporting Secure Boot using the shim bootloader, as is the common solution) or \EFI\<name of distribution>\grubx64.efi if Secure Boot support is not needed. Both Ubuntu and Kali should use that pattern.
The UEFI bootloader for Windows 10 will be at \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI.
Fixes and workarounds
If your UEFI firmware settings ("BIOS settings", although calling UEFI a BIOS is a bit of a misnomer) include a "boot from file" option, you should be able to select one of the above-mentioned bootloader files to boot the respective OS... but this will not be a persistent fix by itself.
If you do this, I suggest you boot Windows 10 first, as it seems to have "self-healing" features that cause it to automatically rewrite its UEFI boot variable if it seems to be lost... potentially overwriting the boot variables of other OSs, unless you let Windows keep the first UEFI boot variable (called Boot0000) for itself. Alternatively, you can boot from a Windows 10 installation media and select "Repair your computer" to automatically fix the UEFI boot variables and possibly also the Windows UEFI bootloader if it seems to be non-functional.
After Windows 10 is fixed, it's time to try and boot one of your Linux installations, either using the "boot from file" option in the UEFI settings if one is available, or by booting into rescue from Linux installation media, or by using a Linux live boot media that provides a completely independent environment. Once there, you should be able to use the efibootmgr command to recreate any missing boot variables for your Linux installations. Read the man page first, it has good examples: man efibootmgr.
Windows 10 also has a native command for editing UEFI boot variables: bcdedit. You'll have to run a Command Prompt as an Administrator to use it, and I find it... less ergonomic for the purpose than Linux efibootmgr (although I might be biased as a Linux guy). But it can do the job.
The bcdedit commands required:
bcdedit /create /d "<description of your Linux boot option>" {fwbootmgr}
This command will return a long GUID string, which will be used by all the following commands. It will be marked as <GUID>
bcdedit /set <GUID> device partition=S:
If you're using the same ESP partition to contain both Windows and Linux bootloaders, the Windows drive letter S: is likely already assigned to ESP, although ESP is not mounted in Windows by default. If you are using another ESP for Linux, you'll need to assign that ESP a Windows drive letter before starting this process, and change the partition=S: part accordingly.
bcdedit /set <GUID> path \EFI\<name of Linux distro>\shimx64.efi
This sets the bootloader pathname associated with the boot variable.
bcdedit /set {fwbootmgr} default <GUID>
This sets the newly-added boot variable as the default boot option, as it will most likely provide the GRUB boot menu you can use to select the operating system to boot.
