Grub FUBARed
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) Code:
Thanks. |
Check the BIOS boot order, and make sure the IDE is first.
|
Boot Order
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) Code:
(hd0) /dev/hda 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 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) 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 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. |
All times are GMT -5. The time now is 07:48 PM. |