LinuxQuestions.org - Grub FUBARed

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - Grub FUBARed (https://www.linuxquestions.org/questions/linux-software-2/grub-fubared-577442/)

I had a beautifully working Ubuntu installation; stable, solid, smooth. But my wife needs me to teach her how to use a piece of software that only runs in windows. I was a little bored with how well my Ubuntu was running anyway, so I decided to re-install EVERYTHING. I have an external SATA drive that holds all of my important data, but no OS.

I disconnected my SATA to protect it from accidental corruption. I repartitioned my two internal IDE drives, and installed this way...

hda1__ Windows
hda2__ swap
hda3__ ext3 empty

hdb1__ swap
hdb2__ Feisty Fawn Ubuntu
hdb3__ ext3 empty
hdb5__ ext3 empty
hdb6__ ext3 empty

sda1__ ext3 empty
sda2__ xfs Full of important stuff

sda was disconnected for the install of both the Windows and the Ubuntu OSs. Both booted easily, and then I connected the SATA, sda, and grub started throwing out all kinds of problems. First it gave an error 15, and after a bit of tweaking it gave error 17 (two better than 15?)

I've read several how to's and the man pages for grub. I'm lost. I'm an experienced linux user, but I used to do all of my fancy boot loader stuff with lilo. I could go back to lilo, but everyone seems to be moving to grub, so I want to learn grub. Especially since it's the default for Ubuntu.

Ok, so here's the present situation. Grub is spitting out "error 17" on boot. BUT, if I use the Feisty Fawn install disk, and tell it to boot the first hard drive on the boot screen, it brings up the grub menu and boots as it should, and boots Ubuntu using the grub reference to (hd1,1) as root for Ubuntu.

Here's my configuration. My boot directory is on my Feisty install, /dev/hdb2. My bios has the SATA as the last of the hard drives in the boot order.

/dev/hdb2 /boot/grub/menu.lst

Code:

# menu.lst - See: grub(8), info grub, update-grub(8)

#            grub-install(8), grub-floppy(8),

#            grub-md5-crypt, /usr/share/doc/grub

#            and /usr/share/doc/grub-doc/.



## default num

# Set the default entry to the entry number NUM. Numbering starts from 0, and

# the entry number 0 is the default if the command is not used.

#

# You can specify 'saved' instead of a number. In this case, the default entry

# is the entry saved with the command 'savedefault'.

# WARNING: If you are using dmraid do not change this entry to 'saved' or your

# array will desync and will not let you boot your system.

default                1



## timeout sec

# Set a timeout, in SEC seconds, before automatically booting the default entry

# (normally the first entry defined).

timeout                3



## hiddenmenu

# Hides the menu by default (press ESC to see the menu)

#hiddenmenu



# Pretty colours

#color cyan/blue white/blue



## password ['--md5'] passwd

# If used in the first section of a menu file, disable all interactive editing

# control (menu entry editor and command-line)  and entries protected by the

# command 'lock'

# e.g. password topsecret

#      password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/

# password topsecret



#

# examples

#

 title                Windows 95/98/NT/2000

 root                (hd0,0)

 makeactive

 chainloader        +1

#

# title                Linux

# root                (hd0,1)

# kernel        /vmlinuz root=/dev/hda2 ro

#



#

# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST



### BEGIN AUTOMAGIC KERNELS LIST

## lines between the AUTOMAGIC KERNELS LIST markers will be modified

## by the debian update-grub script except for the default options below



## DO NOT UNCOMMENT THEM, Just edit them to your needs



## ## Start Default Options ##

## default kernel options

## default kernel options for automagic boot options

## If you want special options for specific kernels use kopt_x_y_z

## where x.y.z is kernel version. Minor versions can be omitted.

## e.g. kopt=root=/dev/hda1 ro

##      kopt_2_6_8=root=/dev/hdc1 ro

##      kopt_2_6_8_2_686=root=/dev/hdc2 ro

# kopt=root=UUID=d0b556d9-7ba0-43cb-85ea-5badde152ddd ro



## Setup crashdump menu entries

## e.g. crashdump=1

# crashdump=0



## default grub root device

## e.g. groot=(hd0,0)

# groot=(hd1,1)



## should update-grub create alternative automagic boot options

## e.g. alternative=true

##      alternative=false

# alternative=true



## should update-grub lock alternative automagic boot options

## e.g. lockalternative=true

##      lockalternative=false

# lockalternative=false



## additional options to use with the default boot option, but not with the

## alternatives

## e.g. defoptions=vga=791 resume=/dev/hda5

# defoptions=quiet splash



## should update-grub lock old automagic boot options

## e.g. lockold=false

##      lockold=true

# lockold=false



## Xen hypervisor options to use with the default Xen boot option

# xenhopt=



## Xen Linux kernel options to use with the default Xen boot option

# xenkopt=console=tty0



## altoption boot targets option

## multiple altoptions lines are allowed

## e.g. altoptions=(extra menu suffix) extra boot options

##      altoptions=(recovery) single

# altoptions=(recovery mode) single



## controls how many kernels should be put into the menu.lst

## only counts the first occurence of a kernel, not the

## alternative kernel options

## e.g. howmany=all

##      howmany=7

# howmany=all



## should update-grub create memtest86 boot option

## e.g. memtest86=true

##      memtest86=false

# memtest86=true



## should update-grub adjust the value of the default booted system

## can be true or false

# updatedefaultentry=false



## ## End Default Options ##



title                Ubuntu, kernel 2.6.20-16-generic

root                (hd1,1)

kernel                /boot/vmlinuz-2.6.20-16-generic root=UUID=d0b556d9-7ba0-43cb-85ea-5badde152ddd ro quiet splash

initrd                /boot/initrd.img-2.6.20-16-generic

quiet

savedefault



title                Ubuntu, kernel 2.6.20-16-generic (recovery mode)

root                (hd1,1)

kernel                /boot/vmlinuz-2.6.20-16-generic root=UUID=d0b556d9-7ba0-43cb-85ea-5badde152ddd ro single

initrd                /boot/initrd.img-2.6.20-16-generic



title                Ubuntu, kernel 2.6.20-15-generic

root                (hd1,1)

kernel                /boot/vmlinuz-2.6.20-15-generic root=UUID=d0b556d9-7ba0-43cb-85ea-5badde152ddd ro quiet splash

initrd                /boot/initrd.img-2.6.20-15-generic

quiet

savedefault



title                Ubuntu, kernel 2.6.20-15-generic (recovery mode)

root                (hd1,1)

kernel                /boot/vmlinuz-2.6.20-15-generic root=UUID=d0b556d9-7ba0-43cb-85ea-5badde152ddd ro single

initrd                /boot/initrd.img-2.6.20-15-generic



title                Ubuntu, memtest86+

root                (hd1,1)

kernel                /boot/memtest86+.bin

quiet



### END DEBIAN AUTOMAGIC KERNELS LIST

/dev/hdb2 /boot/grub/devices.

Code:



(hd1)        /dev/hda

(hd2)        /dev/sdb

Ok, I just realized that's messed up. I'll try to fix that bit and get back to ya'll. In the mean time, any other thoughts or insights?

Thanks.

Check the BIOS boot order, and make sure the IDE is first.

Checked and double checked.

My bios has an odd boot order setup.
The CD-rom is set to the first,
Hard Drive is set to second.

Then under the hard drive boot order, hda is first, hdb, second, and sda, last. I'd remove sda entirely if possible, but it isn't possible in my bios.

It was a fresh install of Ubuntu, and I really need to get this system up and running, so I'm re-installing tonight, hoping that the install will fix grub.

I had this setup with the same drives, but Ubuntu on hda2, and I never had an issue. Does grub have an issue with the /boot directory being on the slave drive?

Thanks.
If the install fixes this, I'll post the generated config files so we can compare and see what went wrong.

I'm a little doubtful though, so keep those ideas coming.

Re-install didn't work

I reinstalled Ubuntu Feisty to fix grub, but it ended up worse than I began. They system is now completely unbootable, even using the Ubuntu liveCD booting to first harddrive trick.

it results in a grub "error 18".

All of this seems to point to a bios issue, which I think is odd since it all worked before.

My mobo is an Abit AN8 32X with SATA. I haven't changed any BIOS settings. My HDs are set to auto detect. I haven't moved the harddrives. I repartitioned and installed into different partitions.

here are the new config files generated by the Ubuntu live install with the SATA drive connected during the install.

/boot/grub/menu.lst

Code:

# menu.lst - See: grub(8), info grub, update-grub(8)

#            grub-install(8), grub-floppy(8),

#            grub-md5-crypt, /usr/share/doc/grub

#            and /usr/share/doc/grub-doc/.



## default num

# Set the default entry to the entry number NUM. Numbering starts from 0, and

# the entry number 0 is the default if the command is not used.

#

# You can specify 'saved' instead of a number. In this case, the default entry

# is the entry saved with the command 'savedefault'.

# WARNING: If you are using dmraid do not change this entry to 'saved' or your

# array will desync and will not let you boot your system.

default                0



## timeout sec

# Set a timeout, in SEC seconds, before automatically booting the default entry

# (normally the first entry defined).

timeout                3



## hiddenmenu

# Hides the menu by default (press ESC to see the menu)

hiddenmenu



# Pretty colours

#color cyan/blue white/blue



## password ['--md5'] passwd

# If used in the first section of a menu file, disable all interactive editing

# control (menu entry editor and command-line)  and entries protected by the

# command 'lock'

# e.g. password topsecret

#      password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/

# password topsecret



#

# examples

#

# title                Windows 95/98/NT/2000

# root                (hd0,0)

# makeactive

# chainloader        +1

#

# title                Linux

# root                (hd0,1)

# kernel        /vmlinuz root=/dev/hda2 ro

#



#

# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST



### BEGIN AUTOMAGIC KERNELS LIST

## lines between the AUTOMAGIC KERNELS LIST markers will be modified

## by the debian update-grub script except for the default options below



## DO NOT UNCOMMENT THEM, Just edit them to your needs



## ## Start Default Options ##

## default kernel options

## default kernel options for automagic boot options

## If you want special options for specific kernels use kopt_x_y_z

## where x.y.z is kernel version. Minor versions can be omitted.

## e.g. kopt=root=/dev/hda1 ro

##      kopt_2_6_8=root=/dev/hdc1 ro

##      kopt_2_6_8_2_686=root=/dev/hdc2 ro

# kopt=root=UUID=00dff890-cd64-47d2-bec7-c2208f57969c ro



## Setup crashdump menu entries

## e.g. crashdump=1

# crashdump=0



## default grub root device

## e.g. groot=(hd0,0)

# groot=(hd1,1)



## should update-grub create alternative automagic boot options

## e.g. alternative=true

##      alternative=false

# alternative=true



## should update-grub lock alternative automagic boot options

## e.g. lockalternative=true

##      lockalternative=false

# lockalternative=false



## additional options to use with the default boot option, but not with the

## alternatives

## e.g. defoptions=vga=791 resume=/dev/hda5

# defoptions=quiet splash



## should update-grub lock old automagic boot options

## e.g. lockold=false

##      lockold=true

# lockold=false



## Xen hypervisor options to use with the default Xen boot option

# xenhopt=



## Xen Linux kernel options to use with the default Xen boot option

# xenkopt=console=tty0



## altoption boot targets option

## multiple altoptions lines are allowed

## e.g. altoptions=(extra menu suffix) extra boot options

##      altoptions=(recovery) single

# altoptions=(recovery mode) single



## controls how many kernels should be put into the menu.lst

## only counts the first occurence of a kernel, not the

## alternative kernel options

## e.g. howmany=all

##      howmany=7

# howmany=all



## should update-grub create memtest86 boot option

## e.g. memtest86=true

##      memtest86=false

# memtest86=true



## should update-grub adjust the value of the default booted system

## can be true or false

# updatedefaultentry=false



## ## End Default Options ##



title                Ubuntu, kernel 2.6.20-15-generic

root                (hd1,1)

kernel                /boot/vmlinuz-2.6.20-15-generic root=UUID=00dff890-cd64-47d2-bec7-c2208f57969c ro quiet splash

initrd                /boot/initrd.img-2.6.20-15-generic

quiet

savedefault



title                Ubuntu, kernel 2.6.20-15-generic (recovery mode)

root                (hd1,1)

kernel                /boot/vmlinuz-2.6.20-15-generic root=UUID=00dff890-cd64-47d2-bec7-c2208f57969c ro single

initrd                /boot/initrd.img-2.6.20-15-generic



title                Ubuntu, memtest86+

root                (hd1,1)

kernel                /boot/memtest86+.bin

quiet



### END DEBIAN AUTOMAGIC KERNELS LIST

/boot/grub/device.map

Code:

(hd0)        /dev/hda

(hd1)        /dev/hdb

(hd2)        /dev/sda

Ok, it's 2:30am here. I'm going to bed. More tomorrow.

Maybe there's something messed up in my partitions? I don't have a lot invested yet (just a lot of time), I could re-partition again.

Ideas?:confused:

I've never seen anything like your kernel line with

Code:

/boot/vmlinuz-2.6.20-15-generic root=UUID=00dff890-cd64-47d2-bec7-c2208f57969c ro quiet splash

Is that normal for Ubuntu?

Did you change the SATA port? Did you boot from the SATA device in your original working configuration?

You might want to try the map command of GRUB

Code:

map (0,2)

map (2,0)

Read the documentation in the GRUB manual first...

http://www.gnu.org/software/grub/manual/
http://www.linuxquestions.org/questi...41#post1208741
http://www.tldp.org/HOWTO/Multiboot-with-GRUB.html

I'm not sure about the boot line being "normal" for Ubuntu. Ubuntu did generate it, and it does match the uuid of the proper partition. I have used uuid in fstab before to make sure to target the correct partition no matter where it is recognized by the bios/os. Usually I do this with usb type drives, such as my sata drive who's drive assignment can be affected by other peripherals. If I always want it to have the same mount point, I use its uuid instead of its dev assignment.

I was not booting from the sata before, and i didn't change the port it's plugged into. It's external, so there is a sata extender that plugs into my mobo and provides a port in one of the pci slot openings. the external drive then plugs into that slot on the back of the PC. I never opened the case during the process. To disconnect the sata, I just unplugged it from the back of the external box and back in again later.

I also re-installed Ubuntu last night with the sata plugged in and running to see if that would fix grub. It's actually worse now.

I'm seriously considering stripping everything down and repartitioning hda and hdb with sda connected, then reinstalling windows and ubuntu.

Something about all of this feels oddly familiar to a time seven years ago when I did a re-partitioned re-install with windows and linux and messed up the partitions, rendering the whole system unbootable, even though everything looked good. It was a long time ago, so I don't recall much, but it has an oddly familiar feeling. Of course that was back with lilo and back when that 1024 block thing really mattered.

I'll look into and try the drive map thing you suggested first, but I have to get the kids to the dentist right now, so it will be later today.

Thanks for your continued help and to everyone else who reads and considers....

We'll fix this yet.

The BIOS is finding the loader code o.k. - presumably on the /dev/hda MBR.
If it were me, to completely take this issue out of (future) consideration, I'd create a (ext2) /boot partition for Feisty on /dev/hda. Doesn't need to be big - 100Meg should be plenty, even allowing for temporary increases during upgrades.

Lilo should avoid this issue, but I haven't used it this millennium, so treat that opinion as suspect.

creating a /boot partition would be a very functional solution, and I know separating the OS among partitions protects against corruption of the whole system, but I boot many distros and a few OSs, and fragmenting any single OS among different partitions will confuse the whole setup.

Having now repartitioned, I'm reinstalling as we speak. Hopefully that will fix it. I'm also planning on using a lilo technique that I used to use when I was booting 9 different distros.

For each distro, at install, I put the boot loader for that distro in its own partition. Then I put a lilo install in the MBR that chain loads all of the other partitions no matter what OS is there, triggering the boot loader in that partition. The partition boot loaders are set to a 1 sec delay, and the MBR is set to a 5 sec delay (to allow for selection).

Since lilo doesn't depend on config files in any particular partition after it's installed, changing or losing any partition won't effect the bootability of the whole system. With Grub, if the config files are in hdb2, and for some reason I change or corrupt hdb2, then the whole system becomes unbootable.

I'll post back here if that works.

I reckon chainloading multiple distros is much easier using grub. No need to worry about running the lilo command all the bloody time.

Each to their own.

It's too hard to do it from a liveCD anyway. I keep getting weird errors.

I had it setup and working from a floppy, but managed to mess that up while trying to get grub to work from the hard drive.

It's been so long that I don't recall all of the terminology for setting it up lilo. I've not used lilo in many years, and I guess I'm not really interested in investing the time to re-learn it since, it seems, no one is using it.

I'm re-installing your way. I put a /boot partition on hda and / on hdb1 with grub going into hd0. Hopefully that will work. It's installing now.

I have to say, this really sucks. It shouldn't be this complicated. I still get this creepy feeling it has something to do with my bios and my ignorance of the complexities of grub. But I've reset all of the bios to defaults, and that didn't work. So I reset it to "optimized defaults" and that didn't work.

Why isn't there a gui for this? I really don't mind the command line. I spend a lot of time in terminal, but this is ridiculous.

If it wasn't for liveCDs I'd be hosed! Thanks to everyone an anyone who makes them!

As always, I'll post back with the results of this next attempt.

Ok,
That reinstall went well. Windows in in hda1, there's a swap partition as hda2, there's a little (600MB) /boot partition for Ubuntu on hda3, and Ubuntu rests in hdb1. More importantly, it boots.

As a precaution, I've backed up my grub directory, and backed up the boot sector of hda to that same folder. I hope that if something gets messed up by later distro installs on other partitions, I'll be able to recover using those. I will make an effort to NOT write the boot loader to the MBR of sda on later installs though. ;)

