I also have not seen in grub before the "BOOT_IMAGE=linux". I dont see the point of this. I have not come across this in grub before and I was wondering if this is stopping the booting of other os's as its not correctly written - either by me or pclinuxos. Could this be explained.
It is a kernel parameter and is commonly used in
Fedora and
Mandriva boot stanzas.
I am not convinced that grub-2 is the problem - yes grub2 is used by these other os's - as all other os's are pcked up by the grub2 in these other os's. Even pclinuxos is picked up. Still kernel panic is the result. 
GRUB2
is the problem. It is a rewrite of GRUB legacy (version 0.97), which was supposedly done to enable booting of UEFI disks. In doing so, the GNU artistes created an over-complicated bootloader that doesn't always do what it's intended to do. When a new OS is added to the GRUB2 (version 1.99) setup, a special routine is run. In TheOtherOS, that routine is kept in the file /etc/grub.d/30_os-prober. When the os-prober runs, it is not smart enough to determine whether the OS to be added to the GRUB2 menu already has a bootloader of its own, and whether or not that bootloader may be legacy GRUB. Instead, the os-prober routine simply tries to boot the added OS directly, using GRUB2 boot parameters. When you added PCLinuxOS to the GRUB2 setup of TheOtherOS, you got a menu that looks like this:
(click on any thumbnail to see a full sized version)

You ended up with a section in the /boot/grub/grub.cfg file that looks like this:
### BEGIN /etc/grub.d/30_os-prober ###
menuentry "linux (on /dev/sda3)" --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root 06a09f8e-ec6f-449d-b0d6-33e1e116dcab
linux /boot/vmlinuz BOOT_IMAGE=linux root=UUID=06a09f8e-ec6f-449d-b0d6-33e1e116dcab quiet vmalloc=256M acpi=on resume=UUID=150f890d-e3e7-46b9-8d44-431f1572b007 splash=silent vga=788
initrd (hd0,2)/boot/initrd.img
}
menuentry "linux-nonfb (on /dev/sda3)" --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root 06a09f8e-ec6f-449d-b0d6-33e1e116dcab
linux /boot/vmlinuz BOOT_IMAGE=linux-nonfb root=UUID=06a09f8e-ec6f-449d-b0d6-33e1e116dcab quiet vmalloc=256M acpi=on resume=UUID=150f890d-e3e7-46b9-8d44-431f1572b007
initrd (hd0,2)/boot/initrd.img
}
menuentry "failsafe (on /dev/sda3)" --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
search --no-floppy --fs-uuid --set=root 06a09f8e-ec6f-449d-b0d6-33e1e116dcab
linux /boot/vmlinuz BOOT_IMAGE=failsafe root=UUID=06a09f8e-ec6f-449d-b0d6-33e1e116dcab quiet failsafe vmalloc=256M acpi=on
initrd (hd0,2)/boot/initrd.img
}
### END /etc/grub.d/30_os-prober ###That is completely wrong. You cannot correctly boot an OS using GRUB2 if the bootloader and configuration files for that OS are using GRUB legacy. It will not work, period. You already discovered this from trying to boot PCLinuxOS from the entries the GRUB2 bootloader created.
GRUB legacy has a tried and true method for passing control from the GRUB1 bootloader to a second bootloader. It is a simple one-line boot stanza:
chainloader +1GRUB2 has exactly the same capability, but I've yet to see it used by the GRUB2 utilities. You must manually edit the /boot/grub/grub.cfg as superuser to get the functionality you need. This is something the GRUB2 configuration utilities should already do, but don't. At the very top of the file is this section:
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#What a crock. To boot PCLinuxOS correctly from TheOtherOS, delete the entire /etc/grub.d/30_os-prober section shown in red above, and replace it with this much simpler section, shown below in green.
### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Chainload PCLinuxOS on /dev/sda3" {
set root='(hd0,3)'
chainloader +1
}
### END /etc/grub.d/30_os-prober ###You will then see a GRUB2 boot menu that looks similar to this:

If you select "Chainload PCLinuxOS on /dev/sda3" from the GRUB2 menu, you will then see this:
Exactly what you should see in the first place if GRUB2 did its job correctly. In the examples shown here, TheOtherOS was installed first. The GRUB2 boot record was written to the MBR of device sda and the configuration files are in partition sda2. PCLinuxOS was installed last. The GRUB1 boot record was installed to sda3 and the config files are in sda3. TheOtherOS's root partition is sda2, PCLinuxOS's root partition is sda3, and both share the swap partition on sda1. The original /boot/grub/menu.lst generated by the PCLinuxOS setup and stored in the /dev/sda3 partition
is still untouched. Not one single change has been made to it.
There is another GRUB2 configuration file at /etc/grub.d/40_custom. You will see the corresponding section in grub.cfg immediately following the section explained above. It is designed to be an "easy" way to
(manually) add GRUB2 boot entries when GRUB2 is re-generated. You would, as superuser, simply add the menu entry shown in green in the grub.cfg example above to the end portion of /etc/grub.d/40_custom. However, the os-prober will still run when GRUB2 is re-generated, and you would end up with the following:
"linux (on /dev/sda3)"
"linux-nonfb (on /dev/sda3)"
"failsafe (on /dev/sda3)"
"Chainload PCLinuxOS on /dev/sda3"Three wrong entries and one correct one, all pointing to the same partition. Now you tell me.
Which bootloader has the real problem? GRUB1 or GRUB2?
I think I have solved this by not using the grub that ships with pclinuxos. I installed grub1 to slackware and here I am writing this from pclinuxos.
But this is not a fix for the grub that ships with pclinuxos - thats still broken/faulty.
I have to disagree. Completely. No matter where you got the copy of GRUB1 from, if it is a working copy of GRUB version 0.97, I guarantee that it is a byte for byte exact copy of the GRUB1 used by PCLinuxOS. The question is, where did that copy of GRUB1 come from? It did not come from Slackware. They still use LILO as the bootloader.
