cannot use separate /boot partition with grub 2?

[eljeffe]

While installing with a separate /boot partition I cannot get two distinct copies of ubu installed on one machine and be able to choose between them.

Each is installed on a different hard drive. x64 versions.

I've had this issue both ways:

Steps

install mythbuntu
install ubuntu

Result
Two entries in grub. Both cause ubuntu to boot

Steps

install ubuntu
install mythbuntu

Result
Two entries in grub. Both cause mythbuntu to boot

Grub 2 is so unfriendly for fixing these things. I don't know where to make changes. Ok, Grub 2 is very powerful, maybe it's the lagging documentation, or lack of tutorials that is the problem. But I don't know how to fix this. Do I start over without the /boot partition? Do I bail on ubu?

Thanks

[eljeffe]

I know there's not much technical info there. Not sure what would help figure this out.

the result of cat /boot/grub/grub.cfg is:


#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="0"
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}

function recordfail {
set recordfail=1
if [ -n ${have_grubenv} ]; then if [ -z ${boot_once} ]; then save_env recordfail; fi; fi
}
insmod ext2
set root='(hd0,8)'
search --no-floppy --fs-uuid --set 2f11e948-a795-4bcf-955b-cc334d060db7
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
insmod gfxterm
insmod vbe
if terminal_output gfxterm ; then true ; else
# For backward compatibility with versions of terminal.mod that don't
# understand terminal_output
terminal gfxterm
fi
fi
insmod ext2
set root='(hd0,7)'
search --no-floppy --fs-uuid --set da6a8fed-fed6-4a3e-b859-429f03f5d4c0
set locale_dir=($root)/grub/locale
set lang=en
insmod gettext
if [ ${recordfail} = 1 ]; then
set timeout=-1
else
set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Ubuntu, with Linux 2.6.32-24-generic' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd0,7)'
search --no-floppy --fs-uuid --set da6a8fed-fed6-4a3e-b859-429f03f5d4c0
linux /vmlinuz-2.6.32-24-generic root=UUID=2f11e948-a795-4bcf-955b-cc334d060db7 ro quiet splash
initrd /initrd.img-2.6.32-24-generic
}
menuentry 'Ubuntu, with Linux 2.6.32-24-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd0,7)'
search --no-floppy --fs-uuid --set da6a8fed-fed6-4a3e-b859-429f03f5d4c0
echo 'Loading Linux 2.6.32-24-generic ...'
linux /vmlinuz-2.6.32-24-generic root=UUID=2f11e948-a795-4bcf-955b-cc334d060db7 ro single
echo 'Loading initial ramdisk ...'
initrd /initrd.img-2.6.32-24-generic
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry "Memory test (memtest86+)" {
insmod ext2
set root='(hd0,7)'
search --no-floppy --fs-uuid --set da6a8fed-fed6-4a3e-b859-429f03f5d4c0
linux16 /memtest86+.bin
}
menuentry "Memory test (memtest86+, serial console 115200)" {
insmod ext2
set root='(hd0,7)'
search --no-floppy --fs-uuid --set da6a8fed-fed6-4a3e-b859-429f03f5d4c0
linux16 /memtest86+.bin console=ttyS0,115200n8
}
### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Microsoft Windows XP Home Edition (on /dev/sda1)" {
insmod ntfs
set root='(hd0,1)'
search --no-floppy --fs-uuid --set 5c787cb3787c8e10
drivemap -s (hd0) ${root}
chainloader +1
}
menuentry "Ubuntu, with Linux 2.6.32-24-generic (on /dev/sdb2)" {
insmod ext2
set root='(hd0,7)'
search --no-floppy --fs-uuid --set da6a8fed-fed6-4a3e-b859-429f03f5d4c0
linux /vmlinuz-2.6.32-24-generic root=UUID=2f11e948-a795-4bcf-955b-cc334d060db7 ro quiet splash
initrd /initrd.img-2.6.32-24-generic
}
menuentry "Ubuntu, with Linux 2.6.32-24-generic (recovery mode) (on /dev/sdb2)" {
insmod ext2
set root='(hd0,7)'
search --no-floppy --fs-uuid --set da6a8fed-fed6-4a3e-b859-429f03f5d4c0
linux /vmlinuz-2.6.32-24-generic root=UUID=2f11e948-a795-4bcf-955b-cc334d060db7 ro single
initrd /initrd.img-2.6.32-24-generic
}
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

