Windows 98 Assigns Drive Letters to Same Partitions Twice

[sburtchin]

I restored a Ghost image of Windows 98 to a primary partition on the second hard drive. It boots OK using GRUB and everything appears to be functional, except that all the logical partitions are getting two drive letters assigned to each one. Here's the relavent partition info:

First disk:
All primaries hidden except
1 Extended (type "0F") consisting of
---some NTFS partitions
---a FAT32 partition
---a FAT12 partition (the last logical)

Second disk:
All primaries hidden except
Windows 98 on FAT32 at cylinder 12814 type "0C"
1 Extended (type "0F") consisting of
---some NTFS partitions
---some hidden FAT16/FAT32 partitions
---7 FAT16/FAT32 partitions plus
---a FAT32 partition (the last logical)

The relevant GRUB commands are (with explanations):
rootnoverify (hd1,3) - sets the focus to the partition containing Windows 98
makeactive - sets the 'active' flag for this partition
map (hd0) (hd1) - swaps HDD's in BIOS
map (hd1) (hd0) - swaps HDD's in BIOS
chainloader +1 - loads the boot sector into RAM

What's happening:
The drives get switched in BIOS (this is somewhat of an assumption),
Windows boots and assigns letters to the first primary on each drive (only one - C: ),
then it assigns drive letters to all the logical partitions on both disks (D: thru M: ),
then somehow the drives get switched again,
then the two (visible) logicals on the first disk get assigned (N: and O: ),
then the first 7 (visible) logicals on the second disk get assigned (P: thru V: ),
***the last logical on the second disk does not get a letter***
then the CD, ZIP drive and external HDD get letters (W: thru Y: ).

The drives D: thru M: are not accessible. I've tried various combinations of visible and hidden partitions. The number of inaccessible drives is always equal to the number of visible logical partitions. All the accessible drives look normal in Windows Explorer.

Questions:confused::
Has anybody here seen this problem?
Is there any way to fix?
Is this a problem booting Win9x on a second HDD using BiNG, XOSL, others?

Thanks in advance for any help anyone can give on this.

[mjc]

You are coming up with some very interesting and rather unique problems...I haven't heard of this happening before. Maybe Paul will have some ideas, 'cause I don't.

[Paul Komski]

You can use BiNG and SBM (and XOSL if memory serves) to boot a primary on the second HDD but the swap option must be set. I cant see how GRUB would be at the root of this but the conversation between the BIOS and the boot managment must somehow be going astray. The fact that you cannott access the partitions up to M implies they have not been correctly allocated by the BIOS (ie the shadow RAM may be incorrect) and are just ghost entries that Windows tries to make some sense of.

If you swap HD0 and HD1 so that you are booting from the first hard drive then it might add to the knowledge base to know whether the duplication persists with the same or a different boot manager.

(BTW note that the swap option varies in its effects from BIOS to BIOS).

I have seen drive duplication under NT oses but that is a "simple" duplication of the mounted devices in the registry and would not expect to see it under a DOS based OS due to the dynamic assignment of drive letters.

P.S. If you have them, does WinHex or PM from within Windows also see the duplication or report any errors; (noting that PM's errors are not always real errors).

PartInfo from symantec or terabyteunlimited might help make sense of your very elaborate partition arrangements.

[sburtchin]

Fixed:D. I think I've read about everything out there about booting Windows on a second hard disk, but the fix goes contrary to all of it. All the sources seem to agree that it can't be done, or to do it you have to fool Windows into thinking it is being booted from the first disk. Not true! Just changing the "Drive ID" in the boot sector from 80h to 81h did it. Windows knows it's being booted from the second disk. It will only boots this way if I don't swap the drives. Also, it assigns letters to the logicals on the first disk before assigning the logicals on the second disk. I remember reading one source saying that the "Drive ID" should always be 80h because DOS/Windows cannot be booted unless they think they are on the first disk.

Still I want to understand what went wrong in the first situation. It is easy to recreate, so I will see what WinHex (evaluation version) sees and post back.

I know the same partitions are being looked at twice because the number of ghost drives is always equal to the number of visible logical partitions.

How intrusive is it to install BiNG or XOSL? Can I uninstall just by restoring track 0? I thought XOSL wanted it's own partition - not sure about BiNG. Also, I have been running GRUB from a floppy. I don't know if running it from the MBR vs. floppy would have any relevance to this.

[Paul Komski]

Both BiNG and XOSL write their own bootstrap code to the mbr and also need to have (hidden) files on a specified partition. BiNG also writes more code to an Extended or EMBR - which is just more code written to some of the sectors on Track0. Running fixmbr or fdisk /mbr will remove the boot code from both of them and the residual code from BiNG on the EMBR shouldnt interfere with anything but would be recognised at a later stage if you wanted to reactivate BiNG by booting to its boot CD or Floppy.

SBM can be installed onto a floppy and therefore not, in that case, change anything on the hard drive.

A backup of the mbr (or track0 if you want to) would retain the original signature and partition tables so it is always a useful thing to have in the background when doing such work as yours.

Using the swap option does, I believe, just what you have done manually and changes the ID from 80 to 81 effectively for that particular boot-up.

You can also easily uninstall BiNG by booting to the floppy or cd or by changing the settings under maintenance.

[sburtchin]

Changed drive ID back to 80h and GRUB booted with drives remapped (won't boot otherwise). Letters assigned exactly as before. With WinHex "Tools -> Open Disk . . ." all letters are available, including the phantom ones (eg. "Fixed Drive: D:"). The others are listed with their volume names as shown in Windows Explorer. Cannot open the phantom ones - I get:

Error #10
Cannot Access "Drive D:"

I can open the ones that Windows Explorer allows me access to.

If I open "Physical Disk 0" it opens the real physical disk 1 and vice-versa. All partitions are shown and available when opening the physical media.

PTEDIT also sees the disks as being switched. Setting drive ID to 81h it is back to normal and boots only if drives are NOT switched.

--------------------------------------------------------------------------

The first partition on HD0 is 251MB FAT16 starting at cylinder 0 head 1 sector 1. This has DOS 7.10 operating system, utility progs, backups of all MBR's/EPT's/BS's, my system log, the GRUB program files in "\boot\grub\", and the Windows 2000 Recovery Console files in "\cmdcons\" (it has an NT boot sector and uses BOOT.INI to select between the two). Real important stuff, so I do frequent image AND file backups of this partition to the external HDD. Can I put the BiNG and XOSL files here without disrupting things?

Would BiNG or XOSL change the disk signature? If I were to boot Windows 2000 with a different signature, this would wreak havok with drive letter assignments. I think I read that "FDISK /MBR" in some versions of DOS can be used as a quick method for changing the signature.

[sburtchin]

Here it is: (http://www.goodells.net/multiboot/partsigs.htm)The Win98 "fdisk /mbr" command is similar to the 2000/XP "fixmbr" command (used from the 2000/XP recovery console). The intended purpose of both commands is to restore the MBR boot code, and both commands replace the boot code but do not alter the partition table at the end of the master boot sector. The two commands are not exactly identical, however. As detailed by Michal Kawecki, the NT/2000/XP boot code is 440 bytes, while the Win98 boot code is 446 bytes (271 bytes of executable code, 80 bytes in error messages, and 95 bytes filled with zeroes). The NT/2000/XP "fixmbr" command replaces the MBR boot code but stops short of overwriting the four bytes of the DiskID that sits between the boot code and the partition table. The Win98 "fdisk /mbr" command will replace the boot code and zero the DiskID--albeit, unintentionally. As Kawecki points out, we can take advantage of that "mistake" because it has the effect of invalidating the partition signatures--since the signature is derived from the DiskID and Windows has to regenerate a new DiskID, it has to recalculate the signatures and assign new drive letters, abandoning any previous assignments.

[jlreich]

This may apply to your situation, but I thought I would mention it just in case.

I have had similar ghost drives before. It happens when I have a flash drive in the system when going into BiNG's partition work. It shows duplicate partitions and sometimes screws up booting. If I don't go into partition work everything is fine. With regular external USB drives it's fine.

Sometimes the fix was simply rebooting without the flash drive in place. Other times I had to reset to BIOS defaults. Now I just try not to go into partition work with a flash drive plugged in.

I don't think the fault is with BiNG, but rather my motherboards inability to deal with the flash drive correctly.

[Paul Komski]

It happens when I have a flash drive in the system
Lots of systems "go funny" when booting up with a flash drive attached including booting the wrong partition or not booting up at all.