galkinvv

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. 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.

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).

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))

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.