I am multibooting with GRUB several Linux distros and Win XP. For a reason that I can't figure out, almost all of the distros on two of my disks (I am using three currently which are partitioned for Linux) have quit booting from GRUB.

Following is my GRUB menu.lst from the MBR.

*notes:
/dev/hda or hd0 will boot
/dev/hde or hd1 won't boot any distro other than Zenlinux (from the Scientific Linux entry?!?!?!?)
/dev/hdg or hd2 won't boot any distro

**** What is odd is that a few of the distros on hd1 try to boot the distros of hd2. That is why I wonder if something has changed about how GRUB sees the disk order. The disk order has not changed in the BIOS. I had a couple of difficult to multiboot distros such as aLinux and Linspire installed. I formatted those partitions (as a first step in trying to fix this) so they are no longer on the system, the menu.lst reflects that. I really don't know what screwed the system up. The only things I did after the last time that I know that it worked properly and booted every Linux are: 1. used synaptic to install a i686 kernel for PCLinuxOS (on the menu.lst), installed aLinux and MyahOS on the now vacant hdi (hd3). I removed MyahOS and aLinux form hd3 as my first step in trying to fix all of this. I am chainloading all of the distros except PCLinuxOS as you can see from the GRUB menu.lst. I will make notes to the side about what is gong on when I try to boot the distros and which bootloader the distro uses.

timeout 10
shade 1
viewport 3 2 77 22
splashimage (hd0,1)/boot/grub/mdv-grub_splash.xpm.gz
default 0

title PCLinuxOS LiveCD Kernel GRUB, boots
kernel (hd0,1)/boot/vmlinuz-2.6.16.27.tex1.lve root=/dev/hda2 splash=silent vga=788
initrd (hd0,1)/boot/initrd-2.6.16.27.tex1.lve.img

title PCLinuxOS i686 kernel GRUB, boots
kernel (hd0,1)/boot/vmlinuz-2.6.16.29.tex1 root=/dev/hda2 splash=silent vga=788
initrd (hd0,1)/boot/initrd-2.6.16.29.tex1.img

title Windows_XP boots
root (hd0,0)
chainloader +1

title Suse 10.1 GRUB, boots
root (hd0,4)
chainloader +1

title Ubuntu GRUB, boots
root (hd0,5)
chainloader +1

title Blag GRUB, boots
root (hd0,6)
chainloader +1

title Mepis GRUB, boots
root (hd0,7)
chainloader +1

title elive GRUB, boots
root (hd0,8)
chainloader +1

title Freespire GRUB, boots
root (hd0,9)
chainloader +1

title Momonga GRUB, error 15
root (hd1,4)
chainloader +1

title Frugalware GRUB, tries to boot VLOS on (hd2,5) but gets error 15
root (hd1,5)
chainloader +1

title KateOS Lilo, tries to boot Vine on (hd2,6) but gets error 15
root (hd1,6)
chainloader +1

title Scientific Linux GRUB, boots Zenwalk on (hd2,7) successfully ?!?!?!?
root (hd1,7)
chainloader +1

title Sabayon GRUB, error 22
root (hd1,10)
chainloader +1

title SAM cl GRUB, (I think) tries to boot Kororaa on (hd2,9)
root (hd1,9)
chainloader +1

title CentOS GRUB prompt
root (hd1,8)
chainloader +1

title Mandriva GRUB, error 15. Listed as ext2fs and I installed as ReiserFS
root (hd2,4)
chainloader +1

title VLOS GRUB, error 15
root (hd2,5)
chainloader +1

title Vine GRUB, error 15
root (hd2,6)
chainloader +1

title Zen lilo (I think), error 13
root (hd2,7)
chainloader +1

title Fox GRUB, error 13
root (hd2,8)
chainloader +1

title Kororaa GRUB, error 13
root (hd2,9)
chainloader +1

Not to be cynical... but how many distros do you really need?

I don't think that they will boot with only the 'chainloader +1'. I would try to boot every distro with their own kernel and initrd, like

