Bug 1731557 - New kernel fails to boot if /boot is not its own partition
Summary: New kernel fails to boot if /boot is not its own partition
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-19 18:28 UTC by Göran Uddeborg
Modified: 2020-10-05 18:34 UTC (History)
7 users (show)

Fixed In Version: systemd-245.8-2.fc32 systemd-243.9-1.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-23 17:12:38 UTC
Type: Bug


Attachments (Terms of Use)

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.

Comment 3 Ben Cotton 2020-04-30 20:13:41 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Göran Uddeborg 2020-05-03 19:23:58 UTC
No change from what I can tell in Fedora 32 and systemd-udev-245.4-1.u1.fc32.x86_64.

Comment 5 Zbigniew Jędrzejewski-Szmek 2020-08-01 13:34:55 UTC
https://github.com/systemd/systemd/pull/16639 should fix this issue.

Comment 6 Fedora Update System 2020-09-20 13:20:20 UTC
FEDORA-2020-0d29e88946 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946

Comment 7 Fedora Update System 2020-09-20 13:22:31 UTC
FEDORA-2020-dc4f0fb907 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-dc4f0fb907

Comment 8 Fedora Update System 2020-09-20 23:55:17 UTC
FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0d29e88946`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2020-09-21 00:39:12 UTC
FEDORA-2020-dc4f0fb907 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-dc4f0fb907`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-dc4f0fb907

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2020-09-21 08:01:16 UTC
FEDORA-2020-0d29e88946 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946

Comment 11 Fedora Update System 2020-09-21 14:28:21 UTC
FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0d29e88946`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2020-09-23 17:12:38 UTC
FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Fedora Update System 2020-10-05 18:34:44 UTC
FEDORA-2020-dc4f0fb907 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.