Any tips on chain loading grub, or is there a good guide to advanced grub configurations with linux distros?

I'm almost terrified to install other distros into this setup now.

Thanks for your help. I've still a bit to learn, but then we all do, don't we? That's what I love about forums.

I've never believed in backing up MBR - except when I've been testing and expect to (deliberately) destroy the MBR immediately. Normally there is nothing to gain - and you can make an unholy mess of your systems if you happen to change partition allocation between the backup and restore. Grub is easy to re-install to the MBR from any liveCD.
For backing up the partition table I like sfdisk - it gives you a text file you can feed back into sfdisk to rebuild the partition table. Again only any use if it's (always) current. See the manpage.

For the chainloading, install every distro after the first with it's boot loader in the partition rather than MBR. Then it's as simple as

Code:

title Number 2

root (hd0,3)

chainloader +1

title Number 3

root (hd1,0)

chainloader +1

Adjust and replicate as needed.

If you want some light reading try saikee (a user here) sig line; used to be plenty there.

SuSE does new installations with GRUB in the MBR faultlessly since I first tried it years ago. I don't know about the other distributions but since this is GRUB they should be okay as well.

So when I create a new instance of the OS (I have several for testing etc.) I just let the latest GRUB handle it, never had any problem with that. So chain loading is not really necessary from my experience.

It's strange. The only issue I can see with the way I installed it was that grub was being installed on the MBR of a different drive than the boot partition with it's config files. Once I put the config files on a partition on the same drive, it all worked. Maybe it's a thing with my bios and the way it's recognizing drive assignments... I don't know, and hopefully I won't have to find out.

Thanks again for your help.

syg00,
thanks. That's a lot like the way I did it with lilo. It's good to see the syntax is not too complicated. One day I'll have to sit down and read the grub man pages.

Quote:

Originally Posted by mlitty (Post 2865325)

...One day I'll have to sit down and read the grub man pages.

:D ;)

Originally I just wanted to leave the smilies for you, but the forum demands some text from me. So here it is, forum :p.