Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 820340
Summary: | kernel-X.Y-Z.fc17 does not supersede kernel-X.Y-Z.fc16 in grub | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | preupgrade | Assignee: | Richard Hughes <hughsient> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | bcl, bloch, bojan, collura, emailjonathananderson-fedora, germano.massullo, hughsient, kparal, mads, mskinner, pjones, thomas |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-01 11:30:21 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
Adam Williamson
2012-05-09 17:09:06 UTC
Please add the grub.cfg from before and after the preupgrade, and any relevant logs. Otherwise there's no way to tell at all what's going wrong. Hum, now I think about it, it might be anaconda, since it generates a new bootloader config during the upgrade. I just tested installing 3.3.4-3.fc17 on an F16 system with 3.3.4-3.fc16 installed and that worked okay. I'll have to re-do the upgrade to duplicate, I didn't take a 'before' grub config because I wasn't expecting this... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers So I just tried to reproduce this by doing a DVD upgrade, starting from the same F16 image (pretty much). The TC3 DVD has 3.3.4-3.fc17 on it. But...the bug didn't happen. The upgraded system has only 3.3.4-3.fc17, and it boots fine. 3.3.4-3.fc16 is (silently) removed as part of the upgrade. so...I'm confused. I've no idea what magic happened during the preupgrade to trigger this, but I know what I saw! I KNOW WHAT I SAW, DAMN YOU! If there's any part of this that's grubby, it's grubby not getting called in or at the appropriate time and way. Reassigning. *** Bug 821289 has been marked as a duplicate of this bug. *** AFAICT, this is not related to anaconda, because I preformed all three of my upgrades using the yum upgrade process (as per bug #821289). All machines hung in exactly the same way on second reboot (first reboot was dracut doing the usrmove, so this was after distro-sync). (In reply to comment #6) > I preformed all three of my > upgrades using the yum upgrade process (as per bug #821289). If you are upgrading manually then it is your own responsibility to make sure the kernel get correctly updated. "Upgrading Fedora using yum" should probably mention that now when all supported releases use the same kernel version. (It could also be argued that it is a yum bug if distro-sync doesn't install the right kernel.) (In reply to comment #7) > (In reply to comment #6) > > I preformed all three of my > > upgrades using the yum upgrade process (as per bug #821289). > > If you are upgrading manually then it is your own responsibility to make sure > the kernel get correctly updated. "Upgrading Fedora using yum" should probably > mention that now when all supported releases use the same kernel version. > > (It could also be argued that it is a yum bug if distro-sync doesn't install > the right kernel.) The correct kernel did get installed. The currently running kernel (the one from F-16) panicked on reboot. (In reply to comment #8) > The correct kernel did get installed. Did it work correctly? That indicates that your bug wasn't a duplicate of this bug anyway ... and that it actually wasn't a bug at all. > The currently running kernel (the one from F-16) panicked on reboot. That is expected. The old dracut in the old initramfs cannot boot a f17 system where everything has moved to /usr. That is why it is so important to get a new kernel when upgrading to f17 ... and this bug describes a case where that didn't happen with a normal upgrade. Right. This bug is not for the general 'my f16 kernel was newer than my f17 kernel so I still get an f16 kernel on upgrade' case, nor for the 'first shutdown after a yum upgrade from 16 to 17 crashes' case. It's specifically for a case I observed where installing an F17 kernel with the _same_ NEV (but not R) as the current F16 kernel seemed to result in the new kernel not being present in the grub menu at all. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #9) > (In reply to comment #8) > > The correct kernel did get installed. > > Did it work correctly? Yes. In fact, I'm writing this on it. There is nothing wrong with that new kernel or the system in general. > That indicates that your bug wasn't a duplicate of this bug anyway ... and that > it actually wasn't a bug at all. Possibly, yes. > > The currently running kernel (the one from F-16) panicked on reboot. > > That is expected. The old dracut in the old initramfs cannot boot a f17 system > where everything has moved to /usr. Well, that bit is not true at all. In fact, F-16 kernel booted up just find after usrmove and worked fine during distro-sync. It only died on shutdown -r now. > That is why it is so important to get a new > kernel when upgrading to f17 ... and this bug describes a case where that > didn't happen with a normal upgrade. Then the instructions should probably be changed to upgrade the kernel to an F-17 kernel before usrmove. (In reply to comment #10) > nor for the 'first shutdown after a yum upgrade from 16 to 17 crashes' Yeah, maybe my original bug should be unduplicated. +1 on this one. I used preupgrade to from F16 to F17. Everything seems to have worked fine until reboot. Grub still loads F16 kernel, not F17. The boot seems to work but shutdown gives kernel panic. Also, graphics init failed with the proprietary nvidia driver. Some further investigation gives: #yum list installed kernel Installed Packages Installed Packages kernel.x86_64 3.3.6-3.fc16 @updates/16 kernel.x86_64 3.3.7-1.fc16 @updates/16 kernel.x86_64 3.3.7-1.fc17 @anaconda-0 I find this in the grub menu: menuentry 'Fedora (3.3.7-1.fc16.x86_64)' --class fedora --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd0,msdos1)' search --no-floppy --fs-uuid --set=root 5c8db405-2b42-495e-90c3-199c9c8339aa echo 'Loading Fedora (3.3.7-1.fc16.x86_64)' linux /vmlinuz-3.3.7-1.fc16.x86_64 root=/dev/mapper/vg_cinderella-lv_root ro rd.md=0 rd.dm=0 KEYTABLE=sv-latin1 rd.lvm.lv=vg_cinderella/lv_swap rd.lvm.lv=vg_cinderella/lv_root rd.luks.uuid=luks-e5fe3fb6-2f73-4149-a31a-82c1bb845473 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 echo 'Loading initial ramdisk ...' initrd /initramfs-3.3.7-1.fc16.x86_64.img } So it does indeed load the kernel for F16. This might be related to this found in the upgrade.log: 03:47:08 Upgrading kernel-3.3.7-1.fc17.x86_64 grubby fatal error: unable to find a suitable template Simply changing all "fc16" to "fc17" in the grub menu made my system work. Also, the boot seemed to work with fc16 to until it was about to initialize the proprietary nvidia module, which failes as the were different versions, but this did not become apparent why until I booted into runlevel 3 and tried "startx". That gave a verbose error message about version mismatch. Give a look also to https://bugzilla.redhat.com/show_bug.cgi?id=826537 grubby-8.12-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17 For reference, http://git.fedorahosted.org/git/?p=grubby.git;a=commitdiff;h=1dddd842f609042d336c16a6f50f443da7977fdd explains the problem: When there are multiple devices mounted on /, as there can be during a preupgrade, the last device is the one that should match the grub.cfg entry. This was preventing preupgrade from installing the new f17 kernel. I just did the pre-upgrade this morning. The upgrade seemed to work, but no FC17 kernel was added in my /etc/grub2.cfg file. The kernel was installed but the config file was not updated. Once I updated the /etc/grub2.cfg to point to the new FC17 kernel - 'Fedora (3.3.7-1.fc17.x86_64)' - that was my workaround that worked. What about merging these 2 bugreports https://bugzilla.redhat.com/show_bug.cgi?id=820340 https://bugzilla.redhat.com/show_bug.cgi?id=826537 into https://bugzilla.redhat.com/show_bug.cgi?id=820351 ? I'm marking this bug as a duplicate of bug 826537. Even though this one was created earlier, more information and logs are there. I'll leave bug 820351 separate for now, because it was (originally) about DVD upgrades and the other two are about preupgrade. *** This bug has been marked as a duplicate of bug 826537 *** grubby-8.12-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |