Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

  • Country


Posts posted by alacran

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


    @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

    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:


    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



  2. On 3/8/2022 at 10:56 AM, JFX said:

    @alacran I think that i fixed WLAN problem and new version should handle your es-MX source with it's 2 fallbacks.

    you can make your own MinWin profile, make a copy of default folder and name it the way you want.
    WinNTSetup will give you a selection menu, if you left click on the MinWin icon. Right click will open the folder in explorer.

    I'll keep this default profile very slim, but if there is a serious problem let me know.

    WLAN problem is solved and now Wifi is working very fine.

    Yes, I usually copy the Defaul folder renamed as Medium and I make any edition there. And I select MinWin >>> Medium to install.

    When capture the VHD to a WIM file and re-applied it in Compact LZX Mode to a new VHD, by means of VHD_WIMBOOT program made by wimb, I kept the VHD mounted to take a look into it.

    And this are my findings, in no way VHD_WIMBOOT program caused the issue, as I also mounted the source VHD and was able to verify the lack of the following into it:

    \Windows\Boot\EFI >>> Folder qps-ploc should not be here, rest OK.
    \Windows\Boot\Fonts >>> Empty, all fonts were deleted, Fonts.txt needs to be fixed, the previus two lines \Windows\Boot\Fonts (delete folder fonts), and !\Windows\Boot\Fonts\ (but keep into it nothing), it seems you forgot to type the rest, maybe !\Windows\Boot\Fonts\segoe*
    \Windows\Boot\Misc\PCAT >>> All fine here
    \Windows\Boot\PCAT >>> Folders qps-ploc and qps-plocm should not be here, rest OK.
    \Windows\Boot\Resources >>> All fine here.

    Then this made my check SysWoW64 and System32 folders too.

    I would like to know the logic used in MinWin feature related to the %LANG% variable because if I understand correctly:

    !\Windows\SysWoW64\en-US >>> as I understand means exclude from deletion list en-US (folder in this case), just as wimlib works with files lists and the exceptions.

    !\Windows\SysWoW64\%LANG%  >>> as I understand means exclude from deletion list all (folders in this case) that comply the condition set in %LANG% variable.

    In previus case for es-MX as the fall backs langs are es-ES and en-US, the complete es-MX. es-ES and en-US should be keep intact, and this is not the case, what I got is the following:

    \Windows\SysWOW64\de-DE >>> This folder should not be here.
    \Windows\SysWOW64\en-US >>> Has 4 files and 0 folders; main OS has 45 files and 1 folder.
    \Windows\SysWOW64\es-ES >>> Does not exists; main OS has 142 files and 0 folders.
    \Windows\SysWOW64\es-MX >>> Has 14 files and 0 folders; main OS has 198 files and 7 folders.

    In my current moded SysWOW64.txt file I only added lines at the end of all lines in your original file, and didn't modified any lines in your list.

    The file System32-DLL.txt doesn't contain the %LANG% variable, but maybe in this case is into the code of MinWin.  And perhapss only MUI files related to listed DLLs are added.  As I got this:

    \Windows\System32\en-US >>> Has 86 files and 1 (Licenses) empty folder; main OS has 118 files and same empty folder.
    \Windows\System32\es >>> All fine here.
    \Windows\System32\es-ES >>> Has 668 files and 0 folders; main OS has 847 files and 0 folders.
    \Windows\System32\es-MX >>> Has 611 files and 0 folders; main OS has 849 files and 7 folders.

    All values related to main OS are cited as a reference, as this PC is running same OS 10x64 2004 es-MX, activated in line with ID, but Updates blocked, and only has installed 7-zip, SumatraPDF, FireFox and MB antimalware free, because the HDD failed about 2 weeks ago and I haven't installed more programs.

    All info you can share will be very highly appreciated, as then I will edit the lists in accordance with the logic related to %LANG% variable.


  3. The new WinNTSetup v5.2.2 made a fantactic work installing a Mini-10_es-MX.vhd.

    As wimb mentioned the Wifi connection is working very fine now, and no need of all the additional files I was using during my tests trying to make it work in a build made with previous v5.2.1, JFX only added 10 more DLL and MUI files to make the Wifi work.

    Of course there may be some little minor details to fix, but nothing critical.

    For now I'm using my modded SySWoW.txt file with very minor changes (under testing), and latter I will try to check if I can reduce it's size a few.

    In fact I'm posting from FireFox Portable runing from my Mini-10_es-MX.vhd.


    • Like 1
  4. @JFX

    Thanks JFX, you made a GREAT work with this new feature.

    But we still need your support to solve Wifi issue.  It is the only little detail still not working in Win10 2004.

    We have now on reboot.pro a topic dedicated to MinWin feature, to share there the info about our experiments building Mini VHDs with WinNTSetup: Mini Windows made with WinNTSetup


    On 3/7/2022 at 2:26 AM, wimb said:

    - LibreOffice does not work for me with modded SySWoW.txt - same error as before

    Fixed now.   Also all my previous post here were updated with this info,  Download of all the files I have edited is available on this post.


  5. Found another DLL file required:

    ; \Windows\System32\hotplug.dll

    And its respective *.mui file in the (lang) folder (es-MX in my case):

    ; \Windows\System32\es-MX\hotplug.dll.mui

    This DLL is required for USB device extraction.


    • Like 1
  6. On 3/6/2022 at 7:12 PM, alacran said:

    ; \Windows\System32\SensApi.dll   >>>   Requided to boot notepad++   now it boots and works fine, but fails when trying to save as....

    I found Paint can't also save as... but I had same issue before in a wimb's project aand I know the cure for that:

    ; \Windows\System32\shellstyle.dll   >>>   This is used by Paint to save as...., this very possible will also fix same issue in notepad++ (pending to test, will report back).

    Yes, I can confirm \Windows\System32\shellstyle.dll solved the Save as... isuue in Paint and in notepad++, and very possible in many other programs too.

    Well, just to summarize, so far:

    Installing Classic Shell just after first boot, the Start menu isuues are solved. It even has its own search feature, no need to use Cortana support for local search, which is good because our very appreciated SwiftSearch (that works at warp speed in NTFS) does not work in FAT-32 formated drives.

    With the modded SySWoW.txt, LibreOfficePortable is working fine.  EDIT: This file was re-uploaded it is fixed now.

    And with a minor edition in System32-DLL.txt, notepad++ and Paint are working fine.

    ; \Windows\System32\SensApi.dll   >>>   Requided to run notepad++

    ;\Windows\System32\shellstyle.dll   >>> Required for Save as...

    Only remaining is the Wifi issue.


    • Like 1
  7. Forgot to comment:

    I applied some extra settings with WinNTSetup 5.21 and they were working fine.

    The Start Menu has some issues as an example if traying to open Notepad, it doesn't open, the screen gets black for a second and it recovers immediatelly, as I always use Classic Shell, this is not a problem for me, from Classic Shell all is launched perfectly fine.


  8. JFYI

    My Mini-10_es-MX.vhd boots very fine now. (Made using Win10_2004_Spanish(Mexico)_x64.iso)

    By the way there is a typo in the file name it says: Lanugages.txt not Languages.txt

    Any way I edited it to keep all es-ES and es-MX, and saved with both names, your program will use the one it has coded, during you fix the typo.

    For use in es-MX version, I did same thing in my modded version of SySWoW.txt that was used in Mini-10-US.vhd to fix LibreOfficePortable issue, and also try to cover other possible cases like that.

    Also edited System32-DLL.txt, commenting the following lines:

    ; \Windows\System32\KBDLA.DLL   >>>   Spanish Latin American KB

    ; \Windows\System32\KBDSP.DLL   >>>   Spanish KB

    ; \Windows\System32\SensApi.dll   >>>   Requided to boot notepad++   now it boots and works fine, but fails when trying to save as....

    I found Paint can't also save as... but I had same issue before in a wimb's project aand I know the cure for that:

    ; \Windows\System32\shellstyle.dll   >>>   This is used by Paint to save as...., this very possible will also fix same issue in notepad++ (pending to test, will report back).


    Adding WlanMM.dll, let me see the available Routers now, but if selecting one, the usuall next dialalog to Connect and type the Password is not shown. Something else is still necessary.



  9. This is a quote from my post on http://reboot.pro/index.php?showtopic=21977&page=42#entry221074


    Testing WinNTSetup v5.21 to make Mini-VHD installations.

    WinNTSetup v5.21 was used to install Mini-10x64-2004_en-US.VHD and Mini-10x64-2004_es-MX.VHD

    In first try I didn't edited any list, or applied any tricks in WinNTSetup Tricks window.

    So far this are my findings:

    Mini-10x64-2004_en-US.VHD boots fine, but even if it recognizes the USB Wifi device, it can't connect to Internet, also even if I can select Spanish KB, and Latin American KB, they are not loaded, I found KBDSP.DLL and KBDLA.DLL were removed, this will be solved deleting the respective lines in System32-DLL.txt, but it seems fix the Wifi issue will be a little more complicated, but not impossible.

    I was able to install ClassicShell and 7-zip without any issue, also was able to install as TI, by means of PowerRun the PC context menu, and explorer context menu to launch cmd.exe, BootIce and WinNTSetup work fine, haven't tested any other programs.

    Mini-10x64-2004_es-MX.VHD does not boot. I can see Windows logo but never see the dots and never starts loading the first boot configuration, and then the PC shouts off.



    GOOD WORK JFX!!!!!, it does a GREAT job, but certanly the Wifi issue requires to be fixed.

    Now I have some questions:

    Can we make use of the Tricks window, or it's better don't use it in Mini-VHD?

    Any ideas about what I can test to fix the es_MX not booting?

    Will continue testing and report back.





  10. Thanks, allready fixed the post.

    Yes, I'm aware Porteus entries are included in your programs, I tested first Porteus, it boots fine, but tested on 2 PCs and the sound do not work on both of them.  Slacko64-7.0 sound works fine.

    EDIT: Porteus sound is working fine, but the program do not include any sound file to tets the sound, then from it comes my idea it was not working fine, just tested on Yutube and all is fine.

    By the way I usually have found sound issues on many distros, only Ubuntu and Linux-Mint Cinnamon (not the other Mint flavors) worked fine here, In fact your entries for Linux-Mint ISO are working very fine, but I'm looking for something smaller, about 1 GB total size including a 512 MB persistence file.

    I'm testing now Puppy Linux Fossapup64 v9.5 (409 MB, released on Sept/2020, based on Ubuntu), entries on menus are same as on Slacko64-7.0, but using Fossapup64 folder.

    So far all seems to work fine, it looks even faster than Slacko64-7.0 and more complete, this distro has an small program not included on Slacko64-7.0, (and no name available, to try to install it on other distros) that let rebuild the ISO keeping all the user settings and modifications (packages added and deleted), I want to change the browser for FireFox, I have done this before on other older flavor versions of Puppy, but haven't tested it on this distro yet.


  11. Thanks for your new versions. I will download and test them ASAP.

    I improved a little the menus from my previous post to load Slacko64-7.0 from Slacko64 folder located on the root of U-BOOT or U_NTFS partitions.

    For a folder (Slacko64) on the root of U-BOOT or U-NTFS partition on USB device
    Default KBD is en-US but can be changed on first boot; pkeys=es is a sample to set my Spanish KBD, delete it if unneeded.
    MBR grub4dos
    iftitle [if exist (hd0,0)/Slacko64/puppy_slacko64_7.0.sfs] Puppy Linux Slacko64 - (hd0,0)/Slacko64
    kernel /Slacko64/vmlinuz pmedia=usbflash pdrv=U-BOOT psubdir=/Slacko64 pkeys=es pfix=fsck,fsckp
    initrd /Slacko64/initrd.gz
    iftitle [if exist (hd0,1)/Slacko64/puppy_slacko64_7.0.sfs] Puppy Linux Slacko64-7.0 - (hd0,1)/Slacko64
    root (hd0,1)
    kernel /Slacko64/vmlinuz pmedia=usbflash pdrv=U-NTFS psubdir=/Slacko64 pkeys=es pfix=fsck,fsckp
    initrd /Slacko64/initrd.gz
    UEFI Grub 2
    if [ "${grub_platform}" == "efi" ]; then
    if [ -e "(hd0,msdos1)/Slacko64/puppy_slacko64_7.0.sfs" ]; then
    menuentry "Puppy Linux Slacko64 7.0 - (hd0,msdos1)/Slacko64/puppy_slacko64_7.0.sfs" {
        echo "Loading vmlinuz"
        linux /Slacko64/vmlinuz pmedia=usbflash pdrv=U-BOOT psubdir=/Slacko64 pkeys=es pfix=fsck,fsckp
        echo "Loading initrd.gz"
        initrd /Slacko64/initrd.gz
    if [ -e "(hd0,msdos2)/Slacko64/puppy_slacko64_7.0.sfs" ]; then
    menuentry "Puppy Linux Slacko64 7.0 - (hd0,msdos2)/Slacko64/puppy_slacko64_7.0.sfs" {
        echo "Loading vmlinuz"
        linux (hd0,msdos2)/Slacko64/vmlinuz pmedia=usbflash pdrv=U-NTFS psubdir=/Slacko64 pkeys=es pfix=fsck,fsckp
        echo "Loading initrd.gz"
        initrd (hd0,msdos2)/Slacko64/initrd.gz

    By the way reboot.pro is ofline again, do you have some info of the issue?


  12. JFYI

    I was able to run Puppy Linux slacko64-7.0 from a  folder on the root of U-BOOT partition.


    Create Slacko64-7.0 folder on the root of U-BOOT partition.

    Download the ISO and extract to that folder, as a bare minimum only following files are required:

    fdrv_slacko64_7.0.sfs, initrd.gz, puppy_slacko64_7.0.sfs, vmlinuz and zdrv_slacko64_7.0.sfs (332 MB in total).

    This are the menu entries I used:

    For a folder (Slacko64-7.0) on the root of U-BOOT (FAT-32) partition on USB device
    Default KBD is en-US but can be changed on first boot; pkeys=es is a sample to set my Spanish KBD, delete it if unneeded.
    MBR grub4dos
    iftitle [if exist (hd0,0)/Slacko64-7.0/puppy_slacko64_7.0.sfs] Puppy Linux Slacko64-7.0 - (hd0,0)/Slacko64-7.0
    kernel /Slacko64-7.0/vmlinuz pmedia=usbflash pdrv=U-BOOT psubdir=/Slacko64-7.0 pkeys=es pfix=fsck,fsckp
    initrd /Slacko64-7.0/initrd.gz
    Grub 2
    menuentry "Puppy slacko64 7.0" {
        echo "Loading vmlinuz"
        linux /Slacko64-7.0/vmlinuz pmedia=usbflash pdrv=U-BOOT psubdir=/Slacko64-7.0 pkeys=es pfix=fsck,fsckp
        echo "Loading initrd.gz"
        initrd /Slacko64-7.0/initrd.gz

    On first boot you are able to edit your settings, connect to your LAN, etc. when you turn off the OS you have the option to create a persistence file, if using default settings it will be slacko64save.4fs file, located into Slacko64-7.0 folder.

    NOTE: Every time you close the OS you are allow to save changes or not as you prefer.


    • Like 1
  13. There is no rush my friend, take your time, and maybe better waith for new UEFI grub4dos version.

    By the way as I read grub2 of a1ve do not have that problem since the begining because it is coded to find the EFI on FAT-32 first and FORCE to load it, only when it is not present there, it looks for it on NTFS partition. That's way you were able to boot from it and not from G4E when you had the compressed EFI on NTFS partition.


  14. Yes, that sound fine, I usually make the VHDs from Win10XPE_x64, as it boots as Trusted Installer, there is no problem to remove the x-Boot and x-EFI, but it's better if they are not created, in fact I deleted them and bootmgr and BOOTNXT files before make a new recaptured WIM file, but so far they were created and renamed every time I use VHD_WIMBOOT. It will be good if they are not recreated anymore, as in any future new version approach are also unnecessary.

    Hope reboot.pro will be online soon.



    I see that you often speak of grub32.efi whereas it is grubia32.efi  ......

    Thanks for correcting me, I will take care of not commit that mistake again.



  15. New version working very fine.

    Go to my issue Report: https://github.com/chenall/grub4dos/issues/248

    Almost at the very end of it you will find a message from yaya, download the BOOTX64.rar.txt, delete the .txt and extrac the new version, he allready implemented the map -- mem --top and now it is possible to load files to the top memory just as on MBR version I just tested it Rambooting a 2 partition VHD of 2.3 GB and it booted very fine.

    I assume it will be officially released very soon.


    • Like 1
  16. Just to make sure it was not an issue created by a possible mistake I committed, I deleted all the VHDs used for testing since 2020-11-26 version and created a new 900 MB Win10XPE_x64.vhd FAT-32 single partition VHD just extracting the ISO to it, and also a 1088 MB 2 partitions Mini-10-UEFI-WB.vhd (WimBoot VHD), both are booting fine but the virtual Floppies, CDs and VHDs are present too on this new Mini-10-UEFI-WB.vhd.

    If Rambooting Mini-10-UEFI-WB.vhd on MBR all is fine (no virtual devices on it), then there is no dubt they are created by the UEFI version of grub4dos during loading to Ram.

    And now I have a new issue, during this new tests I was UEFI booting from the Win10XPE_x64.ISO to make certain editions to the menu.lst and copying some files. etc, it was booting very fine more than 5 times until it do not fully load anymore, the loading line remains forever about 1/3 from the beginig and never moves, replaced it with the copy on my USB and same thing, tryed with and old version and then the classic message boot_image_handle not found, so now it can load any other ISO but not that one (from any partition, as tried several).

    Also there is no way I can setup the resolution on this PC, If I put colors or set a resolution, then the screen is colored and with no letters on it.

    At least now it is 1024x768 (just by itself) because it was 800x600 before, anyway once the WB VHD or the PE VHD boot, the resolution (1024x768) can't be changed, This 22 inches screen standard resolution is 1920x1080, but I usually have it set to 1600x900 on everyday use.

    Also the halt commad makes the PC reboot.

    Then I could say:

    This new version is working better than previous, it is a great achievement to Ramboot by means of SVBus as I can confirm.

    But there are still many things to fix, let's be patient, I'm sure in a few months the VHD Ramboot will be working as fine as the MBR version, yaya, a1ve, sunsea and many others including Ventoy author are actively posting comments and ideas on the topic on wuyounet forum.

    In the mean time we could help testing every new version to give them feedback with our findings.

    @ wimb

    I suggest you to make a Win10XPE_x64.vhd FAT-32 single partition VHD (maybe 900 MB to 1 GB depending of the size of your ISO to start testing Ramboot, don't forget to delete the CDUsb.y file on the VHD or you will have problems during booting, this is just to make sure your PC UEFI firmware allows you to boot from it.

    If this goes fine you should try latter a Mini-10 Wimboot install on a 1088 MB 2 partitions VHD wich is working fine on my PC. Maybe you are luckier and you don't get the extra virtual devices I get here.


  17. It seems I found the possible cause of the issue:

    Once Rambooting from a 2046 MB (just 2 MB smaller than 2 GB) VHD there are 3 virtual floppy drives (A:, B: and M:) + 2 virtual CDs (N: and O:) + 2 VHDs (they appear as un-inicialized) all of them related to SVBus, see attached pictures please.

    I don't have any resolution set on my menu.lst, after Rambooting and once on desktop the OS resolution is very low and it can't be changed.



    SVBus VHD-3.png

  18. Just made a 2046 MB VHD with same partition layout and installed on Compact LZX mode my Mini-10x64 on it and it Rambooted flawlessly on UEFI, This probes I was right when I said there is a 2 GB limit imposed to items loaded on Ram on versions grub4dos-0.4.6a_for_UEFI-2020-11-26 and 2020-12-05

    I opened an issue on https://github.com/chenall/grub4dos/issues

    Related to can't map --mem more than 2 GB on Ram: https://github.com/chenall/grub4dos/issues/248


    UEFI Rambooting.png

    • Like 1
  19. New version available:


    This new version is capable to UEFI Ramboot my 800MB Wimboot Mini-10x64 as VHD or as IMA:

    A big thanks to yaya, a1ve, and all other developers involved on this great achievement.


    title 10x64-WB.vhd SVBus RAMDISK for UEFI boot from HD -1
    find --set-root /VHD/10x64-WB.vhd
    map --mem /VHD/10x64-WB.vhd (hd)
    chainloader (hd-1)

    title 10x64-WB.ima SVBus  RAMDISK for UEFI boot from HD -2
    find --set-root /VHD/10x64-WB.ima
    map --mem /VHD/10x64-WB.ima (hd)
    chainloader (hd-1)

    But the 2.3 GB Mini-10x64 Compact mode installed did not boot as VHD or as IMA file:


    title 10x64-UEFI.vhd SVBus RAMDISK for UEFI boot from HD
    find --set-root /VHD/10x64-UEFI.vhd
    map --mem /VHD/10x64-UEFI.vhd (hd)
    chainloader (hd-1)

    title 10x64-UEFI.ima SVBus RAMDISK for UEFI boot from HD
    find --set-root /VHD/10x64-UEFI.ima
    map --mem /VHD/10x64-UEFI.ima (hd)
    chainloader (hd-1)

    Message is still the same:

    Out of memory
    boot_image_handle not found

    Press any key to continue....

    NOTE: Both, the 800 MB Wimboot and the 2.3 GB Compact mode, where installed on NTFS second partition, and boot files/folders are on first 64 MB FAT-32 0C partition (active to also be MBR bootable) of the (MBR inicialized) VHD or IMA. See pictures of sample BCDs attached on this post.

    From my previous post:


    In fact I don't know which it the actual size limit to load on Ram some item, so far a 2.3 GB VHD or IMA file is not loaded, it reports not enought Ram, but I was able to load and boot from Ram linuxmint-19.3-cinnamon-64bit.iso which size is 1.89 GB, based on this I assume the limit is currently about 2 GB.

    Then only issue remaining is:
    Load to RAM VHD or IMA files bigger than 2 GB.


  • Create New...