Multiple Linux Distributions

[bennachie]

I should first say that I am impressed by the latest Beta of Mageia. I've only tested the Gnome version so far, but it seems solid and likeable. The only real problem I have experienced to date is one inherited from Mandriva; an apparent inability to launch Mageia when it is one out of the four or five Linux distributions installed on my desktop testing workhorse at any given time.

I normally use Ubuntu or Mint to manage the boot selection process, since they use Grub2 and Grub1-based distributions can't readily identify and launch Grub2-based distributions. When using Ubuntu or Mint in this way, I have no problem in launching openSUSE or Fedora which of course, like Mageia, still use Grub1. I do get a bit of extra verbosity at boot time with these, but everything otherwise proceeds normally. When I try to launch Mageia in the same way, however, the exercise terminates with a kernel panic, suggesting that there is something non-standard about the way that Mageia locates or identifies its kernel. I experienced exactly the same difficulty with Mandriva, so this outcome is not surprising, but it would be nice if the Mageia developers could borrow the necessary code from openSUSE or Fedora, and avoid the problem.

There may, of course, be an easy workaround, and I would certainly welcome guidance from a more experienced Mageia user.

[barjac]

The simplest way to launch Mageia from grub2 is using a label (mageia_root in this case) for your Mageia root partition with this menuentry in your grub.cfg :-

Code: Select all

menuentry 'Mageia' {
search --no-floppy --label --set=root mageia_root
linux /boot/vmlinuz
initrd /boot/initrd.img
}

However the above will bypass any special kernel options set up by Mageia in menu.lst, so...
A safer way is to chainload into your legacy grub in the Mageia partition, but you must have installed the bootloader to the boot sector of the root partition for this to work. You can do this from within Magiea (or by chroot into mageia root) using :-

Code: Select all

su
grub
grub> root (hdx,y)
grub> setup (hdx,y)
grub> quit

Where x is the Mageia drive counting from zero and y is the partition, again counting from zero
Then use :-

Code: Select all

menuentry 'Mageia' {
search --no-floppy --label --set=root mageia_root
chainloader +1
}

I hope that helps.

