Description of problem: After runnning preupgrade on fully updated F16, rebooting into the new system from grub fails with dracut: FATAL: Don't know how to handle 'root=anaconda-kickstart' and resulting in Kernel panic Version-Release number of selected component (if applicable): anaconda-17.16-1.fc17 preupgrade run from F16: preupgrade-1.1.10-1.fc16 How reproducible: Always Steps to Reproduce: 1. Run preupgrade 2. Reboot 3. Boot "Upgrade to Fedora 17 (Beefy Miracle)" from grub menu Actual results: Fails with dracut: FATAL: Don't know how to handle 'root=anaconda-kickstart'. Expected results: System is upgraded. Additional info: Tested in KVM using virt-manager, libvirt.
Proposing as Beta blocker per criterion: "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria".
Discussed during 2012-03-30 blocker review meeting. Accepted as blocker per criterion cited in comment #1. I tested and reproduced this. bcl thinks it's due to "the kickstart parsing rewriting root=". Seems a good supposition, because there is no root= in the cmdline written by preupgrade, it is: linux /upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=blahblah:/upgrade/ks.cfg stage2=hd:UUID=blahblah:/upgrade/squashfs.img initrd /upgrade/initrd.img note that there's no UUID= in the 'repo=' parameter. There are two colons, indicating something was maybe supposed to go between them. Seems like that may be a bug somewhere. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at 2012-03-30 blocker review meeting. Accepted as a blocker per criterion cited in comment #1. We need to determine if the bug here is in preupgrade or anaconda to know whether we should block the RC3 compose for it; if anyone is prepared to decide that, please let us know :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
for now, bcl says anaconda. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
"hd::".. is a special preupgrade-only notation for "the disk device we're upgrading from", so that's legit. Digging deeper now.
Actually this turns out to be pretty straightforward: we didn't support stage2= like we used to. Patches will be along soon.
anaconda-17.17-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.17-1.fc17
reproduced with F17 Beta RC3
Not reproduced here, but I hit another failure. https://bugzilla.redhat.com/show_bug.cgi?id=810136 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Same here, this one seems to be fixed, but I hit #810136.
Package anaconda-17.17-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-17.17-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-5388/anaconda-17.17-1.fc17 then log in and leave karma (feedback).
When should this be available in preupgrade from fc16?
OK, further testing verifies that this is resolved, and the remaining bugs are 810005 and 810136. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
anaconda-17.19-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.19-1.fc17
anaconda-17.20-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/anaconda-17.20-1.fc17
anaconda-17.20-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.