Jump to content

WinNTSetup v5.3.4


JFX

Recommended Posts

1 hour ago, alacran said:

--recover-data parameter emulates the way Dism works during apply.

No, --recover-data ignores data corruption. That's not something that should be simply ignored.
Wimlib has an error output. Don't know why I have not add this. Will be available in next version.

BTW: DISABLE_INTEGRITY_CHECKS is useless in BCD loadoptions.

Link to comment
Share on other sites


40 minutes ago, JFX said:

No, --recover-data ignores data corruption. That's not something that should be simply ignored.
Wimlib has an error output. Don't know why I have not add this. Will be available in next version.

BTW: DISABLE_INTEGRITY_CHECKS is useless in BCD loadoptions.

 

About; --recover-data ignores data corruption.

Yes, you are right, I am aware that is the info mentioned in wimapply.pdf.

But I also remember in a post on wimlib forum Synchronicity (Eric Biggers) mentioned that it is the usual way Dism works when applying a WIM file.

 

about: DISABLE_INTEGRITY_CHECKS is useless in BCD loadoptions.

That's not fully right.

It is still usefull upto 10 v2004 (20H1), that's why I still prefer to use this version to make my Rambootable Mini VHDs (having SVBus driver installed).

It doesn't work anymore starting in 20H2, for 20H2 and newer we can pre-load (by means of grub2 or grub4dos for UEFI) EfiGuardDxe.efi before running the commands to Ramboot the VHD to solve this.

alacran

Edited by alacran
Link to comment
Share on other sites

You mix things up. 20H1 did work because the certificate was not blacklisted by MS.
A signed driver with stolen Cert can still pass Secureboot, if you have added it as trusted to your system.

Link to comment
Share on other sites

I jut tested SVBus_v1.3 signed, and it is working fantastic.

It allowed me to filedisk boot and Ramboot without the need to edit all BCD files.

Quote

New SVBus_v1.3 signed was just uploaded.

v1.3 uses a different certificate that is not blacklisted so far, so there is no need to edit all the internal and external BCDs

Download link to reboot.pro forum Downloads Section: http://reboot.pro/index.php?app=downloads&showfile=625

My thanks to JFX who shared with me the link to github page.

But the download lacks following files:

Install_SVBus.txt
instx64.exe
instx86.exe

So for users convenience I included them into this package.  A README file with instructions is also included in this package.

alacran

Download link to reboot.pro forum Downloads Section: http://reboot.pro/index.php?app=downloads&showfile=625

alacran

Edited by alacran
Link to comment
Share on other sites

After applying MinWin, some applications using .NET Framework do not start. Here's something like a "solution". 
You need to copy (or extract with 7zip) entire "C:\Windows\Microsoft.NET" folder from the original wim/esd image to your running MinWin Windows. (to the same folder). You will have a complete .NET Framework in this case. 
Then you need to launch all the .NET Framework applications you need, MINIMIZE them (do not close them), and delete entire "C:\Windows\Microsoft.NET" folder. Windows won't allow you to delete files that applications need (because they are used now). You will get something like mini .NET Framework. 
In my case 77 mb and 64 files. 
BUT some features in .NET apps won't work. You need to find dependencies for these applications and add libraries for them (dll files).

Edited by enuser2k
Link to comment
Share on other sites

@ JFX

Currently ONLY partition layout available in WinNTSetup to make a 2 partitions MBR initialized VHD, bootable in Bios/UEFI environments is having the FAT-32 Active Primary Partition as second partition.

Could you consider adding in a future version the option to make a 2 partitions MBR initialized VHD, bootable in Bios/UEFI environments having the FAT-32 Active Primary Partition as first partition?

I have being dealing with this using a pre-made VHD, and the boot files/folders are created fine if the FAT-32 is the first partition, but I'm thinking in make the life easier for non-advanced users, or some people that are partially visually impaired as our fellow devdevadev.

alacran

Link to comment
Share on other sites

There is bit more to translate now in:

WinNTSetup 5.2.6

- fixed Feeds did not got disabled on Windows 10
- added log files wimgapi_error.log and wimlib_error.log
- added VHD-DIFF option
- added commandline option VHD-DIFF -file:{file} -parent:{file}
- added commandline switch for VHD-CREATE -mbresp
- added commandline switch for VHD-CREATE -vhdbootletter:{0|1}
- added commandline switch for NT6 -vhdbootfiles:{0|1}
- new commandline switch -syspart and -tempdrive support VHD(X) files
- workaround: added AMD's Shadercache to wimscript exclusion (buggy SecurityDescriptors)
 

Link to comment
Share on other sites

  • JFX changed the title to WinNTSetup v5.2.6

JFYI

