WinSetupfromUSB: problem installing XP on legacy system

[mattrix]

Trying to install 32bit XP using WinSetupfromUSB.

The system will boot the USB as a USB-ZIP but WinSetupfromUSB won't get past the "start part 1 menu" so I have installed plop into the MBR on the HDD, and find the USB using UHCI on Host4, Port1.  HDD is SATA but bios emulates it as IDE, I don't seem to have any control over this.

WinSetupfromUSB freezes after shifthd.bat.  

Before shifthd.bat (hd0) 0x80 is the USB, (hd1) 0x81 is the HDD, but after shifthd.bat (hd0) is still the USB and (hd1) seems to be no longer mapped.

I'm still trying to learn grub4dos, but got the above information by adding geometry commands to winsetup.lst.

On screen dialog:

• starting setup part 1
• error occurred while savedefault
• 0x80: .... USB
• 0x81: .... HDD
• It seems plop has been loaded
• found 2 disks, set USB hd1
• 0x80: ... USB
• freezes

I'm at a loss what to do now, any help appreciated.

 

P.S. there is an 8MB block at the start of the USB, is this normal?

Edited November 28, 2020 by mattrix

[jaclaz]

The IDE/SATA is irrelevant as long as the disk is accessible by BIOS.

As well usage of plop should be "transparent", though there may be something connected to the exact way the "ZIP" disk is made, there are two types of original ZIP disk formats:
1) partitioned, where there is a single, active partition on slot #3 of partition table
2) non-partitioned, aka "superfloppy"

additionally (original) ZIP disks have a particular geometry (64/32 if i recall correctly), the actual motherboard BIOS may require this or that format or possibly plop is more permissive 

It is possible that shiftd.bat is tricked by some of these particular settings (if any).

Let's first see how your USB stick is partitioned.

You could use my little script, MBRview.g4b, but it is on reboot.pro (which is currently offline), I am attaching a copy.

Alternatively, in grub4dos it would be enough to issue:

cat --hex --skip=446 (hd0)0+1

and

cat --hex --skip=446 (hd1)0+1 

and report.

it is possible that some changes are needed in shiftd.bat or that its execution can be bypassed and disk (re-)mapping can be done manually instead.

Do post the contents of the shiftd.bat and of the menu.lst you are using now, as I seem to remember that there are various version of them, so we are sure we are using the same data.

jaclaz

mbrview-no-wenv.zip

Edited November 28, 2020 by jaclaz

[mattrix]

Hello @jaclaz,

Your script reports only partition 0 is used and it is bootable, type 0c . It was formatted using FBinst.

chs: 1/1/1 to 972/240/36  lba 16128 to 15614208

Thank you for looking at this

matt

menu.lst winsetup.lst shifthd.bat

Edited November 28, 2020 by mattrix

[jaclaz]

Yep, those are "queer" data,

The 1/1/1 to be corresponding to 16128 implies a 255/63 geometry.

The 972/240/36 is then not on a cylinder boundary, but neither justifies the issue.

BUT, re-reading your post, you are using PloP installed on the internal hard disk, while - if I remember correctly - the shiftd.bat is written assuming that the PloP is loaded by itself (or however from the USB) and anyway PloP support is "ecperimental".

Try NOT using the Winsetup.lst.

The first part of setup entry in winsetup.lst, simplified (as you do not need the DPMS.iso) amounts to a few commands, in the case of a "normal" setup with an USB stick and a single internal hard disk:

geometry (hd0)
geometry (hd1)

map (hd0) (hd1)
map (hd1) (hd0)

map --hook
 

geometry (hd0)
geometry (hd1)

find --set-root /WINSETUP/XPpSP3.ISO

map -mem /WINSETUP/XPpSP3.ISO (0xff)

map --hook

root (0xff)

chainloader /I386/SETUPLDR.BIN

boot

Then - if first part works - second part might be:

geometry (hd0)
geometry (hd1)

map (hd0) (hd1)
map (hd1) (hd0)

map --hook
 

geometry (hd0)
geometry (hd1)

root (hd0,0)
chainloader +1
boot

 

The geometry commands are there only to check the hard disk order before and after the attempt to remap them.

jaclaz

 

[mattrix]

Yeah, geometry shows USB as 973/255/63.

Without plop in the MBR the system doesn't treat the USB as a disk.

I typed in the commands and it freezes after the first "map --hook"

It gives a prompt but takes no more input.

matt

Edit: plop sees the USB using EHCI but can not work it out and boot it.

Edited November 28, 2020 by mattrix
more info

[jaclaz]

41 minutes ago, mattrix said:

Yeah, geometry shows USB as 973/255/63.

Without plop in the MBR the system doesn't treat the USB as a disk.

I typed in the commands and it freezes after the first "map --hook"

It gives a prompt but takes no more input.

matt

Hmmm.

But can it boot from the USB (as ZIP)?

(I mean, no matter how the BIOS sees the USB, as long as it can see it and load *somehow* the grub4dos on it, we can try remapping it in grub4dos), I strongly suspect that the PloP is the issue.

Alternatively, if the issue is the USB current partitioning/format we can try re-partitioning it in such a way that the BIOS sees it as ZIP and can boot it.

What happens if you "move" the partition entry to 4th slot?

jaclaz

 

Edited November 28, 2020 by jaclaz

[mattrix]

@jaclaz, our edits crossed.

Without plop the system will only boot the USB from the boot menu (F12) but geometry doesn't see it.

middle of the night here, I'll find my disk editor and move it in the morning.

matt

 

[jaclaz]

But you get to grub4dos (on the USB)?

