Mail Archives: opendos/2001/12/02/12:20:30
On 2001-12-01, Thomas A Webb wrote:
> The specific instance was an old 486 with Linux partitions, and if DRDOS
> needs to read what's there in order to replace it, Ill probably have to
> look for another solution. MS-DOS apparently doesn't attempt to
> interpret what's there, because it works fine.
When you use FDISK to write a new MBR, itīll first read this sector.
This is the same under all issues of DOS. Depending on the existance
of a magic signature 55AAh in there, the FDISK utility will then decide
if it will write a new virgin MBR or a MBR that holds the old partition
table with only the bootstrap code replaced by some generic code (so
you can kill a boot virus, for example).
In other words, you cannot destroy the partition table by MS/PC FDISK
/MBR or DR FDISK "Write new Master Boot Record" unless the contents
is already invalid (or maybe when no partitions are defined).
When FDISK writes the new MBR and some resident anti-virus protection
is active (either a TSR or some code built into the ROM-BIOS), this
attempt will be discarded and youīll usually see an alert pop-up
box indicating the problem. Unless you know some secret codes to
bypass these protection schemes this will happen with any tool
trying to write a new MBR.
However, I assume the problem is related to a DR-DOS feature to
back up the old MBR for later restoration in case of problems
with the new MBR code. This backup copy is written as a normal
file through the filesystem, and AFAIR is always placed on drive
C: in the released version of FDISK. Now, the possible problem:
If DR-DOS cannot access drive C: because it is not FAT12/16
it cannot write its backup copy, and apparently fails with
an error message, instead of just skipping the backup...
Note, that right now I havenīt re-checked the sources to
see what actually happens in this situation, but from your
description this sound like a possible explanation for
what you see.
If this would be the case, you will either not be able
to use DR FDISK, because you cannot specify a different
destination path for this backup file, or will have to
delete all partitions first from within the menu system.
(Unfortunately, it doesnīt help you much that I can tell
you that besides many other additions some handy features
like a) command line options, b) unconditionally write MBRs
on request, c) more versatile options for backup files,
and d) options to specify the destination drive are already
added in my internal issue of FDISK, simply because I cannot
publish this without Lineoīs permission...)
However, MS/PC FDISK /MBR will also not be a solution to your
problem, because they too will not overwrite the partition
table unless itīs already garbaged o empty.
> The problem is this:
>
> When installing Linux, the mbr needs to be a POBT (Plain old boot
> track). Many of the machines we recycle have had Windoze or os2 on them
> in the past, and we need to be able to start fresh. In addition, there
> are opportunities (several, actually ;-) ) to screw up a Linux
> installation to the extent that it is usefull to start over. MSDOS works
> fine for this, but I can't provide a download utility disk using MSDOS
> because of licensing issues.
Really? AFAIK MS-DOS FDISK /MBR does overwrite the bootstrap loader
in the MBR, but not the partition table unless the 55AAh signature
is not in there any more. This is the same as with DR-DOS FDISK...
> I have found shareware "disk editors" that will do this, but they aren't
> what I would call production tools. I have thought of creating a simple
> utility ( in C ) that would simply pop a new mbr on the drive without
> dragging us through a lot of nonsense, but I was hoping there is a
> simple solution already out there. This is all that is holding up the
> release of SlamDunk Linux procedures, and I would appreciate any
> suggestions.
Well, I would either use a DEBUG script or code a tiny .COM program
in assembler just to write 512 bytes of zero to the first sector
of the drive with unit number 80h. I donīt post code here, because
I consider this to be very dangerous, but if you like, feel free to
ask in private mail for my SETMBR.BAT wrapper (which uses DEBUG).
Hope it helps,
Matthias
--
<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
- Raw text -