Re: managing a multiboot without stomping the toes of other OSes

[Rustom Mody]

On Fri, Jan 14, 2011 at 4:24 PM, Felix Miata <address@hidden> wrote:
> On 2011/01/14 16:03 (GMT+0530) Rustom Mody composed:
>
>> Felix Miata wrote:
>
>>>          GRUB_DISABLE_OS_PROBER=true
>
>> Ok Ill try that
>
>>>  As extra insurance, I've been removing:
>
>>>         /etc/grub.d/30_os-probe*
>
>>>  Since I'm a mostly a non-Debian user and I've always remembered to
>>> specify /
>>>  or /boot as a Grub target during OS installation, I've never yet needed
>>> to
>>>  move a Grub2 location or figure out how it's done. NAICT, one would do
>>> this
>>>  by specifying the /boot or / target as a device name running
>>> grub-install.
>>>  See: https://help.ubuntu.com/community/Grub2
>
>>>  Another option to consider is installing grub-legacy to sda3 and/or mbr
>>> and
>>>  using its chainloader to reach sda5&  sda6. Typically I pre-partition
>>> and
>>>  boot a Knoppix disk to mkfs and install Grub1 on a virgin HD before
>>>  installing any operating systems. On multiboot systems I keep a separate
>>>  realboot /boot partition that I never mount as /boot and from which I
>>> either
>>>  load default kernel/initrd sets from specified partitions, or chainload
>>> to
>>>  specified partitions.
>
>>>  One can always expect stepped on toes when multibooting and accepting
>>> the
>>>  usual installation default to install a bootloader to the MBR. Thus I
>>> find
>>>  MBR as default bootloader location as policy to be ludicrous. Any OS
>>> that
>>>  insists on MBR as bootloader location I abort and/or eradicate from my
>>>  systems. Grub on MBR is rarely necessary. I've never needed it, while I
>>> have
>>>  many machines with up to 25 or more installed operating systems.
>
>> I really dont understand (many things actually:-) )
>> If there is not a bootloader in mbr how does the machine boot?
>
> In the beginning of the life of what we know today generically as a "PC",
> IBM made some MBR boot code that takes less than 447 bytes to do its job.
> It's latest incarnations came to be called standard MBR code. Standard MBR
> code transfers boot control to whichever primary partition is marked active.
> Your sda3 is a primary partition, so standard MBR code will cause sda3's
> installed boot code to take boot control as long as it is marked active and
> is the only primary marked active. Any valid partition boot code installed
> to sda3 will take the control passed from standard MBR code.
>
>> Furthermore when grub-installing to /dev/sda6 (instead of /dev/sda)
>> I get all kinds of ominous warnings and what not and grub wont do it
>> until I give a --force option.  This seems to be the opposite
>> direction of what you are saying
>
> Actually it is warning you, as expected, against my admonishings. Grub2 devs
> think Grub belongs on the MBR, so Grub resists attempts to put it elsewhere
> as a function of (its dev's ludicrous) policy. Use --force (if that's what
> it takes), and take control of your computer back from Grub2's devs. Next
> time you're installing, be sure to specify a /boot or root partition as the
> Grub installation location. You should note at that time that the *buntu
> installer will actually suggest that non-MBR is a viable option if it finds
> you installing on a system that already has operating system(s) installed.

Installation is not the primary problem; its (semi)automatic upgrades
that mess up.

>From what you are saying one problem -- auto-probing -- is solvable.
The other -- which partition is grub in -- is yet not solved (or
understood by me).

Let me try put it another way:  I want to go from one way link to two way link.
Currently sda6 boot sector points to debian. I want to have a reverse
link (probably something in /etc/default/grub or /etc/grub.d) that
tells debian that it needs to mess around only with sda6.

And if this is not doable I want help with another workaround.
Currently I maintain 3 grub.cfgs by hand (the sda5 of ubuntu the sda6
of debian and the sda3 which does chainloading).  is there some
convenient utility (other than reading octal dumps of filesystems!!)
that can tell me that this bootsector/mbr is currently setup to start
booting from this partition?

And one last (unimportant) question: how come on the grub help list I
am getting answers that dont agree with grub philosophy?? Something
strange here...