please let me know what else needs investigating.

Thanks

[Blackbird_13]

I multi-boot with grub2. This is what I do with one hard disc.

Install my first Ubuntu OS without a separate boot partition (ie boot/grub is part of root partition), installing grub to mbr of sda.

Install grub to separate partition overwriting mbr on sda. Create grub.cfg on this separate partition:

sudo grub-install --root-directory=/RootOfMySepPart /dev/sdbCreate grub.cfg

sudo grub-mkconfig -o /RootOfMySepPart/boot/grub/grub.cfgInstall subsequent Ubuntu OS but do not install grub (untick in last advanced tab)

You can now edit grub.cfg directly. Just remember if there is a kernel update or you install a new OS you need to create a new grub.cfg manually on your dedicated grub partition.
This has worked on 2 single disc pc's booting windows xp, lucid and jaunty.

I also multi-boot vista, jaunty, lucid and slackware off a 2 disc pc.

Hope this helps.

[oldfred]

Your problem is trying to use one /boot partition for two installs. It only installs the last set of boot files and overwrites the first. I do not recommend separate /boot except in special cases - servers, raid, encryption, or old systems that have to boot from beginning of drive. Otherwise a /boot confuses the standard desktop install. If you really want a separate /boot you have to create one for every install.

You can create a separate /grub partition for booting, but I only do that on my USB keys to loopmount my ISOs.

I would install each on separate drives and install grub using advanced button to that drive, so each drive could boot separately. Then an sudo update-grub on the version you want to use the most will find the other. Set that version's drive as the boot drive in BIOS.

If you do not want to always have to run sudo update-grub on main install to see the updates on the secondary install you can add to 40_custom a boot to the most current kernel.

[techxcell]

While installing any distribution of ubuntu, you come across an option to specify the disk and partition you want it to install grub boot loader on (accessible by clicking the "Advanced" button on the last screen of Ubiquity I think).

Then you start the installation of the second Ubuntu Distribution and complete it (including the installation of the boot loader). Just click on the above mentioned "Advanced" button and select the same disk and partition for grub like you did during the install of the first distribution.

You do not need to edit anything. If the first dist. was installed successfully and can be booted into. The second installation will find the first one during its probe and include it automatically!

Well.. Thats how I have always done it. I have all dists! Ubuntu installer is smart enough to detect all installed OS on all disks and include it in the boot config!

[eljeffe]

Doh! I'm sure I didn't hit the advanced tab. Too used to grub (1).

btw. I did get it working by creating a /etc/grub.d/11_mythbuntu file. Way too much work, only gonna work with this kernel, have to remember which partition has the most current version of my addition, ... AND would need total reworking every new kernel. lame!

I'll check it out with another install.

Thanks much
:oops:

[oldfred]

If you want to boot the most current kernel you can use this in 40_custom or your 11_custom.

Ranch hand
Note that this does not define the kernel. It defines the partition. It boots the newest bootable kernel that it finds at that partition.

menuentry "Daily on sda13" {
set root=(hd0,13)
linux /vmlinuz root=/dev/sda13 ro quiet splash
initrd /initrd.img
}

[varunendra]

Sorry if this is hijacking the thread,

@ oldfred,

Not an argument, I just want to improve my knowledge. Won't it work if one simply creates a separate /boot partition for each install without installing grub on each such partition?

I think it should work exactly as installing different distros on different (single) partitions!

And yeah, me too support the 'no separate /boot' idea. Instead, it's good to have one separate (common for all) /home partition.

[oldfred]

