I'm having some grub issues with a clean install of F9 on a multi boot system where I'm not letting anaconda install grub. Install goes fine, and when I try and reboot, I'm getting grub error 2.

Typically you get this where grub can't find a file (so if the menu.lst entry pointed the kernel to vmlinux... rather than vmlinuz... for example).

Playing around in grub, I can't even find the Fedora kernel, so find /boot/vmlinuz (I have a vmlinux symlink in /boot) finds it on other partitions but not the one Fedora is on. Won't boot to full kernel name either.

I'm only using an ext3 partition, so nothing weird there.

I suspect I should just delete the partition and start again, but I thought I'd just ask here and see if anyone has seen anything similar, if grub has been updated recently or similar (my grub is from OpenSuSe 10.3, so it's not exactly old)

Thanks in advance

Edit - ps - partition seems to mount fine from other distros

Haven't experienced this myself, but I do have a few ideas to run through. Is /boot on its own partition or off of the / partition? If it is on its own you would want to do a find on /vmlinuz. Another option would be to try and find the kernel delivered with F9...

vmlinuz-2.6.25.3-18.fc9.i686

Another alternative for you. I've always had luck with using rescue mode off the CD or DVD. It has will search out and find any Fedora installations. At the least, this method might help you take a look at what you have and perhaps render a solution.

Last one, I've seen a few notes in my travels about getting an Error 2 and it being caused by a corrupt ext3 partition. You could try running fsck from rescue mode or another install. Other option is as you said, go for a reinstall.

No, it's on /, but I'd tried that anyway. I could have tried the long version, but I didn't have the number on hand.

I think I tried the rescue mode thing (it was a couple of days ago now), and as I said, I can mount fine from other distros.

I think I'll just kill the partition and start again


Thanks

Anaconda - been poorly designed/implemented from the start.

Always install grub. No ifs, no buts.
It's not just grub - it's also the copying of the kernel and initrd (yuck) ... yada, yada.
Gawd I hate "helpful" installers.

Install grub to the root partition, and then just grab the applicable lines from the deadrat menu.lst, and copy them into your real menu.lst

Actually I tried that the first install, but had the same issue. the relevant items are in /boot - the kernel and initrd. That's the weird part and why I think it's a partition problem.

I don't normally install grub because most installers don't make it clear where they'reinstalling it - anaconda is way better on that front

I am having the same issue. I have 4 OS'es on the drive, so I didn't install the F9 GRUB because I already have CentOS5 GRUB on the MBR. I duplicated the GRUB config, but I get

"Error 2: Bad Directory or File type"

As reported, the file type of the new kernel is different. I'm including the F9 kernel type ( /mnt/fed/boot/vmlinuz ) and the C5 ( /boot/vmlinuz ) types for the viewing public. Hopefully, someone can cut and paste the GRUB config from their own working F9 installation.

-- Mario

[localhost.localdomain:~] # mount /dev/sda5 /mnt/fed

[localhost.localdomain:~] # file /mnt/fed/boot/vmlinuz-2.6.25-14.fc9.i686
/mnt/fed/boot/vmlinuz-2.6.25-14.fc9.i686: Linux kernel x86 boot executable RO-rootFS, swap_dev 0x1, Normal VGA

[localhost.localdomain:~] # file /boot/vmlinuz-2.6.18-8.el5
/boot/vmlinuz-2.6.18-8.el5: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped


[localhost.localdomain:~] # cat /boot/grub/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd0,0)
# kernel /boot/vmlinuz-version ro root=/dev/sda1
# initrd /boot/initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu

title CentOS 5 (2.6.18-8.el5)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.18-8.el5.img

title Fedora 9 (2.6.25-14.fc9.i686)
root (hd0,4)
kernel /boot/vmlinuz-2.6.25-14.fc9.i686 ro root=LABEL=/1 rhgb quiet
initrd /boot/initrd-2.6.25-14.fc9.i686.img

title Ubuntu 8.04 (2.6.24-16-generic)
root (hd0,1)
kernel /boot/vmlinuz-2.6.24-16-generic ro root=/dev/sda2
initrd /boot/initrd.img-2.6.24-16-generic

