[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Felix Miata
Subject: Re: managing a multiboot without stomping the toes of other OSes
Date: Fri, 14 Jan 2011 05:54:34 -0500
User-agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:2.0b8pre) Gecko/20101030 SeaMonkey/2.1b2pre

On 2011/01/14 16:03 (GMT+0530) Rustom Mody composed:

Felix Miata wrote:


Ok Ill try that

 As extra insurance, I've been removing:


 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.

 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  ***

reply via email to

[Prev in Thread] Current Thread [Next in Thread]