If yes, it must be mapped to *something* (maybe (fd0) or (fd1), and then you can remap it to a hard disk) and you can also try the internal (to grub4dos) USB stack. (You may need to update grub4dos to a more recent version).

http://reboot.pro/topic/19883-improve-grub4dos-boot-speeds-by-using-the-046-usb-driver/

Cannot say if it may detect the USB stick in your case.

But there was at least one case where *something* was seen as floppy and it could be remapped to a hard disk device (the thread is unrelated, but the actual remapping is relevant):

http://reboot.pro/topic/20907-how-to-boot-windows-installerwtg-through-bios-off-gpt-partitioned-removable-usb-drive/page-3#entry208685

 

jaclaz

[mattrix]

@jaclaz,

Thank you,

You were absolutely correct. The USB was seen as a floppy.

After adding map (hd1) to (fd0), I was able to start the setup. However at "starting windows" I get a stop: 7B.

After searching, the recommended solution is a modified ntdetect.com,  which I got from here. I have put it in the root of the USB (or should I put it somewhere else?) but I'm not sure  how to restart the install.

matt

 

 

Edited November 29, 2020 by mattrix

[jaclaz]

You mean mapping (fd0) to (hd1), I believe?

4 hours ago, mattrix said:

@jaclaz,

After searching, the recommended solution is a modified ntdetect.com,  which I got from here. I have put it in the root of the USB (or should I put it somewhere else?) but I'm not sure  how to restart the install.

Yep that goes into the root of the USB stick, but maybe it needs to be changed also in \I386\ folder of the .iso , it has to be seen, your is an "unusual" setup. 

The general idea (of the simplified setup) is to have the internal hard disk mapped to (hd0) and the USB stick mappped to (hd1), so:

map (fd0) (hd1)
map --hook

geometry (hd0)
geometry (hd1)

find --set-root /WINSETUP/XPpSP3.ISO
map -mem /WINSETUP/XPpSP3.ISO (0xff)
map --hook
root (0xff)
chainloader /I386/SETUPLDR.BIN

boot

jaclaz

[mattrix]

Thanks.

That started again from the beginning, I thought I may have been able to continue from where I left off.

Had I finished with the mem disk at the point I ended?

I'm concerned the computer may not see the USB at the same place when I get there again.

Still its started the install again, and we will see when it gets there.

matt

[mattrix]

No didn't fix the problem.

I had to walk away from the computer, so I didn't see where it occurred, but it was the same message.

Any ideas what to do now?

[jaclaz]

Maybe in this case you need then to "abandon" WinsetupFromUSB and use another approach.

Two (please read as three, which means four, actually five) available:
1) offline installation (using WINNT32.EXE on the disk temporarily connected to another computer)
2) good ol' DOS method with WINNT.EXE
3) "plain" install (again using WINNT32.exe) from a PE booted from the stick (if it can be booted, but I don't see why it shouldn't, at the mot using grub4dos to remap disks)
4 and 5) one of the two available "direct from iso with grub4dos"  (memory or directly mapped, this, as well as the above may depend on amount of RAM available)

I guess we already had this conversation:

You have pesky hardware/BIOS, so any of the above may need corrections/adaptations, the "safer" (in the sense of having more chances of success) are #1, #2 and #3 as the installation happens without the USB stick involved in the process (if not as source).

On the other hand, now that you are getting more familiar with grub4dos, you can probably try the one (or the other) "install from iso with gtub4dos"  methods, in your paticular case it is a hit-and-miss game, no certain outcome.

jaclaz

[mattrix]

15 hours ago, jaclaz said:

Maybe in this case you need then to "abandon" WinsetupFromUSB and use another approach.

Agreed.

Part of the problem for me is that I have never seen the process complete successfully, so I don't recognize when things are odd. I did notice that when I chainloaded setupldr.bin grub reported that it would use NTLDR?   WinSetupfromUSB does a lot of poking around in various files when it makes the USB so I don't know when things are being directed by it, or some other program.

Another problem is that I don't know when things become 'case' sensitive. I have seen with some driver packs that setupORG.exe needs to be copied but windows install wants to execute setuporg.exe. Some program usually fixes this up, but not if the install goes awry. 

15 hours ago, jaclaz said:

I guess we already had this conversation:

Yes we have.
I still have a few questions, but since they are no longer about WinSetupfromUSB do you mind if we continue in the other thread?
 

matt

 

Bonus: I'm much more comfortable with grub4dos, so that's a win.

Edited November 30, 2020 by mattrix

[jaclaz]

Yep, as always happens to "evolved" projects, WinSetupFromUSB has accumulated over the years layers and layers of "crust", to the point that the "core" has been "lost" or however is extremely well hidden.

Little by little complications have been added to cover "particular" cases that came out in the experiments (like multi-internal hard disks, "queer" VID/PID assigned to USB devices, the occasional BIOS that doesn't *like* this - or that - partitioning or driver, etc.).

It is better, in your case with an even more "queer" BIOS, to start from simpler, more direct methods.

Do not worry about CaSe SeNsItIvEnEsS in Windows (DOS and Windows are NOT CaSe SeNsItIvE), the issue (if any) may come on Unix/Linux OS's AND - since grub4dos is actually CaSe SeNsItIvE (on CDFS but not on NTFS or FAT) a minimum of attention/diligence is needed when issuing grub4dos commands. 

But no problem, if you wish to actually worry , AND choose the red pill, we do have resources for you:

 

you have no idea how deep is the rabbit hole, but, heck, you asked for it.

https://web.archive.org/web/20151007005513/http://www.911cd.net/forums//index.php?showtopic=25612

jaclaz

dashun9_01.zip