l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
August 5: Social gathering
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2004 Sep 24 11:51

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] rescuing winxp? (resolved)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] rescuing winxp? (resolved)



Er, I forgot to make the point I was driving towards.  Quoting myself:

> 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

[snip gory details of bootstrapping]


Suppose, some while later, your NT/W2k/XP installation commits seppuku
in some fashion, and you decide to reinstall it, overwriting the same 
/dev/hda1 in order to make the thing operable again.  The MS installer,
in addition to loading a big load of stuff _into_ /dev/hda1, will
without asking your leave reassign the bootable flag:

/dev/hda1   bootable (aka active) flag    NTFS
/dev/hda2                                 ext3
/dev/hda3                                 Linux swap

(At the same time, it will, without asking your leave, overwrite the
446-byte program space at the beginning of the MBR.  But you don't mind
that:  All it's doing is replacing the nameless Microsoft MBR bootloader
with a fresh copy of the same -- at worst, a net NO-OP; at best, you'll
wipe out any MBR virus that anyone carelessly installed.)

That change having been made, the Int13h BIOS boot routine never loads
lilo from /dev/hda2's sector zero, but instead branches stratight to
/dev/hda1's sector zero contents, i.e., NT's OS Loader.  Ergo, your
ability to dual-boot gets silently obliterated (until you realise what
happened and fix it).

My point is that people whose living-with-Microsoft dual-boot strategy 
entails conceding the MBR to Redmond need to know about that nasty
habit, and be aware of the need to retweak the bootable flag after each
Microsoft OS reinstallation.

-- 
Virtual Regards,
Rick Moen
Sysimperator, dominus regis deusque machinarum.
rick@linuxmafia.com
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!