Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country


About alacran

Profile Information

  • OS
    Windows 7 x64

Recent Profile Visitors

4,847 profile views

alacran's Achievements



  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

  • Create New...