WinNTSetup v5.4

[Antonino]

I wish I did, but no, I don't. All I know is that the site goes down once a month or so, and then it goes back up on Brito's or somebody else's factual initiative, if I am not mistaken. This time I think it has been down for a bit too long, relative to other times in the past, though. I can also add that, if it were a matter of money, Virgus and I would join in an albeit modest collection to have it back up. 

Edited January 4, 2023 by Antonino

[galkinvv]

A great tool, thanks. Just used it to install windows 7 for testing my software (HW-level, so no VMs).

I have an addition that may be just informational, or theoretically can be treated as a suggestion of a new small feature if many users has similar situations. My system boots in UEFI-mode, I used the SATA-disk for installation. The disk had a ntfs partition created by a gparted a long ago and I pointed WinNTSetup to use it both as a Boot device and Installation device.

WinNTSetup completed fine doing what I planned - placed the /EFI folder on the ntfs partition. I know that this is isn't universally suppotred setup, however if the UEFI capsule on the motherboard contains ntfs driver - this works fine, but the just installed Windows didn't show up in my MotherBoard UEFI boot menu.

My motherboard is Asus P10S-WS (C236 chipset, similar to 1xx intel chipset series) and... its ntfs driver is buggy - it has problems with parsing root directories of some ntfs drives (more details of this bug in my notes about windows10 installation on the another disk of the same system)

However the bug has a simple&stable workaround - just use the system from which WinNTSetup was run to create 5 empty folders in drive’s root with names starting with $ of maximal length:

$EFI_NTFS_DRIVER_FIX_FOLDER_WITH_LONGEST_POSSIBLE_NAME1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
$EFI_NTFS_DRIVER_FIX_FOLDER2WITH_LONGEST_POSSIBLE_NAME1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
$EFI_NTFS_DRIVER_FIX_FOLDER3WITH_LONGEST_POSSIBLE_NAME1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
$EFI_NTFS_DRIVER_FIX_FOLDER4WITH_LONGEST_POSSIBLE_NAME1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
$EFI_NTFS_DRIVER_FIX_FOLDER5WITH_LONGEST_POSSIBLE_NAME1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

This rebuilds the root folder record and buggy UEFI ntfs driver now sees the /EFI subfolder and boots newly installed system just fine!

I'm not motherboards expert but think that the working-but-buggy version of ntfs driver may present on a lot other motherboards too, so such workaround can be useful to anybody who rties to place windows and EFI on the same ntfs partitoin. If the problem is common - it may be useful to add it as a note of a fix to WinNTSetup when boot & installation partitions are selected identical.

[JFX]

Interesting, but I guess this is a very rare problem caused by a specif BIOS.
Or the combination of that BIOS plus the creation\formation of the partition with gparted.

Can these 5 fives be deleted after creation or are the required?

[galkinvv]

I've just tested those extra 5 folders deletion from both of my systems where I did this trick - the boot entry stays in bott menu & works fine. So it seems that after the creation that lead to root directory restructuring the workarounding foldes can be deleted.

I'm sure that this is BIOS-specific, but I don't know how may BIOSes uses the same NTFS driver. The EDK2 UEFI Shell reports

76 00010000 D - - 4 - AMI NTFS Driver FvFile(768BEDFD-7B4B-4C9F-B2FF-6377E3387243)

