On Fri, Aug 28, 2015 at 11:33 AM, Paul Cartwright <pbcartwright@xxxxxxxxx> wrote: > On 08/28/2015 01:19 PM, Gordon Messmer wrote: >> >> Have another look. Boot002 and Boot005 are Fedora, and they are >> identical. They identify \EFI\FEDORA\shim.efi on partition 8. >> Notably, they don't refer to a kernel at all. > ok, so UEFI loads grub which loads grub.cfg which knows about the > different kernels ? UEFI looks at NVRAM to determine boot order, and tries the boot entries in that order until the spaghetti sticks to the wall. Your EFI System partition has at least three bootloaders, an Ubuntu GRUB, a Fedora GRUB, and a Windows bootloader. Since the BootOrder starts with 0004, which corresponds to the Ubuntu GRUB, that's the GRUB that UEFI executes, and that GRUB loads its own grub.cfg, and will display the kernels its aware of. Due to many things, including UEFI, and GRUB being overly complicated, and each distro forking GRUB, and also not always keeping it up to date with upstream, there are many variations in GRUB behavior possible. So it's not necessarily the case a given grub.cfg contains menu entries for all kernels/distros on the system. It might contain only entries for a particular distribution. In my view, the concept of grub.cfg containing entries for other distros is fraught with peril, not least of which is that the wrong /etc/grub/default is read to create the entries for other distros. Also, kernel upgrades only cause one grub.cfg to get updated. So I really wish this whole automatic creation of other distro menu entries would go away and instead create a forwarding entry to all other grub.cfg's. That way the proper menu entry for a particular kernel+distro is always used. And this explanation is courtesy of how overly complicated it is. How it actually works at a code level, just look at grub.cfg - it reads like a bash script. It's not just a boot configuration file anymore. It's simultaneously impressive and annoying. >> >> UEFI loads and runs shim.efi, which is identified in the UEFI boot >> list. shim.efi loads and runs grubx64.efi. grubx64.efi loads its >> configuration file, then loads and runs a Linux kernel (or Windows). >> The kernel runs /sbin/init on its root filesystem. >> >>> , whatever they are.. except there >>> is no shimx64.efi ... >>> >>> -rwx------ 1 root root 1293304 Feb 17 2015 shim.efi >>> -rwx------ 1 root root 1287032 Feb 17 2015 shim-fedora.efi >> >> The full path relative to the system partition is >> "\EFI\ubuntu\shimx64.efi". It's in a different directory than the >> Fedora-installed shim.efi. > I just mounted my ubuntu "/" partition and.... /boot/efi was... empty. > I'm pretty sure it was there when I booted ubuntu.. oh wait... /boot/efi > is a separate partition.. but it is already mounted, and it is fedora, > not ubuntu... arg.... Yet another absurdity is this OCD on Linux with persistently mounting shit that doesn't need to be mounted. No other OS does this with the EFI System partition. In my opinion it's sloppiness+laziness that we do this instead of mounting it dynamically on demand only when it's necessary and then promptly umount it - which should be rather rare. In a previous email some information you posted indicated the EFI System partition was sda8, which makes me wonder if there's more than one ESP on this drive. On an out of the box Windows 8.1 system I had, it was sda2 and Fedora reused that rather than making a new ESP. More than one ESP can also be confusing for the user, and might trigger bugs even though it's permitted in the UEFI spec. -- Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
