Fixing messed EZbios overlay

[Zvi Netiv]

The following exchange took place through e-mail. I post it here, with Irwin's
permission, for the benefit of readers that may have a similar problem.

The problem: Partitions were lost in result of upgrading the EZbios overlay to
latest MaxBlast version. The installed OS is W2K.

Lastly, I cannot make a report for you with the
overlay. Remember, after I ran resqdisk /r/z, the
overlay is gone now. The ezbios does not initialize
and the machine boots directly to "error loading OS".

Reminding you of the sequence of events:
1. Everything working fine with ezbios overlay and
win2k and multiple logical partitions.
2. Booting from resqdisk working floppies, ran
resqdisk /b and resqdisk /b/z.

The backup of track 0 is just fine. We'll use it to restore the drive to its
pre-upgrade state.

3. Booting from maxblast floppy, upgraded overlay.
Also tried to backup MBR, which seems to not have
worked.
4. Rebooted, overlay OK, got into win2k, it complained
that ezbios was corrupted when trying to access
logical partitions.

For a good reason. The reinstallation of Ezbios with the latest MaxBlast was a
total disaster. Explained below.

5. Booting from resqdisk working floppy, ran resqdisk
/b/z. It asked if I wanted restore disk 1, I said yes.

From the drive assessment report, ResQdisk restored nothing.

6. Rebooted, overlay gone, everything gone. Boots
directly to "Error loading OS".

Cause is explained below.

So, I cannot give you the second report. I wonder what
would happen if I ran maxblast and had it reinstall
the ezbios MBR, assuming that the overlay is still out
there somewhere on track zero.

You will only cause more damage.

Though my impulsive
nature makes me want to just do it, I will wait for
your input.

This is standard practice how to convert a minor problem into real mess. ;-)

Also, if you think it wise, I can run a
track zero backup again, if that would help preserve
the current state.

No need to, I believe I got all the information I need. The following is the
ResQdisk /assess report that you sent, combined with info retrieved from the
track 0 backup file.

CHS address: Cyl 0 Head 0 Sector 1
*********************** Setup Diagnostics ***********************
* Disk Type: Maxtor 52049U4
* BIOS/CHS IDE/LBA data
* Number of Heads: 16 16
* Number of Cylinders: 1024 16383
* Sectors per Track: 63 63
* Disk Capacity in Mbytes: 504 19541
* IDE Access Time: 6 msec
* Total sectors on drive: 40020624
******* Use Space to toggle between IDE and Ext.BIOS mode *******
Disk 1, Master Partition Sector, F6 for Layout

The above is badly wrong. The header (that I trimmed) indicates that your BIOS
doesn't support extended Int13 and will only recognize drives with capacity of
up to 8 GB.

Note the translation parameters in the BIOS/CHS column: The drive is detected
as 63 heads, and capacity of 504 mbytes! A 19 GB drive should detect with your
old BIOS as 255 heads and 8 GB capacity (the limit of your BIOS). The above are
the result of erroneous settings when upgrading MaxBlast, and perpetuated now by
the current MBR, and the drive being set to "auto" in the BIOS.

CHS address: Cyl 0 Head 0 Sector 1
******************** Partition Table Layout *********************
*
* Partition Starting Ending Reserved Total
* Boot Type Head Cyl. Sec. Head Cyl. Sec. Sectors Sectors
* Yes 85 0 0 10 63 1021 63 9 4120695
* 0 0 0 0 0 0 0 0 0
* 0 0 0 0 0 0 0 0 0
* 0 0 0 0 0 0 0 0 0

The above is the partition table currently present in the MBR (from the "assess"
report).

Its errors are:

The start of the partition points to sector 0/0/10 (CHS) instead of 0/1/1. No
wonder that the BIOS can't find and load the OS.

The number of heads is 64, where it should be 255. This is what probably caused
the message about corrupted extended partitions.

The number of reserved sectors is 9, where it should be 63.

Lastly, the total number of sectors in the single partition left does not match
the true number in that partition, as seen below, it's almost twice that number!

CHS address: Cyl 0 Head 0 Sector 1
******************** Partition Table Layout *********************
*
* Partition Starting Ending Reserved Total
* Boot Type Head Cyl. Sec. Head Cyl. Sec. Sectors Sectors
* Yes 85 1 0 1 254 148 63 63 2393622
* 85 0 373 1 254 1023 63 5992245 34009605
* 85 0 149 1 254 372 63 2393685 3598560
* 0 0 0 0 0 0 0 0 0
*
******* Press Alt+B to see as boot sector, Alt+M to edit ********
Sector 1 of TRK0.NTZ (offset 0)

The above is the partition table from your TRK0.NTZ backup. It seems to be the
correct partition needed to boot the drive with the overlay.

