Multi-boot with grub and grub2 and chainloading

[saikee]

I think you should have one more try with booting Grub2 by Grub1.

You way you described makes me think that you have not have seen or understood the edited section of my Grub2 thread I wrote after responding to this thread. I put the information in a separate thread because it has been partly shown here and also the information is useful to others. I have a habit in answering questions I tend to refer the posters to my threads.

In a nutshell for another Grub, say Grub1, to boot your Ubuntu 9.10 which has ext4 (which Grub1 cannot read) and Grub2 (which is incompatible with Grub1 and so the two cannot coexist) you must make Ubuntu 9.10 "chainloadable" by restoring/replicating Grub2 in its root partition. This can be in parallel to putting Grub2 in the MBR. You do so by the command

grub-install /dev/sda9

which I have showed at the end of the the above mentioned thread. Thereafter in your Grub1 menu of Mepis the Ubuntu 9.10 should be bootable by Grub1 commands

title Ubuntu 9.10
set root=(hd0,8)
chainloader +1

asuming your Ubuntu has not changed position and still in sda9 in Linux convention and (hd0,8) in Grub convention.

I am confident Grub1 can boot Grub2 by chainloading because I have tries it with several versions of Grub1 even with the oldest Grub 0.91 in my collection.

Would you report the result of such an attempt?

[panther3e]

I have tried your suggestion to boot grub2 from grub. I installed grub2 to the root partition with the command you supplied.

grub-install /dev/sda9

Then installed grub back to mbr from mepis.

I added ubuntu partition to menu.lst.

title Ubuntu 9.10
set root=(hd0,8)
chainloader +1

Rebooted, selected ubuntu, and then I was greeted with the lines:

chainloader +1

grub

I could not ctrl-alt-del, start editor, or enter commands.

I am able to boot slackware and windows..

I will hold off for now to reinstall grub2 back to the mbr. I would like to work to resolve this issue.

Any ideas saikee? Let me know if you would like to keep trying. If you do let me know if you need any additional information.

Thanks Kevin.

[saikee]

panther3e,

If you put Mepis Grub1 into the MBR boot it with Grub2 commands of

title Ubuntu 9.10
set root=(hd0,8)
chainloader +1

It has to failed as you described. However if you put Grub1 compatible commands like this

title Ubuntu 9.10
root (hd0,8)
chainloader +1

Then it will work. Hope the above is obvious to you.

However the most important feature of both Grub1 and Grub2 is the ability to boot each system manually and this you must learn because it allows you to talk to Grub directly without going through me.

At a text Grub menu, for both Grub1 and Grub2, pressing the "c" key will get you a Grub prompt right? In a Grub prompt you instruct Grub by commands line by line. The commands you use are exactly those in the menu.lst or grub.cfg with the following exceptions

(1) No need to use the "title" statement
(2) Add "boot" at last as the green light for Grub1 (or Grub2) to fire up the operating system.

The deal here is if Grub doesn't like a line of command you type it will tell you immediately. You can then retype it repeatedly until Grub is happy with it. Remember you can use the "tab" key to get Grub to complete the rest of the line to reduce the amount of typing by you. Also the "upward" direction key can be used by you to recall previous Grub commands you have typed and accepted by Grub

Therefore if you have a Grub1 in the MBR you can manually fire up Ubuntu manually by typing at a Grub prompt

root (hd0,8)
chainloader +1 
boot

When you have Ubuntu Grub2 menu up you can press C to get another Grub prompt. You can hop from Grub to Grub, therefore from distro to disto this way without booting a system. Naturally in a Grub prompt you can go back to the MBR by these commands

root (hd0)
chainloader +1 
boot

in Grub1 or if you are in Grub2 you can use

set root=(hd0)
chainloader +1 
boot

The power of Grub is released only if you talk and instruct the bugger this way! Why let Grub drives you round the bend when you can make it your slave?

[panther3e]

I changed menu.lst back to the way you stated.

title Ubuntu 9.10
root (hd0,8)
chainloader +1

Then I get my original errors

File system type is ext2fs type 0x83
error 13 invalid or unsupported executable format

I also tried to edit from the drub command and added the boot to the last line and got the same errors.

Here is me menu.lst file:

timeout 10
color cyan/blue white/blue
foreground ffffff
background 0639a1

gfxmenu /boot/grub/message

title MEPIS at sda5, newest kernel
root (hd0,4)
kernel /boot/vmlinuz root=/dev/sda5 nomce quiet splash vga=normal
initrd /boot/initrd.img
boot

