Date: March 30, 2001
From: NoClue
A lot of people have been asking about "nuke and pave" lately. I had a
fairly detailed post on the other board...looks like it's time for another. 
(Editor's note: Nuke=wipe out everything on your hard drive; Pave=make the operating
system new.)
Many people have their own method of setting up a fresh machine; some break their
drives into multiple partitions, some load the entire Win98 folder from the install
CD into it's own partition, etc. There's no 'right way' or 'wrong way'. This is just how I
prefer to do it.
I say Win98, here, because:
Installing Win95 is a little different.
Installing WinNT is a little different.
I don't make a separate swap file partition for Win2000.
I don't have any idea about WinMe.
(Editor's note: But the information here is generally useful no matter what OS
you will be, cleanly, installing, and well worth the read.)
What you'll need:
- Someplace to back up your data. Whether it's floppies, Zip disks, CD-R/RW media,
another hard drive or even a network share, you'll need a safe place to keep your stuff
until you can copy/restore it back.
- Your Win98 Installation CD.
- A Win98 setup boot disk. You can make this if you don't have one. Go into the
'Add/Remove Software' applet in Control Panel, click on the 'Startup Disk' tab, then click
'Create Disk'.
- Fresh drivers for your hardware. This can include motherboard chipset drivers on
some machines. Win98 has a lot of drivers on the CD, but not all of them. Better to have
them and not need them...
To quote from MaximumPC's Clean Start article (another good place to get ideas about
this):
quote:
"Be fully aware of what you're doing before you blindly FDISK your PC.
You'll be doing a complete wipe of the hard drive, which means all the information on it
will be lost. And all means all-all of your old e-mail, all of your bookmarks, all of your
Internet connection settings, all of your saved games, fan letters, resumes, dirty JPEGs,
and 14GB of MP3s. They will all be gone.
Unless, of course, you back them up first. Before FDISKing, figure out which personal
files are important to you and where they live on your hard drive, and back them up on the
media of your choice, or on another machine. Don't even try to blame us if you lose your
dissertation because you forgot to back it up. When we say everything must go, we mean
it."
Good advice...you would do well to follow it.
There are a few threads on this board about backing up your data (here's
one). One thing that can be missed is your Network settings. If you have a Dial-up
connection, jot down any information in the Dial-Up Networking Properties in My Computer.
If cable or DSL, the information will be in the Network Properties applet in Control
Panel. You'll want to know the names of your mail server (s). Make sure you know your
login name and password.
After backing up the more obvious stuff, I'll sometimes do a quick search for certain
file extensions (.zip, .doc, .mp3, etc.) just to make sure I didn't miss anything.
I prefer to break my boot drive into 2 partitions; one for...well, pretty much
everything, and the other for the swap file. I find that (for Win9x) having a
fixed-sized swap file in its own partition (so that it stays unfragmented) really speeds
up a machine. I set the swap file partition at 2.5 times the amount of RAM in the machine,
then I add about 50MB so that Windows doesn't keep complaining about the drive being full.
You'll need to do the math...I find I usually do it during the fdisk portion, when
it says the drive size right on the screen.
Time to 'Nuke':
OK, you've got your backups and all your internet connection info handy, along with
your boot floppy and install CD. What's next?
MaximumPC has a good idea here...test the boot floppy. (I usually don't because
I have quite a few around here, and because I boot straight off the CD for Win2000). Pop
that floppy in the drive and boot, with CD-ROM support, and make sure that you can read
the files on the CD-ROM. Type D: at the DOS prompt (or whatever the CD-ROM drive
letter is) and hit Enter, then type DIR and hit Enter. If you see a list of files
and directory, your disk works fine.
Type A: at the prompt and hit Enter. If you are sure you are ready to wipe the
drive, type fdisk and hit Enter. Say 'Yes' to the question about large hard disk
support (FAT32). You may want fdisk to display your partition information, if it
shows one single primary partition, you're all set. Choose option 3 (Delete partition or
logical DOS drive) and then 1 (Delete Primary DOS partition). Answer the questions. Your
drive is now 'Nuked'.
On to 'Pave':
Return to the main fdisk menu. Choose option 1 (Create DOS partition or logical
disk drive), then 1 again (Create a Primary DOS partition). Say 'No' when it asks you if
you want to use the maximum amount of space. Now it's time to do the math. Multiply the
amount of RAM in the machine by 2.5, add 50 to it. Subtract that number from the drive
size shown. Make the primary partition that size (fdisk may change the number a
bit, but not by much, don't worry). Make the new partition active by choosing 2 from the
main menu (Set partition active). The create the swap file partition. From the main menu,
choose 1, then 2 (Create Extended DOS partition). You can use the default size this time. fdisk
will prompt you to create a logical drive in the extended partition. Choose the default.
Now the install. Reboot with your boot floppy in the floppy drive and your Win98 CD in
the CD-ROM. Let the install run, it will format both drives for you.
I usually do a custom install when it asks, that way I can not install some stuff I
won't use, and add some stuff that doesn't load by default. Your call.
Reboot at the end of the install and load the drivers for your hardware that either
weren't recognized by Windows, or are newer than the version Windows installed.
Once all your hardware is working correctly, you can move your swap file to it's new
home. Right-click on My Computer, choose 'Properties' and then hit the 'Performance' tab.
Click on the 'Virtual Memory' button. Choose the drive letter for the new extended
partition and set the maximum and minimum sizes to 2.5X RAM.
Load your software, copy/restore your backed up data to the new drive, set up your
internet connection and mail client and enjoy.
Date: April 10, 2001
From: Bob
Some disk managers (EZ Drive, Disk Manager) will not clear the partition table even
when you attempt to remove everything.
After the first time a partition table is written to the disk, FDISK will not clear the
partition table even if you remove everything.
A virus infected or corrupted partition must be removed and a new partition table must
be made from scratch. For virus considerations, the system must be booted from a disk that
is virus free.
A new partition table can only be created by first removing the existing partition
table.
This debug script will remove the partition table by writing 0's to the area of the
drive where the partition table resides (Cyl 0, Head 0, Sector 1), effectively removing
the partition table.
A caveat here: I don't think this notice is necessary, but let's be safe.
First, make sure that this procedure is safe to do on your hard drive. I don't know
how to tell you to do that, but you take full responsibility for what you do to your
computer.
I would think long and hard before using this routine on a laptop computer. I'd
probably call the laptop OEM and ask their support team about the problem and this routine
before going ahead with it. It wouldn't surprise me to find out that a disk manager
program supplied with a laptop was essential to the operation of the laptop.
As for all other IDE drives used in desktop and server systems, I will only say that
I've used this routine on well over 50 EIDE drives of sizes from 1 GB to 40 GB and I have
not yet caused any harm. These would include drives from Seagate, Western Digital,
Maxtor, Quantum, Fujitsu and IBM (and maybe others.) The routine has worked in all
cases. Some computer manufacturers may fail to honor their warranty if you use this
routine. On the other hand, I've used this routine when the drive geometry was
munged or when disk managers were inappropriately present or when partitioning software
would not handle a present partition, and, in all cases, the results were a functioning,
healthy drive after subsequent partitioning and formatting. OK, end of caveat.
(Editor's note: Debug is a program that will be included on a Windows 98 Startup (Boot)
diskette. Debug is run from the command prompt.)
With the partition table removed, the disk "looks" as if it has been totally
wiped. For the script below, the DX register holds the identifier for the drive.
"0080" identifies drive 0.
A:\>DEBUG
- f 200 L200 0
- a 100
xxxx:0100 mov ax,301 (ignore segment :offset values at left)
xxxx:0103 mov bx,200
xxxx:0106 mov cx,1
xxxx:0109 mov dx,0080
xxxx:010C int 13
xxxx:010E int 3
xxxx:010F (Press ENTER an extra time here)
- d 100 LF
xxxx:0100 B8 01 03 BB 00 02 B9 01-00 BA 80 00 CD 13 CC
(make sure that hex values match above line before proceeding)
(if values do not match, type Q and start over)
- g=100
(ignore register display)
- q (quits back to DOS)
FDISK should display the message "No partitions defined."
What the debug routine defines:
(Values in DEBUG are HEX)
- f 200 L200 0 FILL
Length of 512 bytes at offset 200 with value 0
- a 100
ASSEMBLE program at offset 100
(Enter register values for INT13 - Function 03)
mov ax,301
AH=03 INT13 function 03 - Write Disk Sectors
AL=01 specifies the number of sectors to write (1)
mov bx,200
BH=02 BL=00 points to buffer area at offset 200
mov cx,1
CH=00 specifies cylinder 0 for INT13 function 03
CL=01 specifies sector 1 (first sector on drive)
mov dx,0080
DH=00 specifies head 0 (first head on drive)
DL=80 specifies physical fixed disk drive 1
(81=2nd drive, 82=3rd drive, 83=4th
drive)
int 13
call INT13 (BIOS Fixed Disk Device Service Routine)
int 3
return to DEBUG (after assembling program)
(blank line) end of routine
- d 100 LF
this line is optional - the resulting hex dump can be
used as a check to verify that instructions have been
entered correctly
- g=100
GO - run program stored at offset 100
- q
QUIT DEBUG back to DOS prompt
quote:
Originally posted by NoClue:
I used to have a DOS program that would essentially do the same thing...I wonder where
that got off to?
Bob: Never ran across it. Don't know where I
snagged this routine, albeit there are
several that do the same thing, with minor
differences, posted in various places on
the internet, including one that uses int
20 (process management) for the return and
specifies a length of 4096 bytes (1000h).
Hmmmm. I usually run debug from a booted floppy
and cold boot after the routine (is finished) running.
Int 20 is usually considered to be a cleaner method
of terminating a program, though in this case the
concern is hardly warranted. Int 3 is specifically
designated for use in returning control to the debugger
from a breakpoint. Int 20 restores a number of vectors,
flushes file buffers, and transfers to the termination
handler address causing release of assigned memory.
Considering that the next logical action is to cold boot,
messy termination works too. I don't write assembler,
but I am curious to find out just what mayhem I may be
causing...
quote:
Originally posted by ntwrklarry:
To Bob:
Please explain what you mean by DX register and are we supposed to put a number where
the xxxx's are? Is that where the 0080 goes?
Do we also include the parentheses and everything in the parentheses in our commands
too?
Bob: The xxxx's are a 4 digit hex number that will be supplied by the system to the
debug program. That 4 digit number represents the segment portion of an address in memory.
Depending on what else is loaded into memory (which can vary by OS and configuration), the
segment delivered to debug for entry of a program will be different from system to system,
perhaps from session to session.
As someone following the script above, the segment address delivered is of no concern
to you. Because the segment may be different on your system, I did not use a specific
segment, but indicated a generic segment with xxxx, just as you would indicate a generic
drive by using X:\ rather than C:\, D:\, etc.
The X86 family of CPU's were originally designed to manage a segment-offset memory
schema. More recent chips in the family use flat addressing and translate to
segment-offset (native mode/real mode) for backward compatibility. The reason for the
segment-offset architecture is to combine two 16 bit registers to deliver a 20 bit memory
address. A segment is a contiguous 64K block of memory. A specific location in that block
is located with an offset. In the script above, the programmer instructs debug to start
writing the program at offset 0100h of the delivered segment. As the programmer, you are
particularly concerned about at what offset your program starts, and you accept the
segment that debug delivers to you (which is actually the next available segment in
memory.)
What you don't need to know is, that to compute a location in memory, the segment
portion of the address is multiplied by 16 and added to the offset resulting in a 20 bit
address (er, sort of.) Debug is an ancient utility. Only the offset pointer can be moved
which means that you are limited to writing 64k programs with it. Not a limitation for our
miniscule use.
So not to worry about the xxxx. xxxx will be supplied.
The script above is a recipe for writing a program. If you enter "debug" at
the A:\ prompt (after booting to DOS with, say, a Windows 98 Startup disk), you will be
greeted with a dash prompt. The dash prompt is your indication that you are no longer
issuing commands to the shell, but are now issuing commands to debug. The script shows
those commands. For instance, the "a" command says to assemble a program and the
"100" argument says to do it at offset 0100h.
A register is a small piece of very high speed memory that is located in a CPU.
Registers in a CPU are identified and in some cases specific registers are given specific
functions used to assist CPU operation. Other registers are provided for programming. The
basic Intel 80X86 architecture provides 4 16 bit data registers. They are the accumulator
(AX), the base (BX), the count (CX), and the data (DX).
Those names come from ah, er, "traditional" usage. The accumulator is used
for math functions, I/O functions, and string operations. The base register is used for
addressing data in memory. The count register is used for loop or traversing operations.
The data register is used for I/O operations, port numbers, and math operations. However,
our interrupt routine treats them as what they really are: registers for general usage.
In our case, the program will call an interrupt routine that looks in the data
registers for information on how to operate. The first four lines of the program
initialize the data registers with the data that the interrupt routine requires to
operate.
The Intel 16 bit registers can be separated into high order and low order portions of 8
bits each. Thus, the DX register can be read as DH and DL ( or IOW, as a single 16 bit
register --OR-- as two 8 bit registers.) Some interrupt routines will look at the high
order and low order data separately and use the data accordingly. The 00 piece of the data
in DX tells the interrupt routine to use head 0. The 80 piece of the data in DX tells the
interrupt routine to use drive 0.
The fourth program instruction uses the MOV instruction to initialize the DX register
with a 16 bit value 0080h which will be used as two 8 bit values of 00h and 80h by the
interrupt routine.
If you have a drive that you want to subject to this routine, then you essentially want
to lose all the data on that hard disk anyway. So, it will cost you nothing to try the
routine. What's the worst that can happen if you fail?
Put the hard drive in the system as drive 0. Boot from a DOS boot floppy of some sort.
Run the debug program from the "A:\" prompt and see if you can figure out, from
the script, the part that debug supplies and the part that you supply.
The instructions in parenthesis do not get entered. They're for the operator. However,
you can't hurt anything by entering those characters--but don't expect the routine to work
if you insert that information, maybe... 
Hmmm, maybe this will help. Your keystrokes are in bold...
A:\>DEBUG
- f 200 L200 0
- a 100
xxxx:0100 mov ax,301 (ignore segment :offset values at left)
xxxx:0103 mov bx,200
xxxx:0106 mov cx,1
xxxx:0109 mov dx,0080
xxxx:010C int 13
xxxx:010E int 3
xxxx:010F (Press ENTER an extra time here)
- d 100 LF
xxxx:0100 B8 01 03 BB 00 02 B9 01-00 BA 80 00 CD 13 CC
(make sure that hex values match above line before proceeding)
(if values do not match, type Q and start over)
- g=100
(ignore register display)
- q (quits back to DOS)
Reboot.
FDISK should display the message "No partitions defined."
Originally posted by ntwrklarry:
So are you saying once fdisk is used once that it will not be able to remove the partition
table thereafter?
Bob: That's right. All entries can be removed so that it can look like there are no
partitions. However the table and its descriptors and the MBR remain.
Provided that FDISK understands your drive and all it's partition entries, you can
remove the partition entries and do a slash-MBR and the disk is mostly clean. It is
sometimes difficult, with FDISK however, to circumvent the various 3rd party disk
managers.
Disk managers are crutches for OS's that don't know how to deal with large disk
volumes. Bob sez, "Trash the disk manager and get an OS that understands your
drive."
The debug routine above leaves no doubt that the disk is mostly clean.
The routine is also useful for nuking partition tables that contain entries that FDISK
won't handle. Like corrupted entries, or some ---uxish entries, and not some few of those
listed in the partition types document (The links, I had, that pointed to partition table
information, have decayed. I have reproduced information about partition types in a document here.)
Each partition table entry is 16 bytes. The information contained in those 16 bytes is
(more or less) dense considering the information provided. For CHS drives the start and
end location of a partition is stored and for LBS, the start and size in sectors is
stored. Also the partition type and the "active" partition flag is stored there.
Versions of FDISK that do not support large drives will incorrectly compute LBA values.
Bytes 0-3 in the table are used by the small program in the Master Boot Record to read
the first sector of an active partition into memory. Now you can see why a virus might
target the first sector, infecting it and moving the legitimate code to where it can be
referenced by the virus.
The MBR uses the same registers (with some different values) as our routine above and a
different service (AH=02) of the same INT 13 routine for the purpose of reading the active
partition's boot sector. Up until this point, we're talking PC and not any particular OS.
Originally posted by ntwrklarry:
What happens when you do subsequent fdisks? Does it edit the original table or what?
Bob: Yes.
Note that extended partitions have extended partition tables.
And only a very small bit of this pertains to W2K dynamic disk structure. W2K basic
disk structure does use this kind of partition table.
Caveat: Just like the low-level reformatting that we used to do off the hard drive
controller ROM, this ain't gonna work forever. Drive architecture will
change.
Bob (April 10, 2001): A note about EZ-Drive, a disk manager shipped with Western
Digital drives. First, with modern equipment, you shouldn't need EZ-Drive and
probably shouldn't use it. EZ-Drive rewrites the partition table to Sector 2, moving
it from the default location of Sector 1. EZ-Drive also rewrites the MBR and alters
the default partition table creating a non-DOS partition. The debug routine above
deletes any reference to sector 2 which would have been stored in sector 1. If you
want to be a purist about cleaning the hard drive, you should wipe sector 2 as well.
To do this, use the debug routine above, but change the length value on the first line
from 200 to 400, and change the value for the ax register to 302. It is important to
reboot any system where the disk geometry or partition information has changed.
FDISK Section
The FAT16 file system included with DOS and Windows 95 (prior to OSR2) is limited to 8
gigabytes per hard disk and 2 gigabytes per partition. These are limitations of the FAT 16
file system. Windows 95 Does Not Support Hard Disks Larger Than 32 GB
Microsoft's technical article that covers this information is: Q246818
The FAT32 file system included with Windows 95 (OSR2 and later) and Windows 98 supports
hard disks up to 2 terabytes in size and partitions up to 8 gigabytes or larger (depending
on the support of INT13 by the hardware in your particular system). However, it
would be a mistake to assume that FDISK gives the same support. Depending on where
and when you got that particular version of FDISK, support may be limited to disks of less
than 64 GB total size.
Babster: (August 27, 2002) There's a newer version of fdisk on the Microsoft web site
to address larger disk sizes..... See Q263044
- "Fdisk Does Not Recognize Full Size of Hard Disks Larger than 64 GB."
Alas, (Microsoft) doesn't just give you the new fdisk.exe (that would be too EASY).
It's an installation program that updates the existing FDISK on Windows 95/98. So
to get the new exe file, you need to have a computer with Win95 or Win98. (Read next
paragraphs.)
Janus (August 31, 2002): The version of FDISK that is included with Windows 95/98/98SE,
has a limitation; when partitioning disc drives with capacities greater than 68.7
Gigabytes (nominal 64 GB), it will incorrectly partition the disk. Using FDISK to
partition a typical 80 Gbyte disc drive, for instance, will result in the total capacity
being reported as 10.7 Gbytes instead of the true capacity. The size that FDISK
reports is the full size of the hard disk minus 64 GB. For example, if the physical
drive is 70.3 GB (75,484,122,112 bytes) in size, FDISK reports the drive as being 6.3 GB
(6,764,579,840 bytes) in size. This is a 16 bit math error. This can also
occur using a RAID host adapter that spans and combines the capacities of multiple hard
drives exceeding 68.7 Gbytes. FDISK will only report the difference between the
total capacity of the disc drive being partitioned and the limitation. This is not
an issue with the version of FDISK that is included with the Windows ME, NT or Windows
2000 operating systems. If you have a drive of that size or larger to FDISK, then
download Microsoft's updated FDISK utility (KB: Q263044).
The size of the replacement FDISK.EXE file is approximately 64K. The package that
installs this fix contains both Windows 98 and Windows 98 Second Edition versions of the
fix. The package automatically installs the correct version.
NtwrkLarry (August 28, 2002): Note that this version of FDISK has a 137 GB limit.
Bob (February 8, 2002): Information on FDISK /MBR (KB: Q69013).
Capacity Notes
The capacity of a hard disk reported in FDISK and by the controller (Particularly a
controller with its own BIOS -- SCSI) may appear to be less than the manufacturer's
advertised capacity. Manufacturers advertise the capacity of their hard drives based
on the following equation: 1 gigabyte = 1,000,000,000 bytes
The BIOS, FDISK, and the OS typically calculate the capacity of a hard drive based on
the following equation: 1 gigabyte = 1,073,741,824 bytes
The 73,741,824 byte difference for that size comparison becomes more pronounced as the
capacity of the drive increases.
If the raw capacity of the hard disk is 2,146,467,840 bytes, then the manufacturer will
advertise the drive as a 2.1 gigabyte drive (the raw capacity divided by 1,000,000,000).
However, both FDISK and the BIOS employed by the controller may report the drive as 1.99
gigabytes (the raw capacity divided by 1,073,741,824).
If the raw capacity of the hard disk is 9,088,229,376 bytes, the manufacturer will
advertise the drive as 9.1 gigabytes (the raw capacity divided by 1,000,000,000). However,
both FDISK and the BIOS of the SCSI controller will correctly report the drive as 8.4
gigabytes (the raw capacity divided by 1,073,741,824). |
Forums 
