Bizarre Windows 98 setup bug, refusing to continue on "please remove any floppy disks from your system", issue resolved, just sharing my experience.

[173a]

I was able to resolve this issue just as I was about to turn to this community for help, so I've decided to create this topic still, just to share my experience (as I've received good assistance from people here in the past) and hopefully help someone having similar woes, as I haven't been able to google a solution for this one.

System:

Celeron 331 (Prescott 2.66Ghz, 256kb L2 cache, LGA775)

MSI PM8PM-V (2.0 PCB revision) (VIA P4M800-Pro), 3.3 BIOS

512Mb DDR2 533Mhz

Radeon 9600 Pro 128Mb

SBLive! SB0100

PATA CD-ROM

SATA 80Gb Seagate HDD (runs in bios "RAID" mode, as the "IDE" seems to install Windows 98, but hangs on boot on attemting to load msmouse.vxd driver, another bizarre bug. Could be of help to someone, as the msmouse.vxd Windows 98 startup freeze topics seemed pretty common and hard to diagnose in the past)

Floppy controller - disabled in the bios

Original OEM bootable Windows 98 CD, reliable, used many times before.

 

Issue:

First of all, just to get this out of the way. I know for a fact that this board makes for a stable and usable Windows 98 system, as I've successfully used it as such for months in the past and have also assembled one exactly like this (except for a Geforce FX5200 for the video) for another person about half a year ago.

Events as they developed: I successfully installed Windows 98 using all of the hardware and the CD mentioned above, VIA 5.24 mobo driver, Catalyst 5.2, SBLive drivers and so on. Ran some benchmarks, played some games, everything working. I also installed the unofficial NUSB3.64 usb driver, a bit later, somewhat foolishly, while checking device manager for any yellow devices, I've noticed that the VIA PCI USB something device had no driver and so I haplessly selected something something with "VIA USB" in it from the presented driver list, silly mistake (NUSB is the only driver required AFAIK), the computer restarted but would not boot with a black screen instead of the Windows 98 bootup animation. The next day I decided to reinstall the whole thing anew, so I boot into DOS, fdisk, delete primary dos partition (no partitions present when selecting to view partition info after), let Windows 98 slow format the drive and just before the "enumerating devices" step begins I am presented with a message against a black screen "please remove any floppy disks from your system" and "press any button to restart", which I do, but the cycle repeats itself. I then tried removing the HDD from the system and deleting all partitions using the DiskGenius software with the HDD in a USB 3.0 caddy on a Windows 7 computer. With the HDD back in the target machine, the issue repeats itself after another round of Windows 98 FAT32 formatting. Removed the eeprom battery, let the computer sit for ~15 minutes, reconfigured the BIOS again, FDD still disabled, issue persists. What resolved it was using the "clean" from diskpart in Windows 7 with the target HDD in the usb caddy, after which the install process ran as expected. Never had this happen before, very strange bug, seems like something was left over on the HDD even after deleting all the partitions (using at least 2 different tools) and causing this situation.

 

Edited April 26, 2023 by 173a

[jaclaz]

What you report is very strange, as you say bizarre.

On a "normal" disk once you re-format the partition(s), even as a quick format, nothing (accessible) remains on the partition(s) themselves, i.e. while the data is still there the newly created FAT tables make the data non accessible at a logical level.

Fdisk deletes the partition table and should (but it would need to be confirmed) re-write also the MBR code (and possibly also 00 out the DIsk Signature, but in any case the Disk Signature is not used on non NT systems).

So the only thing that remains are the so-called hidden sectors (typically sectors LBA 1-62) but those should not be accessed at all during install or normal operation.

The diskpart clean should clean also those hidden sectors, so it is possible that this was the difference, still it is strange that those sectors were accessed/checked at all.

Maybe it was just voodoo (sometimes it just happens).

Happy you managed to solve the issue and thanks for reporting. maybe (hopefully) it will never happen again, but if it does, someone may be able to find this and solve the issue as well.

jaclaz

[173a]

I'm not a computer scientist or even an advanced user, just like older hardware and playing some games, and I don't even have a single floppy disk at home at the moment, but I know when something starts to act strange when it never has done before. I suppose I should also mention that in between all these things that I relate in the OP, what I also did was disconnect the SATA HDD and move over about 50GBs of game ISOs onto the drive from the Windows 7 computer, since the NUSB doesn't work too well with VIA chipsets and USB flash drives (runs slow, in my experience at least, but has no problem with Intel chipsets), but I always do this with a SATA drive and have done this many times before and never experienced something as strange as the past couple of days.

