update grub + 2 ubtuntu installs with shared /boot

[Philip Lawatsch]

Gary W. Swearingen wrote:
> Philip Lawatsch <philip at lawatsch.at> writes:
> 
>> I have
>>
>> a amd64 system (dapper) installed into /foo, a
>> a i386 system (dapper) installed into /bar and
>> a partition mounted as /boot by both (!) installes
> 
> Please reconsider your way of saying where your OSes are installed.
> Maybe the above makes sense in some context or with more explanation,
> but it's seriously confusing to this long-time Unix user.  One usually
> states the device names of the partitions where an OS mounts its
> directories.

Sorry, actuall I meant /dev/foo and /dev/bar

>> Now my problem is that when update-grub is called on one system it will
>> happily trash the other systems entries in menu.lst.
>> What happens is that it seems to completely rewrite the entries and thus
>> does not consider that the kernels have different root parameters.
>>
>> So, if update-grub is run on 32 bit then the next time i boot the 64 bit
>> kernel I'll end up in my 32 bit system (with a 64 bit kernel though) and
>> vice versa.
>>
>> Would someone know a fix for this problem _except_ creating seperate
>> /boot dirs and install grub 3 (2 would work too I assume) times?
> 
> You can't be supprised that mounting one partition as the "/boot" of
> two different OSes will give you grief. 

Actually I am surprised. I've never had problem with that before (using
a 32 and a 64 bit gentoo install).

The only thing that seems to break is menu.lst, simply by the fact that
update-grub touches stuff it should not touch (in my case at least).

> It looks like to do what you
> want, you'd need to customize the /sbin/update-grub script.  (The
> script is apparently not smart enough to guess what root parameters
> you want for each kernel nor allow you to tell it.) But that's
> probably not worth the effort since editing menu.lst by hand is so
> easy.  

Well, imo the correct fix would be to specify an action to update grub,
like 'upgrade from kernel foo to bar' and have update-grub then add /
substitute a new entry for kernel bar with the parameters of the old
kernel. But it should do _nothing_ else. In this scenario I would never
run into the problem.

> You'll probably have to read a bit of "info grub" to learn
> how to specify the proper root partition for each OS entry in menu.lst.

I've no problem understanding / using grub, I've only got a problem
understanding all the automatisms which are in ubuntu and deal with grub.

> I don't understand the comment about installing grub multiple times.
> As long as you have installed the grub bootloader once, you should
> only have to ensure that menu.lst reflects the kernels that you have
> in your single "/boot" and then reboot.  And it shouldn't matter from
> which OS you installed the bootloader.

Well, if I want the comfort of automagically booting the correct kernel
even after an upgrade then I have to have some hack in place to allow
update-grub to update menu.lst without breaking the other install.

For this to work with 2 installs every install needs to have a seperate
menu.lst

And for this to work I would need at least 2 grub installs, where one
grub starts the other grub (and have only one grub installed in the mbr).

In my case I'm going to have one grub installed in the mbr which will
start a bsd install, a windows install and then a different grub for
each of the two ubuntu installs.


kind regards Philip