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 }
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.
(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 ***
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).