From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Galeon/1.3.17 Description of problem: I've proceeded to a Fedora Core 2 -> Fedora Core 3 Test 2 upgrade. I've choosed to updated the bootloader during the process. I had 2 or 3 smp kernels installed before the upgrade. After the upgrade, when i attempted to boot for the first time, grub was showing only one kernel and it was the oldest one (2.6.6-1.XXXXXsmp from FC2 updates). I did press return to try to boot, but grub said "no such file or directory". I've edited the kernel and initrd lines to boot 2.6.8-1.541smp kernel and it worked. Anaconda did upgrade the kernel (and re-install the up kernel i didnt want..) : [root@gruyere ~]# rpm -q kernel kernel-smp kernel-2.6.8-1.541 kernel-smp-2.6.8-1.541 but it didnt updated the grub.conf with correct informations. How reproducible: Didn't try.
Are there any errors in the /root/upgrade.log? Are those kernels definitely from packages?
Yes, those kernels are from packages. Here are the errors from the /root/upgrade.log : Mise à jour de kernel-2.6.8-1.541.i686. cp: ne peut évaluer `/dev/md0': Aucun fichier ou répertoire de ce type grubby fatal error: unable to find a suitable template grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. Mise à jour de kernel-smp-2.6.8-1.541.i686. cp: ne peut évaluer `/dev/md0': Aucun fichier ou répertoire de ce type grubby fatal error: unable to find a suitable template Mise à jour de openldap-2.2.13-2.i386. (Do you want the complete log ?) There are some messages in french as I'm french and wanted to test translations. "Aucun fichier ou répertoire de ce type" means "No such file or directory". "Mise à jour de" -> "Upgrading" I believe grubby screwed up things because I had no UP kernels installed.
Not entirely sure why the kernel package is being pulled in (probably a dependency, I'll track that down later) The more interesting part is: cp: ne peut évaluer `/dev/md0': Aucun fichier ou répertoire de ce type Is your root on raid or does your fstab reference a raid device?
my root filesystem is on a classic primary partition (sda2). I got a software raid 1 volume, though and the fstab is actualy refering it : /dev/md0 /mnt/anvil ext3 defaults 1 2 Do you you want the entire fstab file ? The raid volume was mounted during the upgrade process (i've checked). An LVM volume too.
By the way i've just manualy installed kernel-smp-2.6.8-1.541 and this left my with completly broken bootloader : it just printed "GRUB GRUB" with a black screen. Should I fill a separated bug report or do you think this is related ?
Similar problem here on a uniprocessor box. I was doing an NFS upgrade of an FC2 box. In order to boot the installer, I extracted the kernel and initrd from the boot.iso image and put them in /boot. I then added the following entries to grub.conf: title FC3T2 Install root (hd0,5) kernel /boot/fc3t2-vmlinuz ramdisk_size=8192 initrd /boot/fc3t2-initrd.img title FC3T2 Install (text) root (hd0,5) kernel /boot/fc3t2-vmlinuz ramdisk_size=8192 text initrd /boot/fc3t2-initrd.img title FC3T2 Install (expert) root (hd0,5) kernel /boot/fc3t2-vmlinuz ramdisk_size=8192 expert initrd /boot/fc3t2-initrd.img title FC3T2 Install (lowres) root (hd0,5) kernel /boot/fc3t2-vmlinuz ramdisk_size=8192 lowres initrd /boot/fc3t2-initrd.img These entries were in addition to the existing entries for the FC2 kernel and dual-boot Windows entry. Install proceeded painlessly, but on reboot the FC2 kernel entry was gone and there was no FC3T2 kernel entry to replace it. So no way of booting into FC3T2 from the menu. By manually selecting the kernel and initrd I was able to boot up and then add the required entry to grub.conf. Booting then worked as expected. The upgrade.log indicated that grubby had not found the FC2 kernel entry to use as a template: ... Upgrading kernel-2.6.8-1.541.i686. grubby fatal error: unable to find a suitable template grubby fatal error: unable to find a suitable template ... I don't have a copy of the original grub.conf but I know that the FC2 kernel entry was created during the post-install scriptlet for the last FC2 kernel update, and hence there should have been no problem identifying it. I don't suppose there's any chance of leaving the existing kernel in place during an upgrade so that this sort of problem is easier to recover from?
I had a similar problem. Before the install my GRUB menu had several FC2 kernels and windows XP. After I upgraded (using the CDs) to FC3T2, the only option was XP. I booted on the rescue disk and added the FC3t2 kernel to grub.conf and it loads properly now. Machine details: Gateway 600YGR laptop with 1 40GB hdd. hd(0,0) is windows, hd(0,1) is /boot and hd(0,2) is /.
*** Bug 133337 has been marked as a duplicate of this bug. ***
Can you provide the full upgrade.log with the failure? My attempt here just succeeded...
Created attachment 104665 [details] upgrade.log Here's the full upgrade.log
Similar problem. grub.conf was not updated - ut only had an entry for a KnoppMyth partition. After I (in rescue mode) edited grub.conf, it hangs just saying GRUB Now, in rescue mode again, after chroot /mnt/sysimage I tried: grub-install /dev/hda which writes: Unknown partition table signature (after a timeout it repeats the same error message.) This is test2 - I haven't tried test3.
Same problem. I made an update from fedora core 2 to fedora core 3 test 3 today, everything seemed ok, but when I rebooted grub showed me only the windows boot option. I tried to boot using parameters - kernel=/vmlinuz... - initrd=/initrd... but after some lines of booting the error "errors mounting root kernel panic: attempted to kill init" appeared. My drives are all on raid (exclusion for /boot) and ext3. Till now FC2 worked (almost;)) without problems. If I can post new and useful information I'd be willing to post them. Thank you for all your work! Andrea Bondi
I still have this problem with fc3 release candidate :(
FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier.
Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest this issue on a current release or on the latest development / test version, we would appreciate that. Otherwise, this bug will be marked as CANTFIX one month from now. Thanks for your help and for your patience.