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

[Felix Miata]

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.
--
"How much better to get wisdom than gold, to choose
understanding rather than silver." Proverbs 16:16 NKJV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/