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: preupgradeAssignee: Richard Hughes <hughsient>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: 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
I did a preupgrade from F16 to F17, at a time when apparently the latest stable kernel for F16 was 3.3.4-3.fc16 and the latest stable kernel for F17 was 3.3.4-3.fc17. 3.3.4-3.fc16 was installed prior to the upgrade.

The result was interesting. rpm -q shows both kernel-3.3.4-3.fc16 and kernel-3.3.4-3.fc17 installed. The grub menu does not have the fc17 kernel on it at all, only the fc16 one, which is booted by default. This causes problems, probably because the initramfs was generated under f16 and so prior to usrmove - notably, I can't shut down:

http://www.happyassassin.net/extras/shutdown_fail.png

I think it's probably a grubby bug, that X.Y-Z.fc17 doesn't supersede X.Y-Z.fc16 in grub config? The fc17 kernel is installed properly and has an initramfs file in /boot, so I think the kernel package does things right, but grubby doesn't.

Comment 1 Peter Jones 2012-05-09 19:45:00 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.

Comment 2 Adam Williamson 2012-05-09 22:42:21 UTC
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

Comment 3 Adam Williamson 2012-05-09 23:32:37 UTC
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!

Comment 4 Peter Jones 2012-05-10 18:17:07 UTC
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.

Comment 5 Josh Boyer 2012-05-14 12:57:05 UTC
*** Bug 821289 has been marked as a duplicate of this bug. ***

Comment 6 Bojan Smojver 2012-05-14 23:48:51 UTC
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).

Comment 7 Mads Kiilerich 2012-05-15 00:00:18 UTC
(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.)

Comment 8 Bojan Smojver 2012-05-15 00:05:35 UTC
(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.

Comment 9 Mads Kiilerich 2012-05-15 00:19:51 UTC
(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.

Comment 10 Adam Williamson 2012-05-15 00:21:29 UTC
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

Comment 11 Bojan Smojver 2012-05-15 00:29:13 UTC
(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.

Comment 12 Bojan Smojver 2012-05-15 00:35:12 UTC
(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.

Comment 13 Jonathan 2012-05-30 08:07:03 UTC
+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.

Comment 14 Germano Massullo 2012-05-30 18:13:33 UTC
Give a look also to
https://bugzilla.redhat.com/show_bug.cgi?id=826537

Comment 15 Fedora Update System 2012-05-31 16:32:48 UTC
grubby-8.12-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/grubby-8.12-1.fc17

Comment 16 Mads Kiilerich 2012-05-31 18:47:45 UTC
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.

Comment 17 marc skinner 2012-05-31 19:16:33 UTC
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.

Comment 19 Kamil Páral 2012-06-01 11:30:21 UTC
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 ***

Comment 20 Fedora Update System 2012-06-02 23:57:23 UTC
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.