where 00010000 seems to be version in hex (so, really it seems that version isn't very descriptive and maybe even changes are made without upgrading it...). The BIOS itself is P10S-WS-ASUS ver3801  https://dlcdnets.asus.com/pub/ASUS/mb/socket1151/P10S_WS/BIOS/P10S-WS-ASUS-3801.zip (I'm not a motherboard BIOS expert, so I don't know if it can be unpacked)

And you a re right, this may be specific to the gparted creation/formatting of the ntfs partition; unfortunately I can't remember how I created the win10 partition where the problem apperars the first time several months ago. However such "specific" root directory passes chkdsk without any problems and runs windows fine if the EFI folder is placed on the ESP partition, so it seesm to be ntfs-conforming for other uses.

I'll try windows-based method for ntfs creation on my next windows install - it may be quite soon, since installing with WinNTSetup is very simple and non-risky))

Edited January 6, 2023 by galkinvv

[jaclaz]

I don't think that gparted can actually format (apply a filesystem to) a NTFS volume, it may create the partition but the actual filesystem should be created by Windows .

Or the feature has been added to it?

Otherwise it should be irrelevant, unless (for whatever reasons) the GPT partition entry triggers something strange in the MS format tool used.

Anyway the confirmation with your next experiment will be useful.

jaclaz

 

[galkinvv]

Up-to-date GParted can format NTFS (via `mkfs.ntfs` tool as backend).

I'm 50% Windows and 50% Linux user; my experience about current NTFS support in linux in short: it is 99.9% correct, but unfortunately very CPU-hungry (IO speed on ntfs-formatted SSDs limited by 100% CPU core usage).

[jaclaz]

1 hour ago, galkinvv said:

Up-to-date GParted can format NTFS (via `mkfs.ntfs` tool as backend).

Good to know.

So, it is very possible that this is the 0.1% hedge case, though the main culprit still seems to me the UEFI NTFS driver, I mean, if the mkfs.ntfs tool did anything "wrong" chkdsk would have surely throw a fit and/or the root directory would have had some other issues under windows.

jaclaz

[JFX]

I've added the temporary creation of the 5 folder in case of UEFI boot file creation on NTFS drive.
It shows a message box after creation and deletion.

WinNTSetup_x64.7z

[Antonino]

is there any way to avoid such creation on next editions for those like me who r still in legacy mode? I simply do not want to get confused with all those partitions.

Edited January 12, 2023 by Antonino

[alacran]

On 1/4/2023 at 8:52 AM, jaclaz said:

Latest news I have:

https://msfn.org/board/topic/182107-grub4dos-for-uefi/page/4/#comment-1233863

In a nutshell, there were some issues with the hosting/provider AND the actual machine, so it was shut down and Nuno is going to re-deploy on a new machine from last backup.

jaclaz

 

Just to let all of you know reboot.pro is back on line again: http://reboot.pro/index.php?showtopic=22687

alacran

[gdc88]

Hi, can i bypass the symbolic link in wimlib?

Error
---------------------------
Failed to Capture Windows Installation.

wimlib_add_image 0x33: Could not read the target of a symbolic link

 

thanks!

[galkinvv]

On 1/7/2023 at 6:22 PM, jaclaz said:

Good to know.

So, it is very possible that this is the 0.1% hedge case, though the main culprit still seems to me the UEFI NTFS driver, I mean, if the mkfs.ntfs tool did anything "wrong" chkdsk would have surely throw a fit and/or the root directory would have had some other issues under windows.

jaclaz

In the test I described below - I used Win10 Disk Managment to create & format NTFS partition, in a "new" offset from the disk start - in the free space appeared at the disk end  after shrinking down the last partition. The result is not stable, but >50% tests without extra folders hack lead to inability to run UEFI boot of just installed windows. So this bug is reproducible with windows-based NTFS creation too.

On 1/9/2023 at 1:53 PM, JFX said:

I've added the temporary creation of the 5 folder in case of UEFI boot file creation on NTFS drive.
It shows a message box after creation and deletion.

WinNTSetup_x64.7z 427.94 kB · 7 downloads

I've created a new 30G partition and tried installing there a small win7 variant (1.5GB in esd file). I tested the old and new WinNTSetup version, each 10 times, in a semi random order, formatting partition before each test. The results are following:

• 5.3 Beta 6 - 3 successes, 7 failes
• 5.3 Beta 6.1 - 10 successes, 0 fails

So it seems to be fixed! However now it is also known that the behaviour without "extra folder fix" is not stable. Sometimes it boots fine. Note - the randomness is at install time, not boot time. Every installation either always boots or never boots. Maybe it is related to some random order of flushing cache to disk in the windows NTFS driver.

[JFX]

On 1/13/2023 at 10:32 AM, gdc88 said:

wimlib_add_image 0x33: Could not read the target of a symbolic link

Hmm, never got this error message. There is currently no way to skip errors.
Can you post log file: %TEMP%\WinNTSetup\Logs\wimlib_error.log (don't close WinNTSetup it will delete the temp folder)

@galkinvv Thanks for these tests. I will remove the 2 Messageboxes and silently create/delete the folders in next version.

[gdc88]

On 1/14/2023 at 9:29 PM, JFX said:

Hmm, never got this error message. There is currently no way to skip errors.
Can you post log file: %TEMP%\WinNTSetup\Logs\wimlib_error.log (don't close WinNTSetup it will delete the temp folder)
 

i'd done the backup unattended using cmd, 

the computer is not accessible to me.

next time i'll upload the log 

 

thanks JFX

 

Edited January 16, 2023 by gdc88

[RUSerious]

Via win10, I’ve got all the BCD files in place on a stick for it to be bootable.
And WinNTSetup 5.2.6 gives stick 3 green lights as a Boot drive;  But I know from previous boot attempts that this stick is not BIOS bootable -- will not be seen during boot process.
Is there any way for WinNTSetup, or any windows app, to see this BIOS bootable bit within a stick’s ‘firmware’?
Thanks for the awesome app!!