Hide Forgot
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
Proposing blocker. System doesn't boot, it's as simple as that.
Created attachment 661066 [details] upgrade.log
*** Bug 883072 has been marked as a duplicate of this bug. ***
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.
Created attachment 661310 [details] grub.cfg with fedup-0.7.1-1.fc17
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.
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.
This is fixed in fedup 0.7.2, which is stable now.
drop commonbugs nomination, then.