The boot partition is just where the boot files are including most of grub. But grub (or a boot loader) has to be in the MBR to start booting. If that boot loader cannot directly boot the kernel in another partition then you have to have another boot loader in that partitions boot sector or PBR.

I do not believe in sharing /home either. Some do it and if the verisons are all the same it will mostly work. If upgrading from one version to another it is fine for the new verision will update settings. But if you have systems using different versions of software you may get conflicts. My /home is only about 1GB of mostly hidden folders & settings as all my data is in a /data partition (including firefox & thunderbird profiles and some other (normally) hidden data folders).

I do believe in creating a /data partition and moving all your data folders to that partition if you have multiple systems. Then you have no conflicts and can easily mount your data in each system. I use linking after mounting it.

[varunendra]

The boot partition is just where the boot files are including most of grub. But grub (or a boot loader) has to be in the MBR to start booting. If that boot loader cannot directly boot the kernel in another partition then you have to have another boot loader in that partitions boot sector or PBR.
..true.
Now before I go any further, I'd like to declare that most of it is my assumption, not a proven fact.

I know that the MBR has to have a boot loader to continue booting (although it is not always necessary- right?). But I believe that if it is Grub2 (assuming it is capable of booting all commonly used OSes, which I believe it is), then there should be no need to have a copy of either grub-legacy or grub2 in each partition (here, by 'partition' I mean an entity other than MBR). It would unnecessarily increase the boot time since it will take double grub-loading cycles (first- Grub in MBR, then Grub in the partition).

For OS like Windows, there is no such confusing state since it installs the MBR & PBR anyway without asking you ;) (requiring you to restore GRUB2). The only 3 cases where I see installing grub in each partition relevant is:


when you accidentally install grub-legacy in MBR which will then chainload (after editing menu.lst) Grub2 in the partition saving you from a boot-failure.
when you are using a third party boot-loader.
when there is no bootloader at all in the MBR and you want to boot different OSes just by making their partitions active (one at a time of-course!)

Except for the 2nd point, I find installing/restoring then updating Grub2 in MBR more convenient.

Again, I don't mean to argue, I just want to know how much ground my assumptions hold.


I do not believe in sharing /home either. Some do it and if the verisons are all the same it will mostly work. If upgrading from one version to another it is fine for the new verision will update settings. But if you have systems using different versions of software you may get conflicts. My /home is only about 1GB of mostly hidden folders & settings as all my data is in a /data partition (including firefox & thunderbird profiles and some other (normally) hidden data folders).

I do believe in creating a /data partition and moving all your data folders to that partition if you have multiple systems. Then you have no conflicts and can easily mount your data in each system. I use linking after mounting it.
..Good point! I couldn't have thought of it before suffering the problem myself. Thanks for the valuable tip.

[eljeffe]

No problem on hijacking this thread. It's all related topically and pretty interesting. I think I'll nuke the /boot partition, get a little room back, and re-install ( the whole while remembering to use the Advanced tab to consolidate the boot sectors on the drives this time ). I used /boot out of habit, but I have decided it's an outdated habit. I mean sheesh, I used to have separate /usr /var /home /etc AND /boot partitions. Back in the lilo, then grub days this was massively flexible.

These days I have a separate /boot, /data (wherein I link stuff from my home directory that won't conflict with other distributions) and / directories. I think I'll go to / and /data. The complexities of the /boot directory under grub 2 just don't make it worth doing. Besides, drives are huge now.

On a side note, with Ubu having so many ui tools for system settings, I do find it surprising that grub 2 is not supported.

Thanks for an interesting and helpful thread.

[varunendra]

On a side note, with Ubu having so many ui tools for system settings, I do find it surprising that grub 2 is not supported.

I think you need to have a look at startupmanager in synaptic.

Thanks for approving my unwanted intrusion ;).

[oldfred]

You always have to a have a boot loader in the MBR. That is how all msdos or MBR partition PCs boot. BIOS automatically jumps to the MBR for additional code to boot. Windows & Lilo have simple code in the MBR that just look for the active partition (boot flag) and jump to the PBR or partition boot sector. An active flag without code in the PBR will not boot. Grub bypasses the PBR normally and allows you to directly load a kernel from any partition and even loopmount from an ISO's own kernel.

