Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country


Everything posted by alacran

  1. Just to let all of you know reboot.pro is back on line again: http://reboot.pro/index.php?showtopic=22687 alacran
  2. JFYI After making several failled intents to Ramboot Differential VHDs by means of grub4dos for UEFI, this is the answer got from yaya to the issue report made in GitHub page of grub4dos: Issue: https://github.com/chenall/grub4dos/issues/379 Answer: https://github.com/chenall/grub4dos/issues/379#issuecomment-1258001726 Differential VHDs are not directly supported anymore in G4E. So no way to Ramboot them. Only option remaining in grub4dos to filedisk boot differential VHDs (in MBR and UEFI), is by means of using the external command ntloader. alacran
  3. @Jamdo You don't need to read all the 9 pages of that topic mentioned by our friend Jaclaz. Read this 3 posts, all info you require is there: Building your MinWin: http://reboot.pro/index.php?showtopic=22621&page=8#entry221675 http://reboot.pro/index.php?showtopic=22621&page=8#entry221680 Testing Differential VHDs made from MinWin installations: http://reboot.pro/index.php?showtopic=22195&page=2#entry221689 alacran
  4. JFYI Grub4dos UEFI version support of differential VHDs is available since v 2021-01-31: alacran
  5. I think following info could be useful for some readers of this topic: In a previous post I shared my MinWin_Medium_Profile_2022-08-20 That includes the option to enable automatically attach a VHD to Y drive every boot, this option works fine in all scenarios, even if booting from USB, or a WinPE were all drive letters have changed. This can be used in MinWin or any other mode installations. To include this option in an allready intalled OS, you can find the info and Download here: VHD to fixed drive v1.2 But for people having a good amount of Ram available, it is also possible to load your favorite VHD(s) to Ram automatically every boot, in all previously mentioned scenarios, just by editing a little CMD file, changing the VHD name and drive letter, or adding new line(s) to Ram load additional VHD(s), always keeping in mind that the VHD(s) fit in the available Ram and there is still enought Ram available for the OS, the booting time may have certaing small delate depending of the amount of GB that we will load to Ram. Load_RamDisk v1.0 (2022-08-30) This can be used in MinWin or any other mode installations, just by following the instructions in the README file, in case you want to disable (but keep available) any previous service to automatically attach a VHD, you can use: ServiWin by nirsoft, just select Services and find the service name in the list and by a right click on it select Change Startup Type and select disabled. EDIT: Forgot to mention Load_RamDisk is also possible to attach/mount as file disk, NOT as Ramdisk a VHD or IMG file jus by editing the CMD file, instructions inside the new CMD file. Hope this can be useful for some of you alacran
  6. Hi, JFX In MBR environment there is no problem with dynamic VHDs, and yes in fact they load faster than fixed size VHDs. But in UEFI the problem is not in SVBus driver, who does not support Rambooting dynamic VHDs is grub4dos for UEFI, at least untill last time I checked in the chinese forum where is located its page: http://bbs.c3.wuyou.net/forum.php?mod=viewthread&tid=422652 I read some months ago in a Post from Yaya (who started developing the UEFI version) on that page that the support for differencing VHDs was developed and working fine in the last version at that time. but I never have being interested in this kind or VHDs and didn't pair very much attention to this. By the way I never have tested this feature. EDIT: 2021-01-31 (yaya) Supports starting a first-level differential VHD image. About the WUB, yes it can be removed, it is there doing nothing. About native VHD ramdisk booting from bootmgr.efi, well all WinPE WIM files are Ramboot capables, I ram some tests with no luck, back in August or September 2020, trying to boot a OS drive captured in a single index WIM file, applying the bootable flag, and using the external file boot.sdi but a PE also makes use of the internal driver: \Windows\System32\drivers\fbwf.sys, (file-based wright filter driver) not present in the OS version, also found many things in the Registry that are very different. EDIT: I edited my previous post about the Medium profile, it is now MinWin_Medium_Profile_2022-08-20 Changes: New "Optional PStart pre-configured" folder. Medium\Add\Port_Apps\WUB folder was deleted. Medium\Add\Program Files\VHD_Loader folder: Now includes delete REG files. alacran
  7. I will share with all of you my MinWin Medium Profile. EDIT: It is now MinWin_Medium_Profile_2022-08-20 Hope you like it. See you later fellows. alacran
  8. When I capture a drive using wimlib, I usually use a modded WinbootCompress.ini, and the WinbootCompress.ini used is automatically copied into \Windows\System32, then the WIM is ready for applying it using wimlib with this new WinbootCompress.ini Please take the following as a kind suggestion, but of course as you are the author of the program, the decision is yours: With all due respect to you my friend, IMHO I think it may be easier if you could use a set of WinbootCompress.ini files, and depending of the OS version use the respective file, and just let wimlib apply the selected WIM index IAW the respective file used, and avoid extra decompression that induce file fragmentation or recompression that induce free space fragmentation, I don't have any experiece with Win11 but it seems it may need its own WinbootCompress.ini file. Following is useful to avoid high fragmentation in my Wimboot:WIMCOPY mode look alike installations: To avoid the fragmentation in small (upto 2 GB or 3 GB depending of the compression used) fixed size VHDs, as I use to have the NTFS partition as second partition, it is made first of only 50 MB, and once formated it's expanded to the full space, then in case of making a (1400 MB) VHD similar to Wimboot:WIMCOPY mode from a re-captured MinWin, I copy first the WIM file to the root of the NTFS and then create a Wimboot folder and move the WIM into it, and the resulting installation using wimlib is 0% fragmented, but if the Wimboot folder is created first the trick doesn't work. UPDATE: Today I tested this other option that also works fine: if the Wimboot folder is created outside of the VHD and the WIM file is copied/moved into this folder, and then the folder and its content is copied into the VHD, there is also 0% fragmentation after installation. By the way only fixed size VHDs are capable to Ramboot by means of grub4dos for UEFI + SVBus driver, unless there is new info I'm not aware. Also I want to share here this, that may be interesting for MinWin builds: http://reboot.pro/index.php?showtopic=22650 See you latter my friend. alacran
  9. At least since Win 10 v2004 (20H1), I can confirm without any doubt the Bios bootmgr has reading support for compressed files, just exactly the same EFI bootmgr has. I always test all my builds in Bios and in UEFI environments. Thats why I'm using same [PrepopulateList] as in the WimmootCompress.ini contained in this version, just adding following two lines: \Windows\System32\pwdrvio.sys \Windows\System32\pwdspio.sys I found since this version all *.sys drivers. don't need to be uncompressed as before, including SVBus driver that is loaded during the very first stages of boot process, this is valid for Bios and UEFI So even applying SkipBuildsAbove17000=1, in a Wimboot mode installation, of a re-captured WIM file from a MinWin VHD, (based in 10 2004), having all my programs, made using WinNTSetup, used space is very much bigger than using wimlib directly, that follows to the letter the WimbootCompress.ini contained in the WIM file. Also tried using additionally my same [PrepopulateList] section, in your version in \WinNTSetup_v526\Tools\Compact\WimBootCompress.ini, and the resulting used space is still bigger. The used space, (just after installation) I got when making a Wimboot mode installation of a MinWin based in 10 2004, using wimlib-imagex or Wimlib-clc is never bigger than 60 MB, usually it is 58.9 MB, then it fits fantastic in a 512 MB 2 partition VHD. Very usefull to Ramboot in a PC having only 2 GB of Ram. P.D. : New traslation is pending, I'm running some test about something else, but I'll do it ASAP. alacran
  10. 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
  11. @JFX I made a post and added to it a download link to my MediaFire free account for: Spanish_translation.7z Password: alacran This is based in v5.25 Please excuse me for the long time since previous version. And it disapeared, so I'm posting it again. alacran
  12. @ 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
  13. 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. Download link to reboot.pro forum Downloads Section: http://reboot.pro/index.php?app=downloads&showfile=625 alacran
  14. 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
  15. @JFX Hi my friend. I found an issue in v5.25, from my post: http://reboot.pro/index.php?showtopic=22621&page=6#entry221512 For the complete info please read the full linked post. Additional info that can be useful for you: wimlib-clc has pre-set the parameter --recover-data in apply Tab. Perhaps you are not using in WinNTSetup the parameter --recover-data in wimlib during apply. --recover-data parameter emulates the way Dism works during apply. And as a MinWin VHD had many cuts (per design), it is very possible the main source of the issue, and using the parameter --recover-data could help solve the issue (in case you are not usig it). alacran
  16. JFYI From my post: http://reboot.pro/index.php?showtopic=22621&page=6#entry221511 Modded_SySWoW_2022-08-01.7z 2.89KB alacran
  17. @JFX Just finished testing all features available in the MinWin version created with WinNTSetup v5.25, all useful things are available and open fine, including Event Viewer, Task Manager, Services Management, MS Config, PowerShell, etc. And all ornamentary and superfluous things including the (CR)Apps are removed. Congratulations my friend you did a fantastic work. Only thing I don't like of MinWin is during first boot after installation it takes a very long time to arrive to the desktop. And during long periods it doesn't seem to be doing anything as the HD led is not flashing, but if pressing the Caps Lock or Num Lock Keys they work fine, so we can confirm it is not blocked so It is better to be very pacient, but I would like to know what the hell is the PC doing all this time when the HD led is not flashing. By the way the lines added into Modded_SySWoW (2022-07-30) can be edited by commenting or deleting !\Windows\SysWOW64\mshtml.dll to squeeze a few more MB, (17.2 MB uncompressed, 7.34 MB if Compact LZX compressed). Without losing the capability to run LibreOfficePortable and lz4_compressor, but doing it we lose the capability to read the HTML (.chm) help files into 32 bits programs. alacran
  18. Hi JFX Thanks for the link to svbus_1.3, just downloaded it, but haven't tested it yet. I can confirm adding this lines to Tools\CATTrim.ini solves the issue. Now my MinWin with SVBus installed is capable of filedisk boot and Ramboot again if using CATTrim. But I noticed after apply it, several additional *.log files (that never existed before) are created in catroot2 after off-line apply CATTrim and reboot: C:\Windows\System32\catroot2\edb00001.log C:\Windows\System32\catroot2\edb00002.log C:\Windows\System32\catroot2\edb00003.log C:\Windows\System32\catroot2\edb00004.log C:\Windows\System32\catroot2\edb00005.log C:\Windows\System32\catroot2\edb00006.log C:\Windows\System32\catroot2\edb.log C:\Windows\System32\catroot2\edbtmp.log Each one is 2 MB (total 16 MB on first boot), so if filedisk booting all this garbage accumulates every boot, not when Rambooting as all this garbage is created on Ram every boot. IMHO and with all due respect to you my friend, CATTrim command works fine, but it's not really useful to reduce the OS size and future growup, on the contrary it induces the accumulation of more garbage. Of course as always it depends of user preferences to apply CATTrim to his/hers OS or not. alacran
  19. Yes it was run against a fully tested VHD, having SvBus driver Version=04/28/2020,, (signed by a chinese guy) using EVRootCA.reg, that was installed manually, (not by SVBus_INST_Trusted-20), and all its BCD entries have LoadOptionsString = DISABLE_INTEGRITY_CHECKS present, and the VHD was filedisk booting and Rambooting very fine before ran CatRoot trim tool. alacran
  20. JFYI From my post: http://reboot.pro/index.php?showtopic=22621&page=6#entry221504 Modded_SySWoW (2022-07-30).7z 2.75KB Password = alacran Clear_Event_Viewer_Logs.7z 625bytes Password = alacran alacran
  21. JFYI From my post: http://reboot.pro/index.php?showtopic=22621&page=5#entry221498 For more info please read all the quoted post. Modded_SySWoW.7z Password: alacran From my post: http://reboot.pro/index.php?showtopic=22621&page=5#entry221500 So CatRoot trim tool didn't work fine on my MinWin LZX VHD build. alacran
  22. Hi JFX, thanks for the new version. I will appreciate a lot a brief explanation about how to use NVRAM tool and CatRoot trim tool. After downloading the v5.25 from MediaFire and run it the first time to download required non-distributable files from MS, I was able to find \WinNTSetup\Tools\CATTrim.ini, but I can't find anything related to NVRAM in \WinNTSetup\Tools\ folder. alacran
  23. Just downloaded v4.0, I'll test it and comment back. alacran
  24. JFYI Some comments that I think may be usefull: Usually majority of ETL files in standard OS are located into \Windows\System32\winevt\Logs, this folder doesn't exits in MinWin, so we don't have to worry for it, but many LOG and ETL files are also created in several other locations. In MinWin the LOG and ELT files created after first boot are 100+ MB, and even more acumulate every boot, for more detailed info and files list please see this post. Back in 2020-11-09 I experimented replacing some of this folders, containing the unwanted files, with 0 bytes files to mitigate the creation of so many LOG and ELT files. The trick worked fine, and I made an script to do this, latter Wonko sugessted a more elegant version of the script, and wimb added it to his Win_Reduce_Trusted program. Anyway I made a new updated version of my CMD file, and tested running it as TI by means of PowerRun, just after making a MinWin istallation in a VHD still mounted in drive H, for more detailed info please see this post. Safe-to-Replace.cmd @echo off ; ; Following will delete some folders, to latter create a 0 bytes file with same name, ; to avoid the potential re-creation of the folder and this way send new ETL/LOG files to limbo, ; they will be deleted only if present ; rmdir "H:\ProgramData\Microsoft\Windows\wfp" /s /q rmdir "H:\ProgramData\USOShared\Logs" /s /q rmdir "H:\Windows\Logs" /s /q rmdir "H:\Windows\SoftwareDistribution" /s /q rmdir "H:\Windows\System32\SleepStudy" /s /q rmdir "H:\Windows\System32\WDI" /s /q rmdir "H:\ProgramData\Microsoft\Network\Downloader" /s /q rmdir "H:\Users\Default\AppData\Roaming\Microsoft\Windows\Recent" /s /q rmdir "H:\Users\Default\AppData\Local\Microsoft\Windows\WebCache" /s /q ; ; Following files will be created only if there in not a folder or file with same name ; fsutil file createnew "H:\ProgramData\Microsoft\Windows\wfp" 0 fsutil file createnew "H:\ProgramData\USOShared\Logs" 0 fsutil file createnew "H:\Windows\Logs" 0 fsutil file createnew "H:\Windows\SoftwareDistribution" 0 fsutil file createnew "H:\Windows\System32\SleepStudy" 0 fsutil file createnew "H:\Windows\System32\WDI" 0 fsutil file createnew "H:\ProgramData\Microsoft\Network\Downloader" 0 fsutil file createnew "H:\Users\Default\AppData\Roaming\Microsoft\Windows\Recent" 0 fsutil file createnew "H:\Users\Default\AppData\Local\Microsoft\Windows\WebCache" 0 Exit All was successful except the two last lines in both sections. The 0 bytes files were not created in: H:\Users\Default\AppData\Roaming\Microsoft\Windows\Recent >>> the folder was still present. H:\Users\Default\AppData\Local\Microsoft\Windows\WebCache >>> the folder didn't exists yet and the file also was not created. Then manually deleted the folder and created the two 0 bytes files in both locations. Rebooted, and all was fine. Now since the very first boot avoided the creation of a lot of LOG and ETL files. During first boot now they only use 48.4 MB, not more than 100 MB as before, I deleted all the remaing from SwiftSearch TI, and also made from booted MinWin the following directory junction: MKLINK /J C:\Windows\System32\Logfiles F:\VHD\Logfiles >>> DO NOT replace it by a 0 bytes folder. During boot the OS writes info into \Windows\System32\LogFiles\WMI\RtBackup >>> Criticall for booting But, I found an unexpected result, following additional 0 bytes files were created (after first boot) too: \Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\Windows\Recent \Windows\ServiceProfiles\LocalService\AppData\Roaming\Microsoft\Windows\Recent \Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\WebCache \Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Windows\WebCache So far I haven't noticed any issue, and all seems to work fine. Also I suggest to disable following services in MinWin: Diagtrack, DPS and SysMain. By the way I noticed some files that were deleted during MinWin installtion, were re-created after first boot: \Windows\Installer\SourceHash* >>> was re-created. \Windows\ServiceProfiles\LocalService\AppData\Local\FontCache-*.dat >>> all re-created. I made a new finding: \Windows\System32\dxdiagn.dll >>> is listed for deletion, comment it to avoid deletion because dxdiag.exe (directx dignostic) that is not listed for deletion, will be present in our build, and will not work without dxdiagn.dll alacran
  25. Rename it to WinNTSetup_version_522.rar, and try again, maybe that can help. alacran

  • Create New...