EDIT I forgot to mention that rather than editing your grub.cfg directly, you can add the entries in /etc/grub.d/40_custom then do a grub-update [edit -or is it update-grub - I don't use Ubuntu]. This way they are not lost when your "main" grub2 system is updated (kernel updates etc.)

[bennachie]

@barjac

Thanks, that is very helpful. I was aware that the situation could be redressed using the chainloader mechanism, but I still don't understand why a new distribution like Mageia can't be set up to just work "out of the box" in a mixed environment, as is the case with openSUSE and Fedora. I guess that the problem will disappear when everyone finally moves to Grub2, but that step looks like being quite some time away.

[barjac]

@barjac

Thanks, that is very helpful. I was aware that the situation could be redressed using the chainloader mechanism, but I still don't understand why a new distribution like Mageia can't be set up to just work "out of the box" in a mixed environment, as is the case with openSUSE and Fedora. I guess that the problem will disappear when everyone finally moves to Grub2, but that step looks like being quite some time away.

This looks to be more likely an issue with Ubuntu/grub2/os-prober and it's generation of grub.cfg than with Mandriva and Mageia.
I have no issues booting Mandriva and Mageia from a hand made grub.cfg - I use a grub2 bootloader all the time, although it is a very recent development version.

What happens when you boot using the first entry that I suggested?

Also could you pastebin a default Ubuntu grub.cfg made by running

Code: Select all

sudo grub-mkconfig -o /home/$USER/grub.cfg

That will make a grub.cfg in your home folder and should not affect your system.
In the meantime I will try to duplicate the problem with an installation of Ubuntu that I have for testing.

[barjac]

OK I managed to reproduce this using Ubuntu 10.04.
The problem seems to be with OS-prober getting the partition completely wrong for the initrd.
See the entry below for Mageia in grub.cfg :-

Code: Select all

menuentry "Mageia testing (on /dev/sdb5)" {
   insmod ext2
   set root='(hd1,5)'
   search --no-floppy --fs-uuid --set 521927d2-e454-4135-b9c4-1d4827f4651f
   linux /boot/vmlinuz BOOT_IMAGE=linux root=UUID=521927d2-e454-4135-b9c4-1d4827f4651f nokmsboot resume=UUID=1097bb8c-3820-4b3a-b796-b417c9aa56d8 splash=silent vga=788
   initrd (hd1,4)/boot/initrd.img
}

The initrd line should have (hd1,5), but Ubuntu's os-prober has got it totally wrong. Looking at other Mandriva entries the errors are even worse.

The reason the Fedora works is that the initrd is specified using the filesystem. This is my entry for fc15beta:-

Code: Select all

menuentry "Fedora (2.6.38.2-9.fc15.x86_64) (on /dev/sdb3)" {
   insmod ext2
   set root='(hd1,3)'
   search --no-floppy --fs-uuid --set 90745ecd-7168-4728-823b-1ee56c6a1486
   linux /boot/vmlinuz-2.6.38.2-9.fc15.x86_64 ro root=UUID=90745ecd-7168-4728-823b-1ee56c6a1486 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us-acentos rhgb quiet
   initrd /boot/initramfs-2.6.38.2-9.fc15.x86_64.img
}

For now just manually edit grub.cfg to make the initrd line use the same (hdx,y) as the root and it will boot OK, but don't run update-grub.
I will try to catch the Ubuntu grub dev on IRC and see if this is a known issue.

[bennachie]

Many thanks for all your hard work on this issue - I've generated a temporary fix as you suggested, and all is well.

[barjac]

Many thanks for all your hard work on this issue - I've generated a temporary fix as you suggested, and all is well.

I caught the right person on IRC over breakfast. Here is the culprit :-
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606904
It's apparently fixed in grub2 versions after grub2/1.98+20100804-10, so if you can update your grub2 to a later version (maybe your distro has an "unstable" repo) then all should be well.

I didn't think it would be a Mageia / Mdv problem

[bennachie]

This is getting interesting. Ubuntu 11.04 (and its derivatives) use version 1.99~rc1-13ubuntu of Grub, and we know that the problem still exists. I'll enter this as an Ubuntu bug (which it clearly is) and report back here in due course. Incidentally, I'm very impressed with your quick and constructive response to my, admittedly somewhat out-of-the-ordinary, problem. If that's going to be a typical approach to dealing with issues arising while using Mageia, this could become one hell of a good distribution!

Don't tell me, it already is ...

[wobo]

... my, admittedly somewhat out-of-the-ordinary, problem.

This is not so extraordinary. We've been discussing such problems in the German Mandrivauser forum since Ubuntu started their "extraordinary" venture into grub2. And I'm sure these issues are discussed in other distribution's forums as well.

But I agree on the good quality of the help in this forum - I hope we can increase the number of willful helpers soon ....

[barjac]

There is another existing bug report here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566102 complete with a patch to fix it dated January 2010 !
May be worth adding to that bug report.

[bennachie]

Done. I settled for a very simple report, since the details of the problem are fully covered in the upstream bug reports:

https://bugs.launchpad.net/ubuntu/+bug/779213

Whether Ubuntu will be more interested in dealing with the bug than Debian has been remains to be seen, but the version of Grub2 they are using clearly already contains various tweaks to align it with their needs, and the Grub2 maintainers would probably pay more attention to a request from Ubuntu developers than to an individual bug report.

[barjac]

Looks good - it will be interesting to see what transpires.

Since you use several distros, have you considered using a dedicated grub2 partition. I find it excellent, as no distro depends on any other to boot. It also allows labels to be used throughout, avoiding any confusion with devices or uuids.
I have a small partition labelled "maingrub" at sda1. It has grub2 installed to it and has a hand made grub.cfg which I have pasted here for you to peruse. http://pastebin.com/f2Tjzac1
Note that since no distro has any reason to write to maingrub it does not need to be mounted by any distro and is as safe as can be from corruption.
Just food for thought

[bennachie]

Interesting thought, and thanks again for your help. I'll have a look at the "maingrub" partition option.

[wobo]

IMHO the best way to go about multiple (and changing) Linux installations is
- having a very small installation of a miniLinux with grub in the first partition (or first "Linux partition".
- the grub of this will be in the MBR
- each Linux installation will have its own bootloader in the root partition (setting the default time to 0 will save waiting time)
- all installations are then started by chainloader from the "master grub".

The benefits:
- it's easy to erase old and setup new installations, you only have to change the master grub when you add a new installation.
- when a Linux system updates the kernel it will change its own menue but not a main bootloader, with chainloader you don't have to worry about that.

[barjac]

IMHO the best way to go about multiple (and changing) Linux installations is
- having a very small installation of a miniLinux with grub in the first partition (or first "Linux partition".
- the grub of this will be in the MBR
- each Linux installation will have its own bootloader in the root partition (setting the default time to 0 will save waiting time)
- all installations are then started by chainloader from the "master grub".

The benefits:
- it's easy to erase old and setup new installations, you only have to change the master grub when you add a new installation.
- when a Linux system updates the kernel it will change its own menue but not a main bootloader, with chainloader you don't have to worry about that.

Exactly.

Rather than a mini linux installation, I keep a PCLOS remastered Live iso with all the tools that I need built in, in my maingrub partition and bootable from the menu. (I extended it to about 1GB to do that IIRC)
Same result except that with grub2 in the grub partition I can remove all (hdx,y), sdxy and uuid's from my main grub.cfg and do everything with labels, so partition juggling does not cause a nightmare.

[Rougil]

Hi,

It may be useful to launch an Ubuntu with Mageia/mandriva lagacy grub:

My menu.lst includes simply :


title Uba
root (hd0,8)
kernel /boot/grub/core.img
savedefault
boot


Because I tried Ubuntu on my last partition (sda9) at he end of the sata disk....
(for example eduroam is easier to set )

[barjac]

title Uba
root (hd0,8)
kernel /boot/grub/core.img
savedefault
boot

The last line "boot" is not required in menu.lst, it would only be needed if you were booting manually at a grub command line.

[wilcal]

One of the most useful pieces of hardware I have purchased is:

http://www.newegg.com/Product/Product.a ... 6817121172

Hard drives are very cheap so using the Kingwin Mobile rack
makes it very easy, safe and painless to go back and forth
between Linux, and even WinBlows, OS's.