Bug 882534

Summary: After an upgrade from F17 to F18 using fedup, F18 can't boot (unable to mount FS).
Product: [Fedora] Fedora Reporter: Olivier LEVILLAIN <olivier.levillain>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: bcl, dcantrell, dennis, mads, pjones
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-02 12:28:15 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 Olivier LEVILLAIN 2012-12-01 18:26:16 UTC
Description of problem:
Under F17, I have run fedup once with no problem 
> fedup-cli --network 18 --debuglog fedupdebug.log --instrepo http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/x86_64/os

Then I rebooted and ran the system upgrage in GRUB2 and the system remained stuck for half an hour after the bars at the bottom of the screen "completed". 
I had to restart my PC.

Then I choosed Fedora 18 in the Grub menu but it crashes at boot (unable to mount FS).

I tried to restart the system upgrade in grub with no effect.
When I look at my grub config, the only difference betweenF17 and F18 is that there is no initrd line in F18.

Version-Release number of selected component (if applicable):
- F18 taken from http://dl.fedoraproject.org/pub/fedora/linux/releases/test/18-Beta/Fedora/x86_64/os, 
- fedup-0.7.1-1.fc8 (now, I suppose it was an fc17 version before)
- grub2-2.00-12.fc18.x86_64

Additional info:
Content (partial) of grub conf file:
menuentry 'Fedora (3.6.7-5.fc18.x86_64)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7 --hint='hd0,msdos7'  8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c
	else
	  search --no-floppy --fs-uuid --set=root 8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c
	fi
	echo 'Loading Fedora (3.6.7-5.fc18.x86_64)'
	linux	/boot/vmlinuz-3.6.7-5.fc18.x86_64 root=UUID=8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0  KEYTABLE=fr LANG=en_US.UTF-8 systemd.unit=system-upgrade.target
	echo 'Loading initial ramdisk ...'
}
menuentry 'System Upgrade' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7 --hint='hd0,msdos7'  8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c
	else
	  search --no-floppy --fs-uuid --set=root 8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c
	fi
	echo 'Loading System Upgrade'
	linux	/boot/upgrade/vmlinuz root=UUID=8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0  KEYTABLE=fr LANG=en_US.UTF-8 systemd.unit=system-upgrade.target
	echo 'Loading initial ramdisk ...'
	initrd	/boot/upgrade/upgrade.img
}
menuentry 'Fedora' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7 --hint='hd0,msdos7'  8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c
	else
	  search --no-floppy --fs-uuid --set=root 8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c
	fi
	echo	'Loading Linux 3.6.7-4.fc17.x86_64 ...'
	linux	/boot/vmlinuz-3.6.7-4.fc17.x86_64 root=UUID=8f7ef541-bcb9-45b1-bc4d-34fcfe3fb24c ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0  KEYTABLE=fr LANG=en_US.UTF-8
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initramfs-3.6.7-4.fc17.x86_64.img
}

Comment 1 Mads Kiilerich 2012-12-01 18:46:14 UTC
Will grub2-config create a correct grub.cfg ?

I guess the problem is that grubby is trying to clone the upgrade entry when it is creating the entry for the new kernel.

This would thus essentially be a duplicate of Bug 873455; they do in my opinion have the same root cause and the same solution.

Comment 2 Olivier LEVILLAIN 2012-12-02 12:28:15 UTC
(In reply to comment #1)
> Will grub2-config create a correct grub.cfg ?
> 
> I guess the problem is that grubby is trying to clone the upgrade entry when
> it is creating the entry for the new kernel.
> 
> This would thus essentially be a duplicate of Bug 873455; they do in my
> opinion have the same root cause and the same solution.

Hi Mads
yes, grub2-config created a correct grub2.cfg file (at least with an initrd line).
Yet, the system doesn't crash anymore at startup but doesn't start correctly (telling that "something went wrong" and that's all)
I mark this bug as a duplicate of Bug 873455; as the remaining problem has nothing to do with this bug I think.

*** This bug has been marked as a duplicate of bug 873455 ***

Comment 3 Mads Kiilerich 2012-12-02 14:42:56 UTC
Others might argue that it is a bug in grubby that it can't clone the upgrade entry or a bug in fedup that it doesn't uninstall the upgrade kernel before installing the new kernel (which creates the new boot entry using grubby).