Bug 882534 - After an upgrade from F17 to F18 using fedup, F18 can't boot (unable to mount FS).
Summary: After an upgrade from F17 to F18 using fedup, F18 can't boot (unable to mount...
Keywords:
Status: CLOSED DUPLICATE of bug 873455
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 18
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-01 18:26 UTC by Olivier LEVILLAIN
Modified: 2012-12-02 14:42 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-02 12:28:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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).


Note You need to log in before you can comment on or make changes to this bug.