[Freedos-user] re: FDISK MBR and FORMAT questions

[Eric A. <er...@Co...>]

Hi again (wow, what a lot of traffic today, sigh...),

> > I wanted to make ABSOLUTELY CLEAR that nothing must ever automatically
> > do FDISK /MBR with as only exception a CUSTOM install disk for unattended
> > install on known-empty / known-not-to-have-any-useful-MBR-program systems.

> too bad, people want to have a working system being set up for them.
> if MS FDISK does alter MBR, then our FDISK should do so also.

I already gave the answer to that one: Display a message "if you have
reached this [i.e. partitioning done, SYS done, OSCHECK confirmed the
success of SYS] point and still nothing at all happens when you try
to boot, please boot from CD-ROM again and type FDISK /MBR".

No idea whether MS FDISK zaps the MBR from time to time, but it better not.

> On the other hand, destroying dualboots is something MS also does in 
> Windows setup, and which is a thing we can't afford...

Good example.

> > Buy a new harddisk and do:
> > MIRROR /PARTN

> only get a "Drive letter is out of range..operation terminated"
> any debug script?

MIRROR 0 /PARTN maybe? I am not overly happy with MIRROR anyway, and
always use UNDELETE SYSSAVE instead (which can save a lot of stuff
but not the partition table).

> > Whether the current MBR PROGRAM is working is as hard to decide as whether
> > you have a boot virus in there. Far beyond the scope of FDISK.

> consider the presence of AA55 as "working".

FDISK 1.2.1 / 1.3.0-beta works like this and it kills disk contents. NOT GOOD.

In addition, the 55 aa only means "there is a partition table" (DATA)
and makes no claim whatsoever about the PROGRAM. If there is a program,
you cannot know if it WORKS unless you have a database of all working
boot loaders, along with information which of them can handle LBA and
information which of them you should never see (e.g. the database would
tell you that if you can see EZDRIVE then you MUST NOT proceed with
FDISKing, as you will get the wrong partition table contents and might
even kill EZDRIVE, possibly losing access to all data on disk until
you repair it, which is not at all trivial...).

Actually it would be an idea to backup the MBR before anything is
written to it. FDISK had some command line option to do exactly that,
read the FDISK /? output. I mean: FDISK can save the MBR to a file.
Well, the user would then have to save that file to diskette to make
repair easy, but at least repair from "unbootable but partition table
data is still okay" state would get easier even without diskette backup.

> we buy a brand new hard drive that's a clean as you can ever get, and we 
> want to install a DOS or Windows operating system to it - we haven't 
> decided yet. What is the correct procedure for getting a "working boot 
> program" into the "valid Master Boot Record", and who supplies this 
> program? Is it Microsoft, Intel??

To force the MBR to contain a working boot PROGRAM by deleting the
previous version of the boot program, use FDISK /MBR. This even
works with FreeDOS FDISK, but my point is that it should never
happen automatically, because:

> arrive with XP pre-installed, and I have to FDISK them to get rid of it, 
> but those drives STILL HAVE an MBR right?

Yes, if you use FDISK to remove the drive letters for WinXP, the MBR
boot program will stay working. Basically the chance to meet any
harddisk with broken or missing MBR boot program is only the fraction
of the chance to completely screw up your system (EzDrive case) or
the bootability of your system (many other cases) by doing FDISK /MBR
without thinking about it carefully first.

Okay, there are ways to reconstruct partition tables, but just keep
it like: Add a text to the readme, or, if you insist, to the install
system messages, which tells "if you have never booted any OS on this
PC or harddisk, then there is a tiny chance that you have to use
FDISK /MBR if the system does not boot after you completed this
install process. Do never ever use FDISK /MBR if you already have other
operating systems or boot loaders on this system..." Okay, not never
ever, sometimes you can be in the lucky situation that FDISK /MBR
overwrites a virus without breaking your system, basically if you use
no EzDrive/OnTrack/DDO-style software and no fancy boot loaders or
anything smiilar.

> However, if I understand correctly, AA55 is just a sig, it's not a boot 
> program...

Exactly. Current FDISK 1.2.1 decides that if the sig is missing
(or a read error happens) then it would be okay to delete the
entire MBR data and entire MBR boot program, replacing it by
values for an unpartitioned empty harddisk (but at least with a
boot program). So current FDISK 1.2.1 can and will destroy your
data if a read error happens or some other unexpected things happen.
Luckily gpart can often guess the deleted values after an hour of
searching or so, allowing you to regain access to the disk, as
only the partitioning but not the contents of the partitions screws up.

Eric