Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The problem started today after a restart to switch power sources. Before today it would reboot fine everytime.

I recently did update Ubuntu before the problem started. I have tried the find /boot/grub/stage1 from an ubuntu live cd but it didn't find anything. I have tried editing the bios. I have tried countless online solutions but nothing seems to work. Anyone have any ideas? Thanks ahead of time

share|improve this question
    
The error message might be helpful to help diagnose the problem, and what you have to do to actually get it to boot. –  Jon Angliss Aug 13 '10 at 1:01
    
i dont get a boot on the actual system at all. I just use an ubuntu live cd. –  MG-Dev Aug 13 '10 at 1:16
    
Did it successfully boot after the last update? –  David Mackintosh Aug 13 '10 at 1:54

1 Answer 1

Your previous update probably didn't update the grub. If you got a new kernel as part of the update, grub may not be able to find something to boot, especially if the old kernel got removed as part of the update. (I don't know if Ubuntu does this; I know RH-family don't.)

What I usually do when Grub gets unhappy (assuming my grub.conf is set up correctly and the kernel is in the right place):

  • boot from a rescue CD of some sort. Ideally one with the same version of grub that you have installed.
  • re-setup grub from the rescue environment:

rescue# grub

> device (hd0) /dev/sda

> root (hd0,0)

> setup (hd0)

(blah blah blah)

Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p (hd0,0)/boot/grub/stage2

/boot/grub/grub.conf"… succeeded

Done.

> quit

Then sync and reboot. The partitions don't have to be mounted for this to work.

Things to know if you've never done this before:

  • Your disk is always (hd0), even if it is sdb, hdc, whatever.
  • The "root" partition is the partition with the kernel in it: /boot if you have one, / if you don't. The second number is the partition number minus one. So if you have /boot in partition one, it is (hd0,0); if it is in partition two, it is (hd0,1), etc.

It should complain if it can't find what it is looking for and shouldn't be destructively harmful (it shouldn't hose you any harder than you are hosed now). Usually that means that either your disk can't be found (you can test that by mounting it) or you've specified the wrong partition as the "root" volume.

share|improve this answer
    
Sorry for the nasty formatting. I guess the 'code' parser gets confused when you are liberally using other special characters. –  David Mackintosh Aug 13 '10 at 2:07
1  
In my experience, this always works reliably if you can run grub from within the actual file system on disk, not on the rescue CDROM. This could be due to changes in grub or supporting libs since the CD's version. After mounting the boot partition, chroot to it, and then run grub. Chrooted target must have /proc /dev and /sys of live environment mounted. See Rescue example: fermilinux.fnal.gov/documentation/tips/mount-bind-chroot –  labradort Aug 13 '10 at 13:51
    
Excellent clarification. This works for me because I almost always do a "rescue" boot with the same media I used to install, and all my systems are RH-family anyways. –  David Mackintosh Aug 14 '10 at 3:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.