Jump to content

WinNTSetup v5.3.4

JFX

By JFX
in Install Windows from USB

 Share

Recommended Posts

jaclaz

jaclaz

Posted
Posted
Just now, click-click said:

Do you have more info on reboot.pro? It's been down for weeks now.

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

 

1
Link to comment
Share on other sites

Antonino

Antonino

Posted
Posted (edited)

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 by Antonino
Link to comment
Share on other sites
galkinvv

galkinvv

Posted
Posted

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.

Link to comment
Share on other sites
JFX

JFX

Posted
  • Author
Posted

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?

Link to comment
Share on other sites
galkinvv

galkinvv

Posted
Posted (edited)

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 by galkinvv
Link to comment
Share on other sites
jaclaz

jaclaz

Posted
Posted

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

Or the feature has been added to it? :dubbio:

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

jaclaz

 

Link to comment
Share on other sites
galkinvv

galkinvv

Posted
Posted

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

Link to comment
Share on other sites
jaclaz

jaclaz

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

Link to comment
Share on other sites
Antonino

Antonino

Posted
Posted (edited)

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 by Antonino
Link to comment
Share on other sites
alacran

alacran

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

Link to comment
Share on other sites
gdc88

gdc88

Posted
Posted

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!

Link to comment
Share on other sites
galkinvv

galkinvv

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

1
Link to comment
Share on other sites
JFX

JFX

Posted
  • Author
Posted
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.

Link to comment
Share on other sites
gdc88

gdc88

Posted
Posted (edited)
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:worship:

 

Edited by gdc88
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...