title MEPIS at sda5, kernel 2.6.27-1-mepis-smp
root (hd0,4)
kernel /boot/vmlinuz-2.6.27-1-mepis-smp root=/dev/sda5 nomce quiet splash vga=normal
initrd /boot/initrd.img-2.6.27-1-mepis-smp
boot

title Microsoft Windows XP Professional at sda1
rootnoverify (hd0,0)
chainloader +1

title Slackware
root (hd0,6)
chainloader +1

title Ubuntu 9.10
root (hd0,8)
chainloader +1

title MEMTEST
kernel /boot/memtest86+.bin

I am really stumped. It looks like my only option that worked is to reinstall karmic and put the bootloader in the mbr.

[saikee]

Thr error 13 is associated with no boot loader found at the boot sector of the partition specified in the "root" statement. This suggested that your installation of Grub2 in the /dev/sda9 unsuccessful and you should have receive an error message to that effect.

The "grub-install /sda9" is a bash command to be issued at a root terminal inside Ubuntu 9.10 like this

sudo su
grub-install /dev/sda9

The "sudo su" command requires no root password if you are using a Live CD but a root password would be demanded in an installed Ubuntu.

If you issue the grub-install command as a normal user it may not be acted upon by Ubuntu and you will not be told. Just one of the bad points of the Ubuntu distro.

You don't have to reinstall Ubuntu 9.10 Alpha 5 again. You can boot it manually using Grub1. The Task G1 in the last link of my signature has the steps. You will need to modify it for Grub1 because you will "cat" /boot/grub/grub.cfg and not /boot/grub/menu.lst

Edited addition

The proof of the pudding is in the eating so I fire up my own Grub1 menu, press C to get a Grub prompt and booedt up Ubuntu 9,10 Alpha5 using these commands (my Ubuntu 9.10 is in the sda15) so adjust the partition reference to suit your case. The red bits are obtainable by typing the blue bits first and then press the "tab" key for Grub to complete them.

root (hd0,14)
kernel /boot/vmlinuz-2.6.31-9-generic ro root=/dev/sda15
initrd /boot/initrd.img-2.6.31-9-generic
boot

The green bits are Grub commands. If I list the content of /boot by command "ls" it shows the following

saikee@saikee-desktop:~$ ls /boot
abi-2.6.31-9-generic         memtest86+.bin
config-2.6.31-9-generic      System.map-2.6.31-9-generic
grub                         vmcoreinfo-2.6.31-9-generic
initrd.img-2.6.31-9-generic  vmlinuz-2.6.31-9-generic

I have now added the above as Task K5 in my "Just booting tips."

LInux kernels always start with vmlinuz and the initrd file with initrd so I use Grub to fill in the bit I do not know.

[panther3e]

When I installed grub to my /dev/hda9 partition I used the sudo install-grub /dev/hda9 command. When it was done I received conformation that grub was installed successfully. There was a warning to the effect that not installing to the mbr was a waste of time. Not an exact quote.

I will try what you suggest and post my results.

Thanks Kevin.

[saikee]

Your description of Grub2 response was also the one I received so your Grub2 should have been successfully installed.

The method I described in Post #20 does require a Grub1 to have been modified to read Ext4 filing system if your Ubuntu 9.10 Alpha5 uses that filing system. If your Grub1 has been sourced from a recent distro then it would have been modified to cope with the Ext4.

My Grub1 in the hard disk MBR boots it and another Grub1- 0.97 floppy also manages it but the oldest Grub1 0.91 and one from Open Solaris (off CD) Grub1 0.97 failed.

The default filing system used by Ubuntu 9.10 Alpha5 is Ext4 which became part of the kernel starting from 2.6.28 onward. Since your Grub1 has beemn sourced from Mepis and its latest kernel version is 2.6.27 you might have a uphill struggle to get its Grub1 to read a Ext4 filing system which is what my Post #20 is all about. However many earlier kernel have been known to incorporate the Ext4 support well before it was formalised in 2.6.28 kernel. However there is always a possibility Grub1 may get forgotten in the process that will be a classic case of a bug.

[panther3e]

My Mepis install is ext3. Ubuntu 9.10 in ext4.

I am still reading your #20 post then rereading it. I want to make sure I understand what have written. Not that its unclear. I am getting tired and it is not sinking in as of yet.

I will let you know what happens, Kevin.

[saikee]

I have added a few more bits to help you to understand the Post #20

