21 replies to this topic

[steve6375]

Easy2Boot has a menu option to install Windows XP from an ISO by booting to a 32-bit WinPE, using DiskPart to create a simple NTFS partition and then running winnt32.

 

The Diskpart script used is:

SEL DISK 0

CLEAN

CREATE PART PRI SIZE=20000 ALIGN=64260

FORMAT QUICK LABEL=SYSTEM

ASSIGN LETTER=Z:

ACTIVE

LIST VOL

EXIT

 

Now, this has worked fine for years but I have not tested it for a few years.

Now a user has reported that he gets a "Basic Disks created by Windows NT 4.0" error when using Win10 x86 as the WinPE.

I tested it and using WIn10 1607 as the PE does indeed give this error.

But Win8 and Win7 PEs work OK.

 

Can anyone throw some light on this strange problem (and is there a way to use Diskpart in WIn10 to avoid this error)?

 

Attached Thumbnails

• 

[Wonko the Sane]

Check if changing the bootsector and/or the MBR codes to the XP one after the formatting in diskpart changes anything (Bootsect.exe /NT52  and /MBR).

 

Wonko

[steve6375]

Just tried that and it did not fix the problem. The issue seems to be that it does not like the partition that was created??

I also don't understand why it is asking me to convert it to a dynamic volume and then install XP, I thought XP had to install to a simple volume???

Diskpart must have change between Win8 and WIn10.

Edited by steve6375, 23 April 2019 - 09:20 AM.

[steve6375]

I also added a 

CONVERT MBR

line to the diskpart script and still got the error.

CONVERT DYNAMIC reports an error. so diskpart thinks the disk is not a Basic disk.

[Wonko the Sane]

Just tried that and it did not fix the problem. The issue seems to be that it does not like the partition that was created??

I also don't understand why it is asking me to convert it to a dynamic volume and then install XP, I thought XP had to install to a simple volume???

Diskpart must have change between Win8 and WIn10.

If it is not the MBR and not the PBR code (and I presume it is not the non-cylinder-bound offset and size) then it could be:

1) some pre-existing data at the end of the disk? (dynamic disks - not entirely unlike GPT - have some info written at the very end of the disk) But it would make no sense, if it happened to both you and your user.

2) something in the NTFS itself?

 

Anyway, I seem to remember that XP/2003 could be installed to *some types* of Dynamic Disk (though noone or next to noone ever did that).

 

What do you have with list disk and detail disk (like here):

https://www.partitio...amic-disk-4.png

 

Try doing the following.

create the partition via diskpart of the windows 10 PE

boot to another "good" PE, let's say a Windows 7 PE

re-format the volume in this latter via format.com

 

Then try:

create the partition via diskpart of the windows 10 PE

re-format the volume via format.com

 

The CONVERT MBR is to switch from GPT to MBR (it is not about simple or dynamic) AFAICT 

 

You could also try to put the disk offline and then put it back online via Diskpart, maybe it is *something* that remains "stciky" in the Windows 10 PE after the creation and formatting?

Or use mountvol to remove the drive letter and then re-assign it?

 

Wonko

[steve6375]

I tested the earliest Win10 I could find which used Diskpart v10.0.10240 = FAILED

Early Win8 Diskpart v6.2.8441 = OK

Latest Win8 Diskpart v6.3.9600 = OK

 

I get the feeling that Diskpart v10 had a significant change...

[Wonko the Sane]

I get the feeling that Diskpart v10 had a significant change...

Sure, but until you make more experiments it is the usual "vague" report of "it doesn't work", there must be an objective change to the "final product".

 

We have no real objective proof that the issue is the diskpart (i.e. what diskpart does) and not the actual WinPE (based on Windows 10).

 

Just as an example - maybe (mind you I am just saying aloud semi-random ideas) - if after you have diskpart create and format the volume you reboot, then the XP install can proceed (or maybe not).

 

Maybe there is nothing objectively different in the actual disk/volume but it is the environment that triggers that message of the Windows XP setup only when run in the Windows 10 PE.

 

Wonko

[wimb]

What occurs when you remove  ALIGN=64260 ?

    ALIGN=<N>   Typically used with hardware RAID Logical Unit Number (LUN)
                arrays to improve performance. The partition offset will be
                a multiple of <N>. If the OFFSET parameter is specified, it
                will be rounded to the closest multiple of <N>.

[steve6375]

Removing ALIGN did not help 

[wimb]

OK.

 

For me this ALIGN value was strange and I never use ALIGN like that ....

 

Does FORMAT specifying NTFS FileSystem makes any change ?

FORMAT QUICK FS=NTFS LABEL=SYSTEM

[steve6375]

Progress!

I cleaned and partitioned the target drive using Win8PE Diskpart

Then I booted to Win10PE and ran Winnt32 - FAIL

Then I booted to Win8PE and ran winnt32 - PASS

So it is the Win10 PE environment that winnt32 does not like.

[Wonko the Sane]

So it is the Win10 PE environment that winnt32 does not like.

 

 

Good (which means bad ).

 

Is there any option in the WinPE 10 based to run programs in "compatibility mode"?

 

 *like*:

https://www.tenforum...ndows-10-a.html

(you can anyway try with the direct Registry mods)

 

It is as often happens just a guess, but maybe there is a conflict of some kind, the "RUNASADMIN" is most probably unneeded since in the PE you are already SYSTEM, but you never know.

 