title FreeBSD 7.0
root (hd0,2,a)
kernel /boot/loader

[localhost.localdomain:~] #

I couldn't get F9 to boot directly, but I ended up deleting the partition, recreating a partition, installing F9 onto the new the new partition (sdb11) and grub on the boot sector of sdb11 and chainloading with

title Fedora
rootnoverify (hd0,10)
chainloader +1
boot

(note that my system boots off the second HDD, hence the hd0 even though it's sdb)

I don't think the boot is necessary, and I'll try taking it out a some stage.

I had tried this route the first time I instlled F9 but it didn't work fo some reason

The F9 release notes say that before installing/upgrading you have to check if your drives are labelled properly.
Maybe that is the problem (or part of it).


I can give you my working grub.conf

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd0,2)
# kernel /boot/vmlinuz-version ro root=/dev/sda3
# initrd /boot/initrd-version.img
#boot=/dev/sda
default=0
timeout=10
splashimage=(hd0,2)/boot/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.25.3-18.fc9.x86_64)
root (hd0,2)
kernel /boot/vmlinuz-2.6.25.3-18.fc9.x86_64 ro root=UUID=20beb50e-3701-47d2-942b-fc0d3abae31b rhgb quiet
initrd /boot/initrd-2.6.25.3-18.fc9.x86_64.img
title Fedora (2.6.25-14.fc9.x86_64)
root (hd0,2)
kernel /boot/vmlinuz-2.6.25-14.fc9.x86_64 ro root=UUID=20beb50e-3701-47d2-942b-fc0d3abae31b rhgb quiet
initrd /boot/initrd-2.6.25-14.fc9.x86_64.img
title Other
rootnoverify (hd0,0)
chainloader +1
title SUSE
rootnoverify (hd0,3)
chainloader +1

My partitions (all of them, see sig) were already labelled thus in F8. I did not do that manually.

No, it wasn't a labeling issue - I tried the root=/dev/sdb9 route that works with other distros. i think it was a partition issue, but not entirely sure. Anyway, working now

Thank you Bill Mayday - reinstalling with GRUB on the partition's first sector with the following stanza in the main GRUB has allowed me to finally boot into F9 . --MC

title Fedora
rootnoverify (hd0,4)
chainloader +1

I came across this link http://www.linuxquestions.org/questi...rror-2-643342/ which seems to indicate that newer ext3 partitions look a bit different to the old ones and older grubs can't handle it.

I pretty much suspect this was the issue all along.

I just stumbled on this as well, with Fedora 9.
It is indeed an inode incompatability. I couldn't chainload Fedora from the Ubuntu (7.10) grub - wouldn't find the grub files at all.
Rather than reformat the Fedora partition, I executed the Fedora grub from Ubuntu, and that allowed me to install grub into the Fedora (root) partition. Chainloading from the old(er) grub then worked as expected.

Edit: I was seriously pissed off that I wasn't offered an option on where to install grub (I wanted to install to the partition during install). Was even more pissed off when I ran into this problem.
Devs need to learn they aren't omnipotent - give us the choice.

This is probably a long solved issue by now, but I recently had exactly the same issue and experienced the the same errors when trying to install Slackware using another distros grub loader. I had exactly the same issues as billymayday. The only way I solved it was to type:

from the grub prompt. Now, I know this was supposed to have then installed grub to the boot directory of the Slackware partition and created a menuu.lst file, but it didn't. It did allow me to then edit the main menu.lst file and Slackware booted right away.

Just thought I'd mention it since this was only a week ago that this occurred.

Bob

Syg, i assume you were peeved at Ubuntu which I don't think gives the option (or at least it isn't clear on where it will install grub), but Fedora certainly does.

Bob, I managed to get Fdora chainloaded as indicated earlier. Don't know why that didn't work the first time

No, I was pissed off at Fedora. The only option I got was to install grub, or not. And believe me I looked, because I run 5 distros (plus Vista) on this laptop, and *didn't* want the MBR over-written.

My first install of a Redhat based distros since a bad experience with RH9. Pretty flaky all round - likely to be a long time before I try again.