Created attachment 567784 [details] screenshot Description of problem: After running preupgrade on freshly installed and updated Fedora 16 machine preupgrade completes successfully. Upon reboot and choosing Fedora 17 Beefy Miracle grub entry the system starts booting and then kernel panics. How reproducible: Always Steps to Reproduce: 1. Install Fedora 16 i386 2. Run yum update 3. Run yum install preupgrade 4. Run preupgrade 5. Reboot and choose Fedora 17 grub entry Actual results: Kernel panic Expected results: Upgrade should finish.
Here's a tip. Marking the bug as CommonBugs and marking it urgent doesn't get the bug fixed any quicker, and usually angers the developer. Please don't do that. And perhaps giving some details other than "Kernel panic" and a screenshot of a non-free virtual machine might be helpful.
I have the same problem. Dracut is missing root parameter, which is mandatory now. This happens right after preupgrade restarts system (after downloading packages). Version: 1.1.10-1.fc16.noarch I propose this bug as beta blocker, because it meets 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"
Sorry about that Richard, I'm new and just trying to help. The fact that it was running in a VM should not make a difference. I believe this is an urgent issue because on the wiki it says you can use yum preupgrade to upgrade to fedora 17. This results in a kernel panic on i386. It probably results in the same on x86_64, I have yet to test it. And I agree with Peter, this should be a beta blocker, because yum preupgrade should work. It's extremely important that we get this fixed because I can see a lot of people having failed upgrades and not knowing what to do after the fact by using preupgrade which at the current moment will result in a kernel panic. Thanks.
richard: I'd say the CommonBugs request and 'urgent' severity are defensible: we'd certainly want to document complete fails with preupgrade if they weren't to get fixed, and this bug does indeed completely prevent preupgrade from working and affect other functioning, as per the description of 'urgent' severity at https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Severity . It's maybe strictly 'high' rather than 'urgent', but it's not as if he's flagging a typo as urgent or something. However, Dan, as per that policy, reporters and triagers should never set the 'priority' of a bug - that's reserved for developers. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I can confirm this happens as described in Comment #1 on my x86_64 (non virtual machine).
Created attachment 568470 [details] contents of grub2.cfg
Thanks, changed platform to "All".
Discussed at 2012-03-09 blocker review meeting. Agreed this bug is a 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". -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Can somebody tell me what needs to be added to preupgrade to get the new kernel to boot please? Thanks.
Richard: see https://bugzilla.redhat.com/show_bug.cgi?id=785815 . This is essentially a special-case 'clone' of that bug, which exists because we can fix this up on the preupgrade side if it's not fixed up on the anaconda side. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Note that the recently-committed noloader change for anaconda may result in this going away. I'm not entirely sure. Will ask Will.
This may change once anaconda 17.13 is pushed stable (the build with noloader). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
FWIW I managed to preupgrade to His Meatiness by fixing the kernel line as follows: kernel /upgrade/vmlinuz preupgrade repo=hd:UUID=uuid-of-root:/var/cache/yum/preupgrade root=live:UUID=uuid-of-boot live_dir=upgrade/ live_ram Without live_ram, the boot partition remained mounted and Anaconda failed during storage scan. *However* I removed the ks= option to keep the grub.conf stanza. I'm not sure whether keeping the kickstart will cause a similar failure due to /boot being busy. Should be easy to check.
We can consider this 'MODIFIED' by anaconda 17.13+, which should cause preupgrade to work once a 17.13+ build goes stable. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
the beta RC1 updates are now pushed stable, so once a new installer is composed on the mirrors, we should be able to test this. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #15) > the beta RC1 updates are now pushed stable, so once a new installer is composed > on the mirrors, we should be able to test this. I've run onto this bug on Saturday as well. After finding this bug I tried again with new packages on Sunday evening. Now I do not get anymore a kernel panic, instead now I get anconda/dracut to loop forever very fast trying to mount disks, with annoying messages about udev deprecated rules and whatnot.
Then it's not this bug. http://bugzilla.redhat.com/show_bug.cgi?id=806867 is the new 'preupgrade doesn't work' bug for RC1. The existence of that implies that this one is in fact fixed. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Not really; a fix in preupgrade would have enabled preupgrade to F17 Alpha images using a kernel command line such as the one in comment 13. So I'm changing the reason for closing and subject to match what this bug was really about.