Bug 1693480

Summary: systemd-bootx64.efi broken after upgrade to F29, system unbootable
Product: [Fedora] Fedora Reporter: Gregory Lee Bartholomew <gregory.lee.bartholomew>
Component: systemdAssignee: systemd-maint
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: lnykryn, msekleta, ssahani, s, systemd-maint, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-28 07:44:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gregory Lee Bartholomew 2019-03-27 23:55:46 UTC
Description of problem:

I upgraded from F28 to F29 using dnf system-upgrade. After the final restart, the /boot/<machine-id> directory was gone and no F29-specific /boot/loader/entries/xxx.conf file was created. This left the computer completely unbootable. I had been using dnf update on F28 with this setup for a long time without issue. New kernels were being added to the boot partition without issue in F28.

Version-Release number of selected component (if applicable):

$ rpm -q systemd-udev
systemd-udev-239-12.git8bca462.fc29.x86_64

How reproducible:

??? I only did it once.

Steps to Reproduce:
1. Follow https://github.com/rhinstaller/anaconda/issues/934 to switch to systemd-boot
2. dnf system-upgrade --releasever=29 download
3. dnf system-upgrade reboot

Actual results:

Old kernels removed from /boot. New kernel not placed in correct subdirectory and new configuration file not generated.

Expected results:

At the very least I didn't expect all the old kernels to get removed. Thankfully the config files under /boot/loader/entries were still present so I could copy them and use them as a template for manually fixing everything up from a rescue CD after the fact.

Additional info:

I'm not sure if it matters what grub components were installed and I don't even know (I may have removed some of them when I switched to systemd-boot). These are the grub components that are present on my system after the upgrade:

$ rpm -qa | grep grub
grub2-common-2.02-62.fc29.noarch
grub2-tools-minimal-2.02-62.fc29.x86_64
grub2-tools-2.02-62.fc29.x86_64
grubby-8.40-18.fc29.x86_64

I understand if this is an unusual/unsupported setup and therefore a low priority. I just thought I should let someone know since the outcome was rather drastic.

FYI.

Comment 1 Zbigniew Jędrzejewski-Szmek 2019-03-28 07:44:08 UTC
Yep. It's almost fixed fortunately. I hope you got your bootloader restored.

*** This bug has been marked as a duplicate of bug 1648907 ***