CHS address: Cyl 0 Head 1 Sector 1
******************** Boot Sector Data FAT-32 ********************
*
* Sectors per Cluster: 8
* Number of Heads: 255
* Sectors in Partition: 2393622
* Sectors per FAT Copy: 2334
* Reserved Sectors: 33
* Capacity in Kilobytes: 1225534
*
********** Press Alt+P to analyze as partition sector ***********
Disk 1, Master Partition Sector, F6 for Layout

This is the boot sector found at 0/1/1, from the "assess" report. As you can
see, the total number of sectors and the number of heads, match those indicated
in the previous table. Which suggests that the boot sector is correct, and
intact.

Checking cylinder 2 for FAT pair
*****************************************************************
* Press Space to pause, Esc to stop searching
* --------------------------------------------------------------
* First FAT-32 copy starts on sector 96, Cyl 0
* Second FAT-32 copy starts on sector 2430, Cyl 2
* Sectors per FAT copy: 2334

Lastly, the above snapshot confirms that the FAT fits the boot sector data,
which means that they belong to each other.

To restore the EZbios overlay, and recover the partitions proceed as follows:

Make sure that the attributes of the TRK0.NTZ file are "hidden" and "read-only",
and nothing else ('archive' should be ticked off!) ResQdisk will consider alien
a backup file that doesn't have its attributes as indicated.

Boot the computer from floppy, to either FreeDOS, or plain DOS. If you can see
the message referring to the EZ overlay, then don't continue as the restoration
may fail.

When at the A: prompt, run RESQDISK /KILL, then reboot from floppy. Let the
BIOS autodetect the drive. Make sure that the drive is set in the BIOS as AUTO
and LBA mode. Autodetect should detect it as 255 heads and 8 GB capacity.

When at the A: prompt, after having rebooted, insert the RESQ floppy with the
original track 0 backup (the file that dates from 27 November). Start RESQDISK,
press ^Z and select "compare". ResQdisk should show which sectors differ from
the backup. There should be a few discrepancies from the backup.

Press ^Z again, then select "restore". After track zero is restored is
complete, run ^Z "compare" again and make sure no sector differs from the
backup.

Restart the PC from the hard drive and it should resume normal operation.

Lastly, may I suggest that if you plan keeping that motherboard (and BIOS), then
add an ATA controller card and convert the EZbios overlay to standard partition
types. ResQdisk will let convert the partitions without losing the data and
applications already on the drive.

Overlays and W2K are incompatible! The reason for which you could run W2K with
the overlay, and see the higher partitions, is because the boot partition in
your case is all contained in the first 8 GB. Once W2K is running, it installs
its own drive access driver, that doesn't depend on the BIOS. Just sheer luck!

Regards, Zvi

 

[Folkert Rienstra]

[big snip]

Overlays and W2K are incompatible! The reason for which you could
run W2K with the overlay, and see the higher partitions, is because
the boot partition in your case is all contained in the first 8 GB.

For an explanation to being incompatible, that doesn't make sense.
Being of no help is not being incompatible.

Once W2K is running, it installs its own drive access driver, that
doesn't depend on the BIOS.

Once again, that is saying that W2k doesn't need an overlay, not
that it is incompatible.

Just sheer luck!

Or design?

Btw, the overall impression that I get from what you write is that
W2k doesn't use the overlay at all, bootstage or running.

 

[Zvi Netiv]

For an explanation to being incompatible, that doesn't make sense.
Being of no help is not being incompatible.

My recollection is that "compatibility" is the term used somewhere in the
documentation of boot overlay. Call it what you like, as long as you understood
what I am saying.

Once again, that is saying that W2k doesn't need an overlay, not
that it is incompatible.

The difference is this: Win 9x/ME keep the modified (by the overlay) Int13
handler throughout the entire Windows session and use it for backward
compatibility (that unfortunate word again) with SW that needs it. While
NT/W2K/XP dump the modified handler altogether and use their own.

Or design?

Of what, W2K or of the overlay? IMO, neither.

Btw, the overall impression that I get from what you write is that
W2k doesn't use the overlay at all, bootstage or running.

W2K has no "say" at boot time as it isn't running yet. The BIOS and then the
overlay is what govern drive access until Windows loads its access drivers,
which is quite late down the sequence.

Regards, Zvi

 

[Folkert Rienstra]

My recollection is that "compatibility" is the term used somewhere in the
documentation of boot overlay.

Well, like I said, not helping/working is still 'compatible' (but of no use)
whereas making things worse would be incompatible.

Call it what you like, as long as you understood what I am saying

That's the problem, isn't it?
What exactly ARE you saying when you use the word 'incompatible'?

I think you just mean that it doesn't use it but then, why not just say so,
be clear about it.

The difference is this: Win 9x/ME keep the modified (by the overlay) Int13
handler throughout the entire Windows session and use it for backward

I think that even that is debatable but am not completely sure.
Windows can add it's own Int13 support to drives that don't have it.
Whether it still adds it's own when drives are already under Int13
control I'm not sure about. Bart's Disktool sure does display a dif-
ferent Int13ext version under Windows than it does under DOS.

compatibility (that unfortunate word again) with SW that needs it. While
NT/W2K/XP dump the modified handler altogether and use their own.

So? Once again confirming that W2k doesn't use an overlay.

Of what, W2K or of the overlay? IMO, neither.

In a way both, since the overlay depends on the MBR bootcode and
NT/W2k/XP writing their own, making the overlay essentially dead
code when so desired.

W2K has no "say" at boot time as it isn't running yet.

Essentially it does when that W2k MBR bootcode has been executed.

The BIOS

and then the overlay

Which isn't run, according to the tenor of your post:

" The reason for which you could run W2K with the overlay,
and see the higher partitions, is because the boot partition
in your case is all contained in the first 8 GB."

The same would have been true without that overlay.

is what govern drive access until Windows loads its access drivers,
which is quite late down the sequence.

In which case all should be well, if it actually was that way.
Which, apparently, it isn't.

 

[Zvi Netiv]

Well, like I said, not helping/working is still 'compatible' (but of no use)
whereas making things worse would be incompatible.

Trying W2K's FIXMBR on a drive that has an overlay, and the BIOS not being able
to access the boot partition without it, is one example that comes to mind.

That's the problem, isn't it?
What exactly ARE you saying when you use the word 'incompatible'?

Not compatible, naturally.

I think you just mean that it doesn't use it but then, why not just say so,
be clear about it.

Because this isn't what I meant, and because your statement is incorrect.

W2K doesn't *use* the overlay when running, yet it "needs" it to access its
startup files and report the disk parameters to the OS for the transition from
BIOS to the OS. Especially if the W2K files are beyond reach with an unassisted
BIOS.

I think that even that is debatable but am not completely sure.
Windows can add it's own Int13 support to drives that don't have it.
Whether it still adds it's own when drives are already under Int13
control I'm not sure about. Bart's Disktool sure does display a dif-
ferent Int13ext version under Windows than it does under DOS.


So? Once again confirming that W2k doesn't use an overlay.

Hey, that's my line! As I said, W2K doesn't use the overlay when running.
Which doesn't guarantee that W2K will successfully do the transition from the
overlay to its own disk access.

In a way both, since the overlay depends on the MBR bootcode and
NT/W2k/XP writing their own, making the overlay essentially dead
code when so desired.

W2K (as well as XP) and EZbios are incompatible as FIXMBR from the previous will
kill boot ability of the drive as the special MBR loader will be overwritten
with a standard partition loader (the cloaking of the overlay, which's purpose
is to self-protect the special MBR and the overlay from being overwritten, is
ineffective once W2K/XP is loaded). Whether the drive will boot after the
FixMBR treatment or not depends on whether the boot partition can be accessed by
the BIOS, unassisted.

Essentially it does when that W2k MBR bootcode has been executed.

The MBR loader code isn't OS specific and doesn't make part of the OS. W2K uses
the same partition loader as older OS. There are a few variants of that loader,
the one installed with W2K is the same one that was introduced with FAT-32 and
its major "improvement" is that it will use the mirror boot sector of a FAT-32
boot partition, in case the master BS is void. So far for a drive that doesn't
use an overlay.

If the drive uses an overlay, then the MBR bootcode is actually the *overlay
loader*. Which is why you should not run FDISK /MBR, or FIXMBR, on a drive that
has an overlay. The order of the boot sequence for an overlay drive, is: POST,
loading and execution of the MBR loader, loading and execution of the overlay,
loading and execution of the boot sector loader, and finally the loading of the
OS, starting with NTLDR in the case of NT/W2K and XP.

Which isn't run, according to the tenor of your post:

The MBR content is what governs the running of the overlay, and it precedes the
loading of the OS by two steps.

" The reason for which you could run W2K with the overlay,
and see the higher partitions, is because the boot partition
in your case is all contained in the first 8 GB."

The same would have been true without that overlay.

It depends on whether the OS start files can be accessed with the BIOS,
unassisted. It turns out that Irwin has such an old BIOS (AMIBIOS 1992!) that
allows access to just 504 MB without the overlay. The problem was further
complicated by an unfortunate upgrade of the overlay, followed by W2K messing
with the MBR when it first loaded after the upgrade (step 4 in the first post of
this thread).

In which case all should be well, if it actually was that way.
Which, apparently, it isn't.

No, it isn't.

Regards, Zvi