@wimb

Yes, the align parameter is "queer", 64260 doesn't seem to me a "common" number, usually it is 1024 or 4096, and 64260 is not a multiple of either.

64512 or maybe 65536 would make more sense.

 

Wonko

[steve6375]

I used regedit to add a registry fragment before running diskpart

echo Windows Registry Editor Version 5.00>DP8.reg
echo.>>DP8.reg
echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]>>DP8.reg
echo "X:\\WINDOWS\\system32\\diskpart.exe"="~ RUNASADMIN WIN8RTM">>DP8.reg
regedit /s DP8.reg

but diskpart then does not run at all!

 

I tried ~ WIN8RTM also.

 

[Wonko the Sane]

Well, you just reported that you verified that the issue is not diskpart but rather the environment where the Winnt32 is run:

 

 

 

Progress!

I cleaned and partitioned the target drive using Win8PE Diskpart

Then I booted to Win10PE and ran Winnt32 - FAIL

Then I booted to Win8PE and ran winnt32 - PASS

So it is the Win10 PE environment that winnt32 does not like.

my suggestion was to try setting a compatibility mode (*like* XP) for WINNT32 not for DISKPART.

 

Wonko

[steve6375]

Doh! Sorry - been doing 6 other things and my mind went to 'diskpart at fault' mode!

Anyway, setting reg entry to  Y:\i386\winnt32.exe  and WINXPSP3  did not work either 

[Wonko the Sane]

Doh! Sorry - been doing 6 other things and my mind went to 'diskpart at fault' mode!
Anyway, setting reg entry to  Y:\i386\winnt32.exe  and WINXPSP3  did not work either 

Maybe you need to switch to an "alternate" install method, it sucks to need these workarounds .
 
Does also the good ol' method of *like*:

G:\I386\winnt32.exe /syspart:F: /tempdrive:F: /makelocalsource /noreboot

fail as well?
 
You could try with an old versionof JFX's WinnTSetup:
http://livexp.boot-land.net/
http://livexp.boot-l...etup_JFX.script
 
There is (was) a method to install by copying the files, I will have a look if I can find it.
EDIT:
Here it is:
https://msfn.org/boa...sb-drive-or-cd/
 

Wonko

[steve6375]

Thanks for links. Looks a little too complicated\unreliable for me! I will just limit the user to using Vista-Win8 PE's if they want to use this method.

Presumably booting to WinNTSetup under WinPE 10 and installing XP does not suffer from this issue? (untested). 

[Wonko the Sane]

Presumably booting to WinNTSetup under WinPE 10 and installing XP does not suffer from this issue? (untested). 

I don't know, it has to be tested, but WinNTSetup has historically worked very well on both old and more recent environments, so it is likely to work, the doubt is more if it would be more suited for the tests an old version (like the one I linked to) or a latest-latest (though it is a bit of time I don't use it, late evolution was all focused on the new 7/8/10 so while it surely works on them, it has to be seen if specifically the XP setup part still works in a 10 PE) .

Have you tried the:

 

G:\I386\winnt32.exe /syspart:F: /tempdrive:F: /makelocalsource /noreboot

It is only a guess, but since the process is not "interactive" it may just do what it should do.

If you think about it, the error must come from some kind of check which result is misinterpreted or falsified by the Win 10 PE (and that check may be triggered as well or not triggered in the non-interactive command line).

Or maybe it would give a different error.

 

Wonko


 

[steve6375]

This is what I use.

I get the same error with or without an unattend file.

%SRCDRIVE%\i386\winnt32.exe %LUNAT% /syspart:%TARGET% /tempdrive:%TARGET% /s:%SRCDRIVE%\i386 /makelocalsource

WinNTSetup works OK under WinPE10 (I am sure others would have complained long ago if it did not).

[Wonko the Sane]

WinNTSetup works OK under WinPE10 (I am sure others would have complained long ago if it did not).

Sure, I was saying something slighly different.

The program works just fine, but since noone probably used it to install XP (and XP while running in a 10 PE) lately, the specific XP install has not been tested/verified under these conditions, hence it needs to be tested.

Not entirely unlike you had this bug report only now, some three years after Windows 10 PE came out, as well probably it was the first time that someone attempted to use your tool this way.

And there is still the possibility that the error comes from some API call/whatever that *all* XP installing programs make and that the stupid Windows 10 based PE misinterprets.

 

Wonko

[steve6375]

Not sure what you mean?

I booted to Win10 install ISO and used SHIFT+F10 to get to Win10 PE console

I then ran WinNTSetup.exe

I then mounted an XP ISO and used it to install XP using the WinNTSetup form for XP.

 

Did you have something else in mind?

[Wonko the Sane]

Nahh , I was commenting on the:
 
 

WinNTSetup works OK under WinPE10 (I am sure others would have complained long ago if it did not).

 
And I did not translate (my bad):
 
 

WinNTSetup works OK under WinPE10 (I am sure others would have complained long ago if it did not).

to:

Ok, now, AFTER:
 
 

Presumably booting to WinNTSetup under WinPE 10 and installing XP does not suffer from this issue? (untested).  

 
I have actually tested WinNTSetup and it works fine in a PE 10 to install XP.

Problem solved by using WinNTSetup.

Wonko