Hi!
I have been using Fedora Core 14 on an old desktop as my file server with three hard drives in it all configured in LVM except for /boot. The other day I couldn't connect via SMB and then I realized I couldn't ping it either, so I went and checked from the console and it was at a black screen - eek! So I powered it off and back on (CTRL+ALT+DEL wouldn't work; guess I could have tried opening another terminal but I don't think it would have worked either).

When it booted up, it didn't even get to grub, it went through bios post and then to a black screen with a cursor blinking. ack!

I booted from installation media and did an fsck but no joy.

I booted from installation media and looked at my /boot/grub/menu.1st file and it *looked* fine, but I saw a lot of posts about kernel updates having gone wrong and changing the hd info (i.e. hd0,0 to hd0,1). I of course didn't think to back THAT stuff up, just my data...

When I try to use grub shell to "find /boot/grub/menu.lst" I get an error - Error 15: file not found. I did indeed chroot /mnt/sysimage it and I confirm I was using an l (el) not a 1 (one) for menu.lst. If I try to do init3 as well, I get the error "Failed to connect to socket /ubuntu/com/upstart: connection refused". I couldn't find much of use about that error, and the file not found error gave me little hope for going through and guessing each disk/partition combo to use in menu.lst but if it comes to that I guess I have no choice...

So I guess I'm trying to figure out:
1/ Is there something I am doing wrong to determine if hd0,0 is indeed right in my menu.lst?
2/ Is this a boot/grub issue or is it upstart (new to me)?
3/ Am I WAY out to lunch on this and not even close to fixing it?

I presume it's a grub/boot issue because it doesn't load grub but if I get into rescue environment I can start up ssh and smb and use smb no problem (hehe). I looked at yum history (I had it cron'd to update every four hours) and it had indeed had kernel packages updated lately. We had a power failure the morning I discovered all this fun so I'm wondering if it wasn't indeed a kernel update gone bad (because this would be the first reboot since)? Maybe I should stick to manually yum'ing my boxes (however the same O/S install on another PC acting as a web server does the same thing but was fine - perhaps different disk counts and whatnot is what saved me there, or just dumb luck ha!).

Any help is appreciated. Hopefully I've provided sufficient detail to go on here.

You don't happen to have those three disks in a linux software raid (mdadm) array as well do you? If so it might be looking for a device ID to get everything mounted which I've had change on me after a kernel update before. I'm afraid I don't know how to manually fix it as I wasn't running the system on the lvm on top of raid (just rebuilt the array and updated the mdadm config with the new ID.)

No sir just LVM on top of the physical disks, no software raid (

Being a new Dad doesn't provide me much time to research this stuff on my own time anymore, so I had recently resigned myself to accepting having to boot into rescue mode to get the system up and running past GRUB.

Then today at work I was investigating block level alignment to VMware guests running RHEL with the storage back-end (NetApp SAN). I found a document that walks one through a utility that is a part of the ESX host utility kit from NetApp called MBRAlign. The document goes on to say that after you align Linux guests, grub likely needs to be reinstalled and they provided detailed steps - ding ding ding --> yay! This is exactly what I need. I was trying to fix my issue with "grub-install" and tried identifying the whole (hd0,0) thing with every possible combination I knew possible each time I had to reboot (due to power outage or whatnot). Then, I found this document and found the missing steps, which are (after booting into rescue mode and chrooting the system):

1 - grub
2 - root (hd0,0)
3 - setup (hd0)
4 - quit

This didn't work the first time, I tried something like hd1,0 in the second step and it worked! It got me to the boot loader to the point where I could see the kernels, but it still failed to boot however after a quit edit there to point it at hd1,0 instead of hd2,0, it works! Now I just need to make that change persistent in /boot/menu.lst and I am good

So the issue was that grub couldn't find the second part of the loader (or whatever).

yay!!! So happy

Did NOT want to reinstall and didn't have time to figure it out on my own, hopefully someone else in this situation can make use of this post and benefit them