Ubuntu's Grub unfriendly to other Linux distros

Bug #47229 reported by towsonu2003
34
This bug affects 3 people
Affects Status Importance Assigned to Milestone
grub-installer (Ubuntu)
Invalid
Medium
Unassigned
ubiquity (Baltix)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: grub-installer

To replicate, do:
1. Install other Linux distro(s) (list I tried below) with boot loader on MBR
2. install Ubuntu, grub on MBR
3. Ubuntu's grub menu.lst won't have entries for other distro(s)

Distros I tried so far:
Slackware 10.2, Zenwalk 2.4, opensuse (latest stable), fedora core 5, frugalware, arch (failed installation)[*], ark (failed installation), openBSD (failed installation)

Setup was as follows:
/dev/hda1 - Windows (refer to bug #1 )
/dev/hda6 - ubuntu (no boot flag) -> recognized by opensuse and fedora...
/dev/hda9 - other distro (no boot flag)
/dev/hda10 - other distro (no boot flag)

Note: if you install ubuntu first and other distros last, grub-install won't see other distros but Windows only...

[*] Failed installation: distro's boot loader got installed but could not boot like others.

As a workaround for this bug, I use the following menu.lst and install distro bootloaders to their /boot folder.

Workaround menu.lst:
-------------------------cut here---------------------------
# menu.lst - See: grub(8), info grub, update-grub(8)
# grub-install(8), grub-floppy(8),
# grub-md5-crypt, /usr/share/doc/grub
# and /usr/share/doc/grub-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not change this entry to 'saved' or your
# array will desync and will not let you boot your system.
default 0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout 10

## hiddenmenu
# Hides the menu by default (press ESC to see the menu)
#hiddenmenu

# Pretty colours
#color cyan/blue white/blue

## password ['--md5'] passwd
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line) and entries protected by the
# command 'lock'
# e.g. password topsecret
# password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret

#
# examples
#
# title Windows 95/98/NT/2000
# root (hd0,0)
# makeactive
# chainloader +1
#
# title Linux
# root (hd0,1)
# kernel /vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=/dev/hda6 ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,5)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
## alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
## lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=quiet splash

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
## altoptions=(recovery mode) single
# altoptions=(recovery mode) single

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
## howmany=7
# howmany=all

## should update-grub create memtest86 boot option
## e.g. memtest86=true
## memtest86=false
# memtest86=true

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=false

## ## End Default Options ##

title Ubuntu, kernel 2.6.15-23-386
root (hd0,5)
kernel /boot/vmlinuz-2.6.15-23-386 root=/dev/hda6 ro quiet splash
initrd /boot/initrd.img-2.6.15-23-386
savedefault
boot

title Ubuntu, kernel 2.6.15-23-386 (recovery mode)
root (hd0,5)
kernel /boot/vmlinuz-2.6.15-23-386 root=/dev/hda6 ro single
initrd /boot/initrd.img-2.6.15-23-386
boot

title Ubuntu, memtest86+
root (hd0,5)
kernel /boot/memtest86+.bin
boot

### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate the menu items below from the Debian
# ones.
title Other operating systems:
root

# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/hda1
title Microsoft Windows XP Home Edition
root (hd0,0)
savedefault
makeactive
chainloader +1

title Other Distro
root (hd0,8)
savedefault
chainloader +1

title Other Distro 2
root (hd0,9)
savedefault
chainloader +1
-------------------------cut here--------------------------

Revision history for this message
towsonu2003 (towsonu2003) wrote :

Bumping up severity bc it screws up boot-ability of other installed distros.

Revision history for this message
Colin Watson (cjwatson) wrote :

Please attach /var/log/installer/syslog to this bug.

Changed in grub-installer:
status: Unconfirmed → Needs Info
Revision history for this message
towsonu2003 (towsonu2003) wrote : /var/log/installer/syslog as requested

attached /var/log/installer/syslog as requested. anything else?
thanks for the fast reply.

Revision history for this message
Michael Helmling (supermihi) wrote :