The basic technique of booting any Linux manually are the following command

root (disk_No,partition_No)
kernel Kernal_filename ro root=Root_device_name
initrd Ram_disk_filename
boot

The first line is known to you. The 2nd and 3rd lines require the knowledge of the kernel and ramdisk filenames which are stored in /boot but not easy to obtain via a Grub prompt. Thus using the "cat" command listing its content on the screen is one way to see the two filenames.

The other alternative is to use the "tab" key which is a standard feature of Linux. We know the file is called vmlinuz-XXXXXXX and it is in /boot so typing

kernel /boot/vml

and then press the "tab" key will trigger Grub to find a file in /boot that matches the above and Grub will complete it to

kernel /boot/vmlinuz-2.6.31-9-generic

I then add "ro" to denote read only and "root=/dev/sda15" to denote the /boot is in sda15 and then press the return key. If Grub accepts it then there will be no error I can proceed to the next line of command.

Hope this is clearer.

PS In booting Grub actually passes the control to the kernel so it needs (hd0,14) to find it. Once the kernel is in control it no longer uses the Grub naming convention and so root=/dev/sda15 assist it to continue with the booting process. Both "ro" and "root=xxxx" are parameters used by the kernel. These two are the essential one that can fire up a Linux. Most Linux distros in a formal booting use more parameters than the above two bare minimum.

[panther3e]

Woohooo!!!! Success, finely after several attempts. I started up Slackware, looked at my /boot/grub/grub.cfg. Found the corect kernel and initrd lines. Went back to my mepis install menu.lst file and added them to it. Like how you had it. Saved it, rebooted, and what do you know it started.

I was more than surprised after so many tries did not work. Thank you for all your hard work saikee. I know it has not been easy but you did it.

A quick question though. I think the way I have it added to menu.lst I will have to change the entry when ever I update the kernel version?

I forgot the ro between the kernel name and root. Should I go and add it?

title Ubuntu 9.10
root (hd0,8)
kernel /boot/vmlinuz-2.6.31-10-generic root=/dev/sda9
initrd /boot/initrd.img-2.6.31-10-generic

Thank you very much saikee.

[saikee]

From my experience the "ro" is needed in most Linux. A few can do without it and sometime if it doesn't work I use "rw". I believe it is just the way the maintainers arranged it. Many Linux distros for safety reason boot up a system by mounting it read-only first. The system is re-mounted once for read-write if it proves safe to do so. That way changes are not made to unbootable systems.

I also notice in Grub2 this has been dropped. May be the newer kernel does it automatically. Therefore if it boots you can arrange it anyway you can.

When an kernel is updated the menu.lst or grub.cfg will be automatically added with the new entry and the existing one will be kept untouched. However the changes will only be done to the Linux's own booting commands and not for multi-booting other distros. Thus you save a lot of hassles if you chainload other systems.

My knowledge is really from comparing the hundred of distros menu.lst and lilo.conf. There is no hard and fast rules.

[panther3e]

Well, it seems that grub2 does not like playing second fiddle to grub. I had everything set to my liking. I did the updates for ubuntu. When it was almost done a popup apperead. There were several options. The one I chose was to keep the local grub. I thought this was the best choice and would keep things the way they were. I was wrong, after the suggested reboot. To my surprise I was presented with the grub2 menu.

Mepis, slackware, and win2k all start as they should and I will leave it as it is for now. It is working but I was surprised after the reboot.

Kevin.

[saikee]

I have been reading Grub2 information. Apparently the update does not keep the latest grub.cfg which is generated from /etc/grub.d. Thus one has to tweak the /etc/grub.d to make it permanent. Like I said earlier Grub2 is nowhere near ready but some users are pushing it hard.

[barjac]

Well, I have just installed Ubuntu 9.10 to sda14 with boot loader in sda14 and I cannot chainload into it from grub legacy (Mandriva)
Same error as panther3e
I am trying to help a user on the Mandriva forum and could not believe that a straight chainload would not work, so I tried it myself.
I am in Ubuntu now by using :-
title Ubuntu 9.10
kernel (hd0,14)/boot/vmlinuz-2.6.31-14-generic BOOT_IMAGE=linux root=UUID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ro splash vga=791 quiet splash
initrd (hd0,14)/boot/initrd.img-2.6.31-14-generic
I am beginning to hate grub2.
I wonder if anyone has any more thoughts on this problem?

[barjac]

Sorry I meant (hd0,13) I just quickly edited that from another post.