Bug 885853

Summary: systemd-upgrade.target is copied to the upgraded system, rendering it unbootable (single kernel systems)
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: fedup-dracutAssignee: Will Woods <wwoods>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: awilliam, m-redhat, robatino, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: RejectedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-14 18:36:33 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:
Attachments:
Description Flags
upgrade.log
none
grub.cfg with fedup-0.7.1-1.fc17 none

Description Kamil Páral 2012-12-10 19:50:32 UTC 
Description of problem:
I have performed a clean F17 minimal installation from netinst in a VM. I installed fedup and upgraded. After upgrade is complete, the new system doesn't boot, it gets stuck after "Welcome to Linux" printout. I found out that the offender is systemd.unit=system-upgrade.target boot option, that makes the system not boot. If I remove it from grub, everything works fine.

I tried another upgrade, but this time I installed one more kernel before running fedup. This time everything worked fine, system-upgrade.target was not specified.

Then I tried another upgrade, this time again with just a single kernel. And guess what - broken again!

1 kernel -> breaks
more kernels -> OK

Version-Release number of selected component (if applicable):
fedup-0.7.1-1.fc17
http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/x86_64/os/

How reproducible:
always

Steps to Reproduce:
1. install F17 minimal from netinst, to make sure you have just a single kernel
2. upgrade
3. try to boot F18, it will fail because grub will contain system-upgrade.target when it shouldn't
Comment 1 Kamil Páral 2012-12-10 19:50:56 UTC 
Proposing blocker. System doesn't boot, it's as simple as that.
Comment 2 Kamil Páral 2012-12-10 19:59:09 UTC 
Created attachment 661066 [details]
upgrade.log
Comment 3 Will Woods 2012-12-10 21:00:50 UTC 
*** Bug 883072 has been marked as a duplicate of this bug. ***
Comment 4 Will Woods 2012-12-10 22:25:30 UTC 
Out of curiosity, which entries are left in grub2.cfg? I'm guessing there's three - F17, F18, and System Upgrade?

Can you try with fedup-0.7.2-0.git20121206:

  http://koji.fedoraproject.org/koji/buildinfo?buildID=371385

and let me know if that works as expected? Using that you should end up with just the F17 and F18 kernel.
Comment 5 Kamil Páral 2012-12-11 09:14:55 UTC 
Created attachment 661310 [details]
grub.cfg with fedup-0.7.1-1.fc17
Comment 6 Kamil Páral 2012-12-11 09:51:18 UTC 
With fedup-0.7.2-0.git20121206 I had to solve bug 885990. After that I upgraded and I no longer see this problem. grub.cfg doesn't contain any system-upgrade.target options and the previous "System Upgrade" boot menu disappeared completely. So - fixed.

I have to say I upgraded fedup client, but I used the original Beta kernel images with --instrepo. I don't know how to rebuild those.
Comment 7 Adam Williamson 2012-12-12 18:53:09 UTC 
Discussed at 2012-12-12 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-12/f18final-blocker-review-4.2012-12-12-17.01.log.txt . We agreed that this doesn't seem likely to hit enough 'real' configurations to block release for (note it is an F17 bug, so 'blocker' status would mean 'F17 update must go stable before F18 release date'). Real installed systems pretty much always have >1 kernel. You can also fairly easily workaround this if you do hit it, we can note how in commonbugs. So this is rejected as a blocker. There is no possibility of NTH status for an F17 bug.

Still, Will, it'd be nice if you could push out an update to fix this ASAP, just to be safe.
Comment 8 Kamil Páral 2013-01-14 18:36:33 UTC 
This is fixed in fedup 0.7.2, which is stable now.
Comment 9 Adam Williamson 2013-01-15 00:37:44 UTC 
drop commonbugs nomination, then.