Another problem, connected to this one, appears if you choose the same boot-Partition for ubuntu as for another distro (like I do because of LVM root-partitions): All the kernels from the other distro appear as Ubuntu-Kernels, and my original grub-settings are gone.

Revision history for this message
towsonu2003 (towsonu2003) wrote :

can we change the status from "needs info" to something else? I provided the info requested ;)

Changed in grub-installer:
status: Needs Info → Unconfirmed
Revision history for this message
towsonu2003 (towsonu2003) wrote :

changing to ubiquity as per duplicate's comment -can someone confirm this one? it's my own bug report, so I can't... thanks :)

Revision history for this message
Cameron Braid (cameron-braid) wrote :

I am running feisty with LVM and just installed gusty-tribe-1 using the alternate cd.

I installed the root partition into a new LVM logical partition, and chose to use the same boot partition that I use for feisty.

This (https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/47229/comments/4) also happened to me.

My menu.lst was recreated using all kernels (even the feisty ones) that exist on my boot partition, using the gusty device as the root partition.

Changed in ubiquity:
status: New → Invalid
Revision history for this message
James Bellinger (bellinger-6) wrote :

Funny, I had this work somewhat backwards. I installed Kubuntu after Ubuntu and when Ubuntu tried to upgrade, well, Kubuntu had already overwritten the boot sector so the upgrade wasn't able to boot with the new kernel. Instead it kept getting whatever Kubuntu had put in at the time I installed it. :)

Revision history for this message
Tormod Volden (tormodvolden) wrote :

If you have several distros/operating systems installed, I know of only one sane way of doing it: Let _one_ of them install to MBR, let the other install grub/etc to their respective partitions. Then in the "master" distro's menu.lst, add entries for chainloading the others:

title Chain to Gutsy
root (hd0,6)
chainloader +1

title Mickey Mouse Linux
root (hd0,2)
chainloader +1

title Microsoft Windows
root (hd0,1)
makeactive
chainloader +1

The +1 means the first block of the partition (= boot sector). You can also chainload to a file instead (having copied a boot sector to that file), this can be a solution if you have to share one /boot partition between many OSes, although that case probably needs quite some configuration.

Revision history for this message
Cameron Braid (cameron-braid) wrote :

@Tomodo unfortunately this doesn't seem to work when the root partition (containing the /boot folder) is on LVM

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Cameron, AFAIK having the /boot directory or partition on LVM can not work in any case, since the BIOS needs to access the grub files. That's the reason people use a separate /boot partition. If you try to share one /boot partition between many OSes, you could theoretically make subdirectories there for each one, and copy in the distro's original /boot stuff and change paths accordingly in the menu.lst files. But this will soon become so messy that it will be easier to maintain one big menu.lst by hand, and update it every time one of the distros is reconfigured. This special case is just too difficult to handle in an automated way. WRT to comment 4, do the other distributions handle this better?

Revision history for this message
Cameron Braid (cameron-braid) wrote :

Tomod,

I don't know other distros handle this - I tend to only use ubuntu on my desktop these days, usually using a few different versions at the same time - to try out the dev version, betas etc..

I have a separate /boot partition which is not on LVM.

I have gone through the process of managing separate folders for each linux installation, all in separate subfolders of my boot partition - keeping their menu.lst file in their own folder (/boot/gutsy/grub/menu.lst), and mounting the applicable boot partition subfolder (/boot/gutsy) as /boot. Then I would have a /boot/grub/menu.lst file that uses configfile directive to open the menu.lst from the relevant subfolder. (/boot/gutsy-boot/grub/menu.lst)

This works, but is a pain since every time an OS updates grub, you have to manually fix the generated menu.lst file.

I am of the opinion that grub should fix the need to do this. Grub is only needed because people want to install multiple operating systems on a single pc.. so, why then can't it just work ! I realise that grub2 is in the works, and should support boot on lvm, and other such features, so I hope it will also provide a means for linux install to work well with others.

Changed in grub-installer:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.