[vox-tech] rescuing winxp? (resolved)

[Rick Moen]

Quoting Peter Jay Salzman (p at dirac.org):

> 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
rick at linuxmafia.com