title {title}
root (hdx,y)
kernel /{kernel} root=/dev/hdx ro
initrd /{image}
quiet
savedefault
boot

Good luck!

Thanks

1. I have so many more for fun than a necessity.

2. As I said, "...have quit booting from GRUB" - they all worked. That is called chainloading and it is the easiest way to multiboot in my opinion.

It depends on your setup. If you put a bootloader on each root partition during install (except one that is in the MBR) this method works great. No fooling with unknown parameters.

brjoon1021, did you delete or add any partitions?

No I did not delete any partitions or add any but I did format some existing partitions. One may have changed form ext2 or ext3 to Reiser or vice versa.

The last things I did were: installed Vine Linux. It booted from GRUB. I installed aLinux on hdi or hd3 (which is empty now, I reformatted those partitions after this screw up as a first step in trying to fix things) and I also installed MyahOS on hdi or hd3. It was after these three installations and the installation of a second PCLinuxOS kernel (the i686 one) that something went wrong. I tried to undue the last things done by reformattin all of the partitions on hdi (hd3) to get rid of aLinux and VLOS. This did not help. I recalled that Linspire did not play nicely in a multiboot scenario so I reinstalled VLOS over it. This did not help. The only thing that I have not undone is remove the PCLinuxOS kernel, but I can't imagine how that could help. It appears that either Vine or more Likely alinux or MyahOS screwed something up.

Check the device.map you (last) used to install grub - presumably PCLinuxOS.

I would suggest checking the output of your favorite fdisk type tool against your grub menu to start with. The fact that GRUB is trying to boot something other than what is expected points to partition mismatches of some kind.

Also, please output of fdisk -l.

Are these drives all on cable select?

I take it you have a grub in mbr of hda, from which you chainload a grub in each linux partition?

I would have expected more information from the errors you have supplied...

ie. for grub error 15:
This error can occur in two different stages of the GRUB configuration, either during the initial configuration (installing GRUB in the master boot record) or after booting the system and attempting to launch Linux (or any other entry).

Grub Output - Initial ConfigurationGrub Output - Booting an Entry(from the gentoo linux site).

You can see how the context of the error is quite important.