Edited April 26, 2023 by 173a

[SweetLow]

19 hours ago, jaclaz said:

in any case the Disk Signature is not used on non NT systems

In some cases it is definitely used even on 9x. Not directly but in checksum of zero (MBR) sector.

[jaclaz]

2 minutes ago, SweetLow said:

In some cases it is definitely used even on 9x. Not directly but in checksum of zero (MBR) sector.

Maybe.

But during setup?

Can you detail which cases?

AFAIK (in it's time) there have been countless dual and triple boot installs with 98 and 2K or XP, and the presence of a non 00 disk signature never created an install issue for Windows 98 (that I can remember), and more often than not these installs (and re-installs) were rarely performed on a wiped disk.

In 9x/Me there are the "mistery bytes" but they are in a different position than the disk signature and they only come into play if there is a collision with another disk:

https://thestarman.pcministry.com/asm/mbr/mystery.htm

and in any case fdisk should well be able to take care of them.

jaclaz

 

[SweetLow]

>https://thestarman.pcministry.com/asm/mbr/mystery.htm

>but one of our readers finally pointed out that Microsoft did provide a "partial description of the meaning [of these bytes] in KB article 192606 (or the file: MBtFAQ)."

JFYI, I am this reader

And I know slightly more, of course - the real IOS structure that used for passing these values (signatures and checksums).

 

>Can you detail which cases?

Excerpt from your link:

>or the first word after the boot code is non-zero, IOS will instead store a checksum of the MBR and the INT 13h unit number, rather than the MBR signature.

And as checksum include NT Disk Signature too -> we have unique value of this checksum.

 

>But during setup?

I don't see how this can affect setup too (as you), but NT Disk Signature has some impact on Windows 9x.

 

P.S. And what it looks like in reality (with MBR code from NT):

int13 = 80h, signature = E6FFB000h, checksum = F601BDECh, flags = 0001h
int13 = 81h, signature = E6FFB000h, checksum = BDE79504h, flags = 0001h
int13 = 82h, signature = E6FFB000h, checksum = E6233B84h, flags = 0001h

Win9x signatures are equal, but checksums are different (and IOS is using checksums (flags = 0001h))

 

Edited April 27, 2023 by SweetLow

[jaclaz]

21 minutes ago, SweetLow said:

I don't see how this can affect setup too (as you), but NT Disk Signature has some impact on Windows 9x.

 

But not during setup, so in this case it remains more probable voodoo or the full moon at install time (if it was wednesday).

jaclaz

[awkduck]

6 hours ago, jaclaz said:

But not during setup, so in this case it remains more probable voodoo or the full moon at install time (if it was wednesday).

Yeah, sometimes the machine just doesn't want to be your friend.

After reading the indecent description, I wondered if the "so I boot into DOS, fdisk, delete primary dos partition" was done from the hard disk dos, or Cdrom/Floppy/USB. Not that it would probably made a difference; I'm just trying to pick at something. I don't recall ever using the installed FDISK, to erase itself. 173a might have been using portable boot media, as I always have.

[jaclaz]

Sure, it must have been done *not from the internal disk*, but the questions (unanswered) are more about what does fdisk actually do and whether a fdisk /MBR would have helped (or not).

The generic (by me) suggestion to wipe the first 100 sectors of an hard disk when making a new install/partitioning would likely have avoided the problem, but the curiosity remains about what remained on disk that caused the issue and that diskpart clean removed.

jaclaz

[173a]

14 hours ago, awkduck said:

Yeah, sometimes the machine just doesn't want to be your friend.

After reading the indecent description, I wondered if the "so I boot into DOS, fdisk, delete primary dos partition" was done from the hard disk dos, or Cdrom/Floppy/USB. Not that it would probably made a difference; I'm just trying to pick at something. I don't recall ever using the installed FDISK, to erase itself. 173a might have been using portable boot media, as I always have.

Naturally it was done from the CD:

Boot from cd-rom

Start the computer without cd-rom support

A:/fdisk

And it could see and delete the partitions and later run the setup and format the drive, it's just that that floppy remove prompt would come up, diskpart is the best then.