|Summary:||New kernel fails to boot if /boot is not its own partition|
|Product:||[Fedora] Fedora||Reporter:||Göran Uddeborg <goeran>|
|Status:||NEW ---||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||30||CC:||alciregi, imc, lnykryn, msekleta, ssahani, s, systemd-maint, zbyszek|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Göran Uddeborg 2019-07-19 18:28:20 UTC
After upgrades a machine did not want to boot, not finding the kernel or initrd. After some investigation, I figured out the newly written BLS entry in /boot/loader/entries refers to the images relative to /boot. For example, the most recent version I installed wrote linux /bc6e8f186e8afde79d2ddb0047756edd/5.1.16-300.fc30.x86_64/linux initrd /bc6e8f186e8afde79d2ddb0047756edd/5.1.16-300.fc30.x86_64/initrd On this machine, /boot is not a separate partition but a directory in the root partition. I’m aware there are efforts to make /boot sharable between distributions, and for that to work it will have to be a partition of its own. But is this a REQUIREMENT in F30? Even for machines that will only run one OS, as is the case here? It was not necessary up to F29, but looking in /usr/lib/kernel/install.d/90-loaderentry.install I see no way to add a /boot to the beginning of the linux and initrd lines. On the other hand, I didn't see any warnings during the installation of the new kernel. Version-Release number of selected component (if applicable): systemd-udev-241-8.git9ef65cb.fc30.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install a new kernel on a machine where /boot is just a directory in /, not a file system on its own. Actual results: /boot/loader/entries/*.conf does not include /boot in the path to the linux and initrd images Expected results: /boot/loader/entries/*.conf would include /boot in the path to the images. Additional info: Manually editing the conf file adding /boot to the paths is a workaround I'm using.
Comment 1 Göran Uddeborg 2019-08-13 16:51:13 UTC
After some helpful assistance in Ask Fedora (https://ask.fedoraproject.org/t/should-the-grub-menu-entries-look-all-alike), I've now realised I was running with a non-standard configuration. I had a /boot/$MACHINE_ID directory, which causes the config files generated by 20-grub.install to be overwritten by 90-loadentry.install. Without that directory in /boot, the version from 20-grub.install will prevail. That version DOES include /boot in the path /boot when needed. It is thus probably not a very common problem. It still looks like a bug as far as I understand, though, so I'm not closing the report immediately.
Comment 2 Ian Collier 2019-08-14 15:47:57 UTC
I've just discovered this myself. It most certainly looks like a bug. In my case, I upgraded a machine from F26 to F30 and the new F30 kernel would not boot. I've just discovered that our F26 systems all have this /boot/$MACHINE_ID directory while none of our F28 systems do, and a new F30 install does not either. One other thing that happens is that 90-loadentry.install copies the "BOOT_IMAGE=" setting from the currently running kernel into the kernel parameters for the new kernel in the bootloader entry file. It should not do this either.