Anyway: http://www.uruk.org/orig-grub/errors.html lists your errors as follows:
Perhaps you should peruse the grub.conf for each distribution (chainloading is great when everything works - when it dosn't, then you have N+1 config files to peruse instead of just one - where N is the number of chainloaded distros.)

Thanks guys.

1. I don't know how to do or what "fdisk -l" is. I tried to run that as root in a console from PCLinuxOS and got an error, "command not found"

I am not sure how to find the problem by, "I would suggest checking the output of your favorite fdisk type tool against your grub menu to start with. The fact that GRUB is trying to boot something other than what is expected points to partition mismatches of some kind." either.

2. Yes, I install GRUB hopefully or Lilo if it is the only option in the root of the partition and chainload to it.

3. I want to point out that the three distros that try to boot another distro (another partition) ALL try to boot a partition one disk over... take the Frugalware entry, it is on (hd1,5) but it tries to boot (hd2,5). The other two do the same thing. Does this point to a likely specific issue?

4. I have a mix of Maxtor and WD disks. I recall vaguely that one of those brands either should or should not be used as cable select but should be setup as Master or Slave as appropriate. Could this whole thing be over that? I may need to go over the disks one by one and make sure that they are set up right with the jumpers

I understood that all the GRUB entries worked previously and now they do not. Is that correct?

Run it from Ubuntu or SUSE. <mutters> And never mind how you find the problem this way - something weird has happened to your disk sequencing, looking at the output of fdisk -l will provide us a clue or three.

Good - this means I am understanding you this far. Have you checked the grub.conf and lilo.conf files for each of these? (The error messages will likely be coming from these and not the grub you've given us the conf file for.)

Yes, I've noticed that and it is suggestive. However, I still need the other information to be sure of what I think.

Absolutely - make sure they are all jumpered.

This was my understanding also - so far it looks like something has juggled the drive orders...

At the mo, I'm guessing:
hda = primary master = hard drive,
hdb = primary slave = empty
hdc = secondary master = media drive (CD?)
hdd = secondary slave = empty
hde = tertary master = hard drive,
hdf = tertary slave = empty
hdg = quarternary master = hard drive,

Now I always thought these would be hd0-7, otherwise adding a drive in the primary slave slot would reorder all the numbers requiring an extencive rewrite of all the grub.conf files. But, then, I've never had more than three HDDs at once.

Now, it would appear that the drive thought to be hdg is responding to grub-designation hd1 ... this would suggest that the drive thought to be hde would respond to grub hd2, but this dosn't seem to be the case. But, maybe it will respond to grub hd3... in this case, it would look like we have the errant drives on the first two ide controllers in the slave positions? But how can this be? After all, the grub.conf we see previously worked, and we are assured that no fiddling with cables has occured. We'll see...

Thanks. I had to go to bed. I will continue working on this tonight. Please check back if you can. I will only stop posting if I have fixed it and told you guys so or if I have to be interrupted by nasty things like work.

I am pretty new to Linux despite the fact that I chose to learn and increase my intrest in linux by multibooting. To be honest, I don't know how to check the lilo.conf and GRUB files for the messed up distros because I can't boot into them. Is this where I have to chroot with a liveCD? I have lots of liveCDs and all of the Recovery ones like R.I.P. , sytem rescue CD,. ultimate boot CD, Gparted, PCLInuxOS, Mepis....


All of the disks are jumpered but it could be the case that the picky disk(s) whether that is Maxtor or WD is CS or M/S where it likes to be the other way around. I will fix them.

Thanks again and I am not abandoning the quest I just have to go to work...

B.

I have not reviewed others' suggestion but my gut feeling of the problem is any deletion of a logical partition in the middle of a chain will cause the rest of the chain shifted up by one partition. Thus even the disk order has not been changed the partition numbers may be automatically changed without a user's intervention.

Logical partitions work like a chains with each link carrying the hard disk address for the next link down the line. It is not possible to interrupt a continuous chain. A logical partition deleted in the middle will have its space "dead" and cannot be used. The only way to use it is to recreate a new logical partition in the same space. The LInux kernel will automatically adjust the logical partition numbers if any one of them is deleted to maintain the addressability of the system. It is just the PC standard so watch out.

Don't take my word for it. Go to the terminal mode and call up cfdisk program. It will display this phenomenon right in front of your eye!

Another possible culprit is the hardware change in the form of electrical connection. hda, hdb, hdc and hdd are actually the electrical connection points of the two IDE cables. The primary Master disk is hda and its slave is hdb. The secondary Master is hdc and its slave hdd. Thus doing nothing to the Bios but altering any of the connections can cause LInux to pick up the wrong disk. On top of this the hda to hdd are called differently in Grub as it get the disk order as handed down from the Bios.

Now the cure

Obvious the sensible way to tackle this confusion is to make Grub to work a little bit harder and the best way is use the Grub prompt more by booting the unbootable Linux manually.

These 3 Grub commands instruct Grub to display all the partition in each of hd0, hd1 and hd2
Check the partitions and disk sizez to see if the 3 disks are in the order you expect.

Now select failed the partition you want to fire up. I pick Vlos randomly as an example. Your Grub statements are
You first declare in a Grub prompt (which you can get in most Grub menu, except a few odd ones that use gfxmenu like Suse) by pressing the "c" key
I bet you haven't got Vlos in it so you might as well boot up whatever inside manually by have a look at its menu.lst. This can be done by Grub prompt command
Grub will display the specified file from the declared root or partition.

If you Linux does not boot it is most likely the partition recorded in the menu.lst differs from the declared root. You can then manually type in the statement of the menu.lst line by line but omitting the title statement and finish by adding a boot starement like The Linux will boot if partition reference is correct in the "root" statement as well as the kernel statement on the "root=" parameter.


If you still have a problem then amend the /etc/fstab to reflect the new partition reference. For how to break into an unbootable Linux please consult the steps I documented in Task D2 of the last link in my signature.

Once the LInux boots with the amendments you can edit the menu.lst to let it boot automatically (i.e. not manually). THis is the direct method which involved the use of the kernel statement/

Alternative you can do what you have done to boot everything indirectly by making it chainlaodable by the bash command
Grub will place itself at the beginning of 6th partition of your 3rd disk and will answer the chainloader +1 command call. The Linux inside in this case may not be Vlos though.


Take a look at the Task G to boot up a Linux manually.

The simplest cure is of course to re-create the deleted logical partitions. Even the partitions aren't used the kernel will shift back to the original order automatically.

Grub doesn't alter anything in the Linux. It is always the user doing something to upset the disk or partition order without knowing it.

As long as the Linux in each partition is not overwritten it will be bootable again if you know the correct partition reference, amend its /boot/grub/menu.lst and /etc/fstab.

I have shifted 50 to 60 partitions at a time when moving the Linux to a new PC and rearrange the partition sizes to suit my taste. They all became unbootable at first but a little bit of work will fire up everyone eventually.

Good luck.

--------------

Apology

I was replying too fast and missed out your 2nd & 3rd disks are called hde and hdg. That tell me you probaly have two Sata. The hde and hdg are named in some Linux in place of sda and sdb. hde and hdg can also be connection-dependent. This is to say if you reverse the connections at the motherboard level the disk order can also reverse too. There could be confusion if you pull out one Sata and force the other one to be recognised as the first Sata and inherit the hde status. I could not tell the rules as they may not have been standardised. This is the price one has to pay in exploring a wide range of distros.

------------
Experiment

I just tried out the recognition procedure of my hde and hdg as follow

I run 4 disks, hda, hdc, sda & sdb (the last two are called hde and hdg by some Linux). I shall call the 4 disks as No. 1, 2, 3 & 4.

When I pulled out sda from the PC ( all my disks are on mobile racks) Grub reported 3 disks of (hd0), (hd1 and (hd2). The original sdb (No. 4) is reported as sda in Linux. The original sda (No. 3) position is vacant.

I then reinstated the Sata disk but put sda and adb in reverse position. This is to say I put No. 3 in the previously No. 4 position and the original No. 4 disk went to No. 3 position. Linux assigned sda to the 3rd position and the sdb to the 4th position, same as where I started but the disks have been reversed.

The above proves the sda and sdb are connection-dependent. If only one is used it is always sda. I did not boot any of the distros in sda and sdb in the above experiement as I did not expect them would boot. The Linux I run was in hda.

Guys, thanks for all of your good advice. I now have a system that boots all of the distros again and I don't know why. I did only one thing. Period. In other words, I have not even had time to try any of your good advice. Some of it required me to do some reading before I coud carry it out. In the meantime, I dowloaded, burned and installed the recently released SUSE 10.2 over top of the SUSE 10.1 where it resides in /dev/hda5. Now everything boots again?!?!?

Can you help me figure out how this was a fix.

1. Is it likely that SUSE and its bootloader was the problem? I now recall that I had booted into SUSE 10.1 not long before (maybe even just before) I had the enormous problem that just fixed itself.

2. Could it be that I DID and possibly DO have a disk order switching issue that responds to the last disk that has an OS installed on it? For example, I wonder if everything is going to go all to hell again if I install a distro on /dev/hdi again. I kind of doubt this as a scenario because hda was never part of the problem, it booted all of its distros. It was hde, hdg and the couple of distros on hdi that all quit booting at once.

If you would, please take a look at my GRUB menu.lst in my original post, note what I was saying about the distros on hd1 trying to boot distros on the same numbered partition (but on hd2) and think if you can imagine a scenario where installing SUSE on hda5 over an older SUSE could possibly have fixed all of this... I did just notice that the SUSE bootloader is kind of weird. You have to check two boxes to get GRUB to install in the root of the partition that SUSE is installed on - the way I chainload.

Thanks,

B.