Quoting Peter Jay Salzman ([EMAIL PROTECTED]): > I remember Rick Moen's post about the bootable flag from a few years ago. > > Rebooted Knoppix. Ran fdisk. > > I toggled the bootable flag on hda4 so now hda1 is the ONLY partition with > the bootable flag turned on. Previously, both hda1 and hda4 had the > bootable flag. > > Rebooted. > > Worked.
Congrats. Yeah, the nameless Microsoft Corp. MBR first-stage bootloader is really fussy about that flag. It wants to see the flag on exactly one primary partition, and upon seeing that loads whatever is in sector zero of that partition into RAM and hands over control of it. Woe and betide unto you if you don't give it the partition-flag situation it expects. Note that reinstalling a Microsoft OS always causes it to reassign the bootable flag to what _it_ wants, silently discarding whatever your own policy dictated -- and also overwrites (without consulting you) the MBR sector's program space (initial 446 bytes). For example: Suppose your booting strategy is to allow the nameless Microsoft Corp. MBR program its preferred hegemony over your MBR's program space, and use lilo in the /dev/hda2 superblock to select which OS to boot. Before Linux installation, you have: /dev/hda1 bootable (aka active) flag NTFS After Linux installation, you have: /dev/hda1 NTFS /dev/hda2 bootable (aka active) flag ext3 /dev/hda3 Linux swap At power-on, the BIOS is initially in charge, and the Int13h boot service searches bootable drive devices in the order you specified in the BIOS CMOS, checking each in turn to find the first one that reports itself to be in "ready" state. (E.g., a diskette or CD drive with no media would report "not ready" and be skipped over.) The Int13 boot routine finds the first ready drive device, loads its sector zero into RAM, and transfers control over to whatever was found there. In this example, it found your hard drive's MBR (446 bytes of program space, 64 bytes of partition table, 2 bytes of flags used by NT Disk Administrator and little else). Thus, the nameless Microsoft program wakes up, rummages through its data space (partition table + 2 bytes), and finds the third entry bearing a bootable flag. Not being confused and upset by multiple flagged entries ;-> , it loads into RAM sector zero of the partition thus described and reliquishes control to the contents thereof -- which happens to be lilo because you had "boot=/dev/hda1" in /etc/lilo.conf and ran /sbin/lilo to implement that directive. The lilo bootloader now comes alive and offers you a choice of... (1) branching back to /dev/hda1 (sector zero of the NTFS partition; _not_ the MBR, which is addessed as /dev/hda), which happens to be where NT's OS Loader lives, or (2) loading a Linux kernel image + initial RAMdisk from within /dev/hda2, which in turn load /dev/hda2 as the runtime root filesystem. (You may be fully aware of the above, but I thought sketching out the boot process might help some others understand what's going on.) -- Cheers, "This is Unix. Stop acting so helpless." Rick Moen -- D.J. Bernstein [EMAIL PROTECTED] _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