I can confirm WinNTSetup v5.2.6 is now capable to install a WIM file captured from a MinWin VHD.

I tested this applying the image using WinNTSetup in Wimboot mode to a 2 partitions  512 MB VHD:

Comparative wih same image applied using wimlib to a similar VHD:

MinWin-WB-Fix.vhd  >>>  512 MB Wimboot, made with WinNTSetup VHD, used space in NTFS partition is 315.5 MB, 32% fragmented.

MinWin-WB.vhd  >>>  512 MB Wimboot, VHD made with wimlib v1.13.5, used space in NTFS partition is 58.4 MB, 0% fragmented.

 

As you can see the resulting used space into the VHD NTFS partition is 5.4 X the used space compare with the used space if applying the image using Wimlib-clc or directly wimlib-imagex, also the VHD applied using  WinNTSetup is highly fragmented 32%, when the other is 0% fragmented.

As WinNTSetup used same wimlib v1.13.5, and the WimbootCompress.ini file is the same in both cases, all this increase in size, caused by 2034 full size (real) files, (that are pointers when not using WinNTSetup), is caused for an additional process that decompressed this files and making them real files, that is coded into WinNTSetup, and should no apply to at least Windows 10 2004 (20H1) and newer (haven't tested before this), maybe is not a bad idea to verify the WimbootCompress.ini into 2019 versions just to confirm (but I don't have them).

For more detailed info please see my post in reboot.pro: http://reboot.pro/index.php?showtopic=22621&page=7#entry221576

Mentioned post also include photos and:

Full size files.7z   >>>   Password = alacran  That are pointers when not using WinNTSetup, and using wimlib v1.13.5 directly.

WimBootCompress_for_WIMCOPY_.7z   >>>   Password = alacran  My modded WimBootCompress.ini v2022-08-10 into the WIM file applied,  NOTE: It is there since a previous test,

alacran

Link to comment
Share on other sites

Normally Windows 10 systems above build 17000 don't need any WOF exclusion.

But there were some reports that it don't work for some people (maybe hardware related).
None of them told if they used BIOS or UEFI booting. This also makes a difference!
EFI bootmgr has reading support for compressed files, BIOS bootmgr has not.

You can set SkipBuildsAbove17000 in Tools\Compact\WimBootCompress.ini if you sure you don't have
this problem with your machines.

Link to comment
Share on other sites

WinNTSetup_x64.exe CAPTURE-CLI J:\ "D:\Wimboot\" "MinWin-10x64-LZX.wim" "MinWin-10x64-LZX_220803_044206" "MinWin LZX WIMBOOT IMAGE" -compress lzx -config WimScript.ini

Is above WinNTSetup_x64.exe CAPTURE-CLI command is equivalent to following 'wimlib capture in wimboot mode' command ?

" Path to wimlib_x64 folder\wimlib-imagex.exe" capture J:\ "D:\Wimboot\MinWin-10x64-LZX.wim" "MinWin-10x64-LZX_220803_044206" "J:/ ==wimboot"  --include-integrity  --wimboot  --compress=LZX
 

 

~~~ Commandline Switches for CAPTURE and CAPTURE-CLI :

 image_path image_file "image_name" ["description"]

- /compress [xpress|lzx|lzms]    - set the compress type
- /config WimScript.ini    - Enables use of a configuration file for exclusion and compression options.

 

There is no switch for wimboot capture in CAPTURE-CLI ?

There is a confusion between image path and image file . Can you please a bit describe what to use here ?

Where I should use Volume Drive Letter in CAPTURE-CLI command ?

Thanks & Regards...

Edited by devdevadev
Link to comment
Share on other sites

Yeah, there i no wimboot switch, cause wimboot actually means a weeker compression form of xpress.

Image_path is the name MS choose in imagex.exe

Quote

 

Captures a volume image from a drive to a new WIM file.

  image_path - The path to the volume image to be captured.
  image_file - The path of the new WIM file.
  image_name - The unique name for the image being captured.
  description - The text that provides additional reference information.

 

As for your command line there is no equivalent to "--include-integrity" and you should set "-wimlib" to make sure you actually capture with wimlib and not wimgapi.

WinNTSetup_x64.exe CAPTURE-CLI J:\ "D:\Wimboot\MinWin-10x64-LZX.wim" "MinWin-10x64-LZX_220803_044206" "MinWin LZX WIMBOOT IMAGE" -compress lzx -config wimscript.ini -wimlib

Link to comment
Share on other sites

@JFXHellow, I use your tool to install wim which is syspreped,and is faster than wimlib or imageX.And the "X3 X4" next to the progress bar,how did you do it.I try to use wimGapi from MSDN,but it's too slow.I'm confused.:(

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
  • Recently Browsing   0 members

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