If you have grub2 in any one partition it does not load the grub code in any other partition but directly loads the kernel. It does chainload to windows as the rest of the windows code is in the windows PBR. And it can chainload if you want to another boot loader or grub. But grub2 does not like to be in a partition as then it has to use block lists which it says are less reliable.

GRUB 2 has three main parts plus a boot loader installed to the MBR:
1. /etc/default/grub - the file containing GRUB 2 menu settings.
2. /etc/grub.d/ - the directory containing GRUB 2 menu creating scripts.And a place for totally custom entries 40_custom.
3. /boot/grub/grub.cfg - the GRUB 2 configuration file, not editable.

[varunendra]

You always have to a have a boot loader in the MBR. That is how all msdos or MBR partition PCs boot. BIOS automatically jumps to the MBR for additional code to boot. Windows & Lilo have simple code in the MBR that just look for the active partition (boot flag) and jump to the PBR or partition boot sector. An active flag without code in the PBR will not boot. Grub bypasses the PBR normally and allows you to directly load a kernel from any partition and even loopmount from an ISO's own kernel.

If you have grub2 in any one partition it does not load the grub code in any other partition but directly loads the kernel. It does chainload to windows as the rest of the windows code is in the windows PBR. And it can chainload if you want to another boot loader or grub. But grub2 does not like to be in a partition as then it has to use block lists which it says are less reliable.

GRUB 2 has three main parts plus a boot loader installed to the MBR:
1. /etc/default/grub - the file containing GRUB 2 menu settings.
2. /etc/grub.d/ - the directory containing GRUB 2 menu creating scripts.And a place for totally custom entries 40_custom.
3. /boot/grub/grub.cfg - the GRUB 2 configuration file, not editable.

Oh.. stupid me..! How did I miss the fact that Grub can directly load the kernel (after examining outputs of boot info script so many times!!)? Thanks for the detailed explanation.

However, I don't remember since when, but I have a fading memory of having read somewhere (long ago) that MBR is a 512KB block on the hard disk of which only last 44 KB may contain the boot program (boot loader), but it is not necessary! The rest 468KB contains Structure, Partition Table & Boot Partition info (or something alike). The article also had a nice table that explained in detail which portion of MBR contains what, but I don't remember it now. According to it (if I remember correctly) only a few additional bits (boot flag?) (in a pre-allocated space of MBR) tell the BIOS which partition to look for boot sector, and a boot program (44KB max.) is only needed if one needs to provide advance options (like boot menu) before actual loading of OS kernel.

As I said, I only have a fading memory of all of that, so I may be wrong or maybe it was too basic to explain real life boot-process. I think I must look for a detailed info on MBR & PBR once more.

@eljeffe,

I guess you may wish to mark this thread as [solved] :), I'll leave your thread now.

Thanks a lot to oldfred, and you too!

[eljeffe]

OMFG

Yes this thread is solved. But none of the afore was the culprit. I greatly appreciate the updated knowledge I received from the helpful responses. Thank you all. Learning is cool.

Sorry about this, but ubu is now sadly less cool. It is more like M$ Windows than I would like.

The problem ended up being that when I installed new/different versions of ubu I chose to mount previous versions to something like /ubu or /mythtv. This allowed me to do text level configurations ( I know, how radical ) to other versions, regardless of my currently booted linux. This is where I find ubu has become windows like. On whatever mounted system there was ubu setup decided that it would be a kindness to EMPTY out those pesky /boot directories so I wouldn't become confused. (*,)

I tested at m$ for a while and you don't know the number of times developers would say: "Why would anyone do that?". Lots of design bugs/features are still in windows because of that reasoning. I cannot express strongly enough, as mere language is insufficient, my disappointment at this realization.

By now you know the solution for this problem. All I had to do was make my mountings AFTER ubu got out of the way and edited fstab. With a heavy heart, I'm marking this thread solved.

Thank you