mirror of
https://github.com/oerg866/win98-quickinstall.git
synced 2026-04-25 21:15:52 +03:00
[GH-ISSUE #22] LBA Partitions get corrupt after 8GB storage used #19
Labels
No labels
bug
documentation
enhancement
help wanted
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/win98-quickinstall#19
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @orcutt989 on GitHub (Dec 13, 2024).
Original GitHub issue: https://github.com/oerg866/win98-quickinstall/issues/22
Using about 8GB of any (large) partition of a disk not partitioned with the bigger drive support FDISK makes the volume unbootable and corrupt. Happens on real hardware and 86 box.
See https://www.vogons.org/viewtopic.php?t=84036
Discovered in
https://github.com/86Box/86Box/issues/5044
Integrate newer FDISK into win98 instead of CFDISK
https://archive.org/details/windows-98-and-se-large-drive-fixes.-7z
@orcutt989 commented on GitHub (Dec 13, 2024):
I was not able to reproduce this on hardware so I am going back to the 86box team.
@oerg866 commented on GitHub (Dec 14, 2024):
Thanks for checking on real hardware. I agree 86box is flaky and I also made the mistake of taking errors it produced seriously before :D
@orcutt989 commented on GitHub (Dec 15, 2024):
@oerg866 We spent some time experimenting in that 86Box issue and I came to the conclusion it does have something to do with win98-quickinstall. OEM install works fine with 127GB disk on 86box, but something about windows98-quickinstall corrupts the volume after 8GB written.
@oerg866 commented on GitHub (Dec 15, 2024):
Well I'm not sure what to do with this if it doesn't happen on real
hardware...?
On Mon, Dec 16, 2024, 00:01 orcutt989 @.***> wrote:
@orcutt989 commented on GitHub (Dec 15, 2024):
Well by “real hardware” I just meant some random stuff I had setup. Nothing mimicking the motherboard used in 86box. If you look at the linked issue the 86box dev confirmed its an OS issue.
@OBattler commented on GitHub (Dec 16, 2024):
Hello, 86Box lead developer here,
I have indeed determined it to be caused by the OS - it wraps around at 8 GB back to 0, relative to the first sector of the partition, because the MBR is still there and hasn't been touched. If this was 86Box itself wrapping around, then it would be have wrapped around absolute 8 GB back to sector 0, which is the MBR, so the MBR would have also been overwritten.
In addition, the Vogons thread shows that it does occur on at least some real PC's as well, and I found a discussion on Reddit suggesting it may be a BIOS-specific issue. In any case, newer FDISK should probably be integrated.
@oerg866 commented on GitHub (Dec 16, 2024):
Hello,
I was able to reproduce with 86box and VirtualBox:
Will investigate later after work
It probably has nothing to do with QuickInstall itself but rather the patches used in the reference ISOs, namely the patches used to add LBA48 support. Since the author sadly passed away this will be a bit awkward to debug....
@OBattler commented on GitHub (Dec 16, 2024):
I suspect the drivers just assume the drive support 48-bit LBA without actually checking if it does, potentially causing misbehavior on drives that don't support it.
@oerg866 commented on GitHub (Dec 16, 2024):
Also regarding FDISK, the newest versions of FDISK and such are already integrated into the reference images
@orcutt989 commented on GitHub (Dec 16, 2024):
Yeah makes sense I think CFDISK is modern enough to handle it. I think @OBattler might be close. Perhaps the RLOEW LBA patch shouldnt be installed if the partition doesnt need it? Could you set up a conditional to skip it if the partition is not LBA 48?
Thanks @oerg866 for looking back into it.
@oerg866 commented on GitHub (Dec 16, 2024):
It turns out a belarusian user named SweetLow created a patch for R.Loew's ESDI_506.pdr that fixes exactly this problem. After putting it in place, I no longer get errors when writing obscene amounts of content to the drive. This will be fixed in the 0.9.6 reference images
@oerg866 commented on GitHub (Dec 16, 2024):
@orcutt989 commented on GitHub (Dec 16, 2024):
Amazing!
@orcutt989 commented on GitHub (Dec 17, 2024):
Why does this work fine on hardware with SATA hard drive and 0.9.5 windows quick install?
@OBattler commented on GitHub (Dec 17, 2024):
Your SATA hard drive more likely than not, supports 48-bit LBA, while 86Box does not and I have no idea about VirtualBox.
@OBattler commented on GitHub (Dec 17, 2024):
If what I read here is true: https://msfn.org/board/topic/186313-patches-for-esdi_506pdr-from-windows-98se-rloews-terabyte-plus-pack-21-and-more/ - then 86Box and VirtualBox somehow both report supporting 48-bit LBA even though they does not.
@OBattler commented on GitHub (Dec 17, 2024):
OK, I just check the 86Box code and we do not report 48-bit LBA as supported in IDENTIFY.
@OBattler commented on GitHub (Dec 17, 2024):
This is getting even more strange - none of the 48-bit LBA commands share their instructions with the 28-bit ones, so RLoew's patch must have a bug where it writes 48-bit LBA parameters even when using a 28-bit LBA command.
@oerg866 commented on GitHub (Dec 17, 2024):
Yes, that is also my understanding... Weird stuff.
@oerg866 commented on GitHub (Dec 23, 2024):
0.9.6 releases later today, which fixes this
@LordOfMice commented on GitHub (Mar 25, 2025):
RLoew's patch does not have any bug in this area. The bug is in hardware which reports LBA48 support in IDENTIFY DEVICE data but has some bug in handling real LBA48 commands.
But there is enough OTHER bugs (it is not the bugs on old hardware but turned to bugs on modern) in procedure of parameter harmonization of real mode Int 13h handler and ESDI_506.PDR
And yes, I recommend to take the newer version of ESDI_506.PDR as I incorporated other big fix recently (for old problem of RLoew's SATA Patch).
@OBattler commented on GitHub (Apr 6, 2025):
IDE devices on 86Box do not report LBA48 support in IDENTIF DEVICE, at all, so why does the patch still attempt to use 48-bit LBA commands? Furthermore, as I wrote above - 48-bit LBA commands have different opcodes from the 28-bit ones, the driver is sending the latter but writing 48-bit parameters. That does not work correctly on 86Box, whose drives are 28-bit only. If the driver was actually attempting to use 48-bit commands, all that would happen would be the emulated IDE drive aborting with error, not corrupting the data.
@LordOfMice commented on GitHub (Apr 7, 2025):
OBattler, tell me please:
@oerg866 commented on GitHub (Apr 7, 2025):
Hi, the old versions of the QuickInstall ISOs used the ESDI_506.PDR 24804 bytes (Sunday, 25 October 2015, 18:49:26 - Not sure if that is the original date) from the R. Loew 1TBPLUS package (attached)
ESDI_506.zip
The new fixed one uses your fixed ESDI_506.PDR (24430 bytes).
@LordOfMice commented on GitHub (Apr 7, 2025):
ESDI_506.PDR 24804 bytes (Sunday, 25 October 2015, 18:49:26 - Not sure if that is the original date)
A-ha, this is TBP3.0 version! 48-bit LBA + PARTIAL "SATA" Patch (unlike TBP2.1 with FULL "SATA" Patch).
Very dangerous version on modern systems as it has unstable behaviour.
Look to my first post where is the REAL problem of this version.
And there is more complete description (use translator):
https://forum.ru-board.com/topic.cgi?forum=62&topic=31624&start=540#17
Partially note the decsription of cases of wrong detection of LBA & CHS using...
@oerg866 commented on GitHub (Apr 7, 2025):
Ahhhhh that explains a lot of weird things now. Thank you! 😄
@LordOfMice commented on GitHub (Apr 8, 2025):
Note that I did all planned (on the date of above mentioned post) enhancements already (and some other too) and I hope that is ENOUGH.
@OBattler commented on GitHub (Apr 19, 2025):
I don't think I do any sanity checks on the cylinder other than erroring out of (C * H * S) is above the last sector of the disk. Otherwise, I treat the cylinder as a standard unsigned 16-bit integer.
Now, from what I recall with the specific problem reported here, as I posted above:
8 GB means sector 16777216, this kind of wraparound indicates it's writing the lower 24 bits of LBA correctly (or perhaps even they get overwritten) but then fails to write the upper 4 bits - the only way I can imagine this happening is the driver attempting to use 48-bit LBA with 28-bit read/write commands.
Now the the CHS - 86Box itself, as I said above, in the code, supports a maximum cylinder of 65535. This means it supports a maximum of 65536 * 16 * 256 sectors = 128 MiB, which corresponds to the 28-bit LBA upper limit.
@LordOfMice commented on GitHub (Apr 19, 2025):
Ok, I can say more with internal driver state dumps.
oerg866, can you reproduce error configuration now (with esdi_506.pdr from TBP3.0)?
If so:
http://sweetlow.orgfree.com/download/esdi_506_dump.zip
run go_rl.bat and send me results.
P.S. And results of
http://sweetlow.orgfree.com/download/hdsize.zip -> DUMP_TO.BAT
from DOS (Command Prompt in boot menu) and Windows too.
"8 GB" means 16383:16:63 too if you will calculate as we do not know EXACT wrap-around value,
256 sectors per track config is not usual. 63 SPT and 32GiB limit for CHS are more common values. But yes, 32 GiB are NOT 8 GiB.
@OBattler commented on GitHub (Apr 21, 2025):
We know the exact wrap-around value, it's at sector (16777216 + offset of the first partition), per my analysis of the corrupted hard disk image file, so exactly 8 GiB into the partition, it wraps aroud back to the beginning of the partition. This can only happen if the upper 4 bits of the LBA are never written.
@LordOfMice commented on GitHub (Apr 21, 2025):
what? there is no parttitions on the level of port drivers...
@OBattler commented on GitHub (Apr 21, 2025):
My analysis of the corrupted hard disk image doesn't lie - the MBR is completely untouched, the overwrite starts at the first sector of the partition.
@OBattler commented on GitHub (Apr 21, 2025):
And noone is saying there are - the wraparound occurs when Windows is attempting to access sector (first sector of the partition + 16777216) but, for whatever reason, does not write the upper 4 bits of the LBA address, causing the very beginning of the partition to be written to instead.
Basically, let's assume the partition begins at 0x00000500. Windows then tries to access sector 0x01000500, but fails to write the upper 4 bits of LBA, accessing sector 0x00000500 instead, corrupting the very beginning of the partition instead.
If there's another partition sat, say, 0x00e00500, same thing but worse - it would end up corrupting the very beginning of the first partition while attempting to write to a sector on the second partition. Because the partition itself doesn't matter - it's a LBA wraparound caused by the upper 4 bits not being written for whatever reason.
@LordOfMice commented on GitHub (Apr 21, 2025):
BEFORE this Windows had to access 0x1000000...
@oerg866 commented on GitHub (Apr 21, 2025):
Hello, im sorry I am too busy at the moment but in 0.9.6 for sure the bug
is gone because it uses SweetLow's patched files and I could not reproduce
the problem there anymore :)
On Mon, Apr 21, 2025, 14:46 SweetLow @.***> wrote:
@OBattler commented on GitHub (Apr 21, 2025):
Yes, now that you point this out, it's indeed puzzling why that doesn't wrap around.
Now if this is any indication: https://www.vogons.org/viewtopic.php?t=84036 - this may not even be caused by the patch (or may be an existing problem simply exacerbated by the patch), and maybe Windows itself wrapping around somewhere, before adding the first sector of the partition to it. That would explain why it does not already wrap around from 0x01000000 to 0x00000000.
At this point, I have no idea what exactly is going on, anymore.
@LordOfMice commented on GitHub (Apr 21, 2025):
As I said - try to take TBP3.0 ESDI_506.PDR instead of my version (and copy it to %windir%\SYSTEM\IOSUBSYS)
We're in no hurry ;)
That's why I want to insulate it consistently. But it has to be reproduced for the first step, of course.
@oerg866 commented on GitHub (Apr 21, 2025):
Ahhh, I understand now. Will do tomorrow or wednesday
@LordOfMice commented on GitHub (Feb 24, 2026):
@OBattler insulation procedures done.
Two pretty severe bugs (data corruption in some cases) in VirtualBox ATA emulation found:
The source of this Issue:
Non zero value in ATA Control register (8 (bit 3 is set) to be precise in case of ESDI_506.PDR).
That probably breaks emulation code of 48-bit LBA commands and it treats transaction not as one 48-bit but as two 24-bit.
ATA IDENTIFY DEVICE bug:
Model : VBOX HARDDISK
Revision: 1.0
ATA [Command Set] Version: 6 (ATA/ATAPI-6)
Subversion: 0022h
LBA48 Sectors: 336489216
LBA Sectors: 268435455
Logical Cylinders: 16383
Logical Heads: 16
Logical Sectors Per Track: 63
Sectors: 16514064
Current Logical Cylinders: 16383
Current Logical Heads: 15
Current Logical Sectors Per Track: 63
Current Sectors: 15481935
Current logical heads value is wrong here with high probability as BIOS reports 16 heads in Int 13h handler and in FDPT:
Drive #128 (80h)
Debug -> Extension Check...
Int 13 Extension Supported. Version = 30h (3.0)
InterfaceSupported = 0000000000000111b
Extended disk access subset is supported(0)
Removable drive control subset is supported(1)
Enhanced disk drive (EDD) subset is supported(2)
Debug -> Extension Parameters Check...
Debug -> ExtInfo.info_size on return = 26
Flags Value IMLCVRTD
Ext_Flags = 0000000000000010
(D)DMA boundary errors may occur
(T)Valid CHS info
(V)Drive NOT supports write with verify
(R)Drive is fixed(NOT removable)
Cylinders: 16383
Heads: 16
Sectors: 63
Sector Size: 512
Total Sectors Bytes MiB GiB TiB
336489216 172282478592 164301.38 160.5 0.2
=== INT 46h ===
Addr[0]: 020B:004D - Int 13h Drive 81h (Primary Slave)
Apparent Cylinders: 1024 (0400h)
Apparent Heads: 255 (FFh)
Apparent Sectors: 63 (3Fh)
Actual Cylinders: 16383 (3FFFh)
Actual Heads: 16 (10h)
Actual Sectors: 63 (3Fh)