Jump to content











Photo
* * * * * 1 votes

UEFI MULTI - Make Multi-Boot USB-Drive

aio boot linux uefi wim vhdx ssd windows 10 usb multiboot

Best Answer wimb , 02 March 2019 - 09:49 AM

There is a new version of UEFI MULTI available with new Grub4dos SVBus menu entries.

 

Mapping for VHD WIMBOOT is taken into account for various cases e.g VHD + WIM on USB Or on Internal Harddisk.

 

UEFI_MULTI determines the Drive Number for the MountPoint of the selected NTFS System Drive where the VHD resides.

UEFI_MULTI determines the DriveType and Bus Type of the selected NTFS System Drive.

In this way the program knows where VHD + WIM are located e.g. on USB Or on Internal Harddisk

and the program knows the Windows disk number which is used in menu.lst entries for WIMBOOT mapping in case the VHD + WIM are located on Internal Harddisk.

 

VHD + WIM located on NTFS drive of USB Harddisk Or  Portable SSD

iftitle [if exist (hd0,1)/W10x64_S3.vhd] (hd0,1)/W10x64_S3.vhd - SVBus  RAMDISK  - 2048 MB - map for WIMBOOT
map --top --mem (hd0,1)/W10x64_S3.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

=

VHD + WIM located on NTFS drive of Internal Disk

title W10x64_NL_1.vhd - SVBus  RAMDISK  - 2.0 GB - map as hd for WIMBOOT
find --set-root --ignore-floppies /W10x64_NL_1.vhd
map --top --mem /W10x64_NL_1.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

:cheers:

 

How to Make VHD WIMBOOT on USB and to use Grub4dos menu and SVBus driver for booting from RAMDISK

 

Download: VHD_WIMBOOT and  Manual: 

 

Best Results for speed of Portable VHD WIMBOOT obtained with SAMSUNG Portable SSD T5 250 GB with UEFI/MBR Partitioning with 20 GB FAT32 and 230 GB NTFS partition.

 

[attachment=16488:UEFI_MULTI-2019-03-02_140545.png] == [attachment=16487:W10x64-RAM-HelloWorld-2019-03-01_155130.png] == [attachment=16493:F2-VHD-USB-Ready-2019-03-03_113112.png]

 

With VHD WIMBOOT from USB Portable SSD we can have a full Win10 x64 of Size 600 MB booting from RAMDISK

as very fast Portable and always FRESH Operating System.

 

The only limitation is that booting from RAMDISK requires booting in BIOS mode with Grub4dos.

Hopefully we can have UEFI Secure support when Grub2 in future might be able to load such VHD into memory and launch Windows by chainloading bootmgfw.efi  :rolleyes:  :unsure:

But anyway booting from Windows Boot Manager menu as FILEDISK using Microsoft vhdmp.sys driver is available in BIOS and in UEFI Secure mode.

 

wimlib-clc CAPTURE followed by APPLY is important to reduce the size of the WIMBOOT Operating System from 3,5 GB down to 600 MB 

so that it can be located in VHD of Size 2 GB with total boottime 30 seconds which is OK.

 

Thanks to alacran for pointing me to wimlib of synchronicity (More Info: here) combined with  wimlib-clc of ReTokener    :)

Thanks to steve6375 for --top --mem and Wonko the Sane for (hd-1) and karyonix for (hd) map for WIMBOOT solution in Grub4dos menu   :worship:

 

VHD size 2 GB with full Win10x64 OS + Office Word and Excel + VLC player total size 600 MB in RAMDISK connected to WIM file of size 6 GB on USB NTFS drive

As compared to WinPE the VHD WIMBOOT has the advantage to have support for Office and Printer and any program can be installed which is all not the case for WinPE

 

In case of VHD WIMBOOT on each machine it takes extra boottime and space to adjust the drivers for that machine
The VHD WIMBOOT solution is Portable, but not as flexible as Win10XPE, where boottime is not dependant on machine hardware
 
For Portability it is good to have two VHD's
- On couple of other machines boot first with  25 GB VHD WIMBOOT as FILEDISK from Boot Manager Menu and  let Win10 Install all drivers
- At Home After booting with Win10 x64 OS then CAPTURE WIM of 25 GB VHD - Format and APPLY WIM on 1.5 GB VHD 
- Next time Boot with 1.5 GB VHD WIMBOOT on USB with Grub4dos menu from RAMDISK on all other machines
The 1.5 GB VHD will be handy for booting from RAMDISK on 4GB RAM machines, but in other cases a 3.9 GB VHD is preferred
 
In this way you have some learning on a couple of machines, but then the WIM has improved and can be used on all machines .... 
That principle of learning, where the SYSTEM registry is improving, is already working since the days of Windows eXPerience
Go to the full post


  • Please log in to reply
241 replies to this topic

#176 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 11 March 2019 - 06:20 PM

I understand now I should not have deleted that line, but the funny thing is: it runs even without it.

 

I'm totally agree with you about single line, I also like better that way. I'll start using it since now.

 

I'll run some test on several diferent machines I have at home and let you know, just to discart some potential troubles caused by any stupid Bios.

 

See you latter



#177 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15111 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 March 2019 - 07:36 PM

Wonko is right in saying that in that case mydisk is undefined as used in your menu.lst entry.

 
Well, Wonko is right by definition. ;)
 
The fun fact is actually that


set /a mydisk=%mydisk%+1
with mydisk UNDEFINED results in:


set mydysk
mydisk=0
(which is clearly a "quirk" in grub4dos)
 
So (unless mydisk is defined earlier the result of:
 

find --set-root --ignore-floppies /10x64-WB.vhd
root | set myroot=
set /a mydisk=%mydisk%+1
map --top --mem /10x64-WB.vhd (hd%mydisk%)
map --hook
root (hd%mydisk%,0)
chainloader /bootmgr

is actually same as:

find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd0)
map --hook
root (hd0,0)
chainloader /bootmgr

 
and we are back to square #1, after all these posts I cannot make head or tail of the reports both alacran and wimb made. :frusty:
 
The sheer fact that both of you insist on adding lines to menu.lst entries and blindly running them (as opposed to running commands on command line, checking the values variables get, etc.) is mindboggling (of course in my perverted mind) 
 
:duff:
Wonko
  • blackbalfur likes this

#178 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 472 posts
  •  
    Thailand

Posted 11 March 2019 - 07:51 PM

There is internal variable @root, so you can remove this line and use @root instead of myroot.
root | set myroot=
This can handle the cases where hd number is 1 digits.
set /a mydisk=%@root:~3,1%+1
What happens if root hd number is more than 1 digit.
root is (hd10,0)..(hd19,0) => mydisk=2
root is (hd20,0)..(hd29,0) => mydisk=3
root is (hd90,0)..(hd99,0) => mydisk=10
root is (hd100,0)..(hd127,0) => mydisk=2
It will override one of (hd2)..(hd10) but it should be OK because mydisk will not be equal to root hd number.

If you really want to calculate mydisk = root_hd_number+1, this handle the case where root hd number is 1 to 3 digit. hd number overflows at 128.
This will not be used but since I have already think about it, I write it here as an example.
if _%@root:~4,1%==_, set /a mydisk=%@root:~3,1%+1 || if _%@root:~5,1%==_, set /a mydisk=%@root:~3,2%+1 || set /a mydisk=%@root:~3,3%+1

There is (hd) which means next available driver number for hard drive. You can use together with (hd-1) (last existing harddrive). (ref : rmprebusb)
Map as (hd), then, after hook, it becomes (hd-1).
You don't have to use set, variable, string manipulation, calculation. It looks simple.
title win.vhd map next to last hd
find --set-root --ignore-floppies /win.vhd
map --mem --top /win.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

  • wimb likes this

#179 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 11 March 2019 - 10:39 PM

 


The sheer fact that both of you insist on adding lines to menu.lst entries and blindly running them (as opposed to running commands on command line, checking the values variables get, etc.) is mindboggling (of course in my perverted mind) 
 
:duff:
Wonko

 

 

I already know since long time ago this is your prefered way to work.

 

I can't talk for wimb, but in my case using an Spanish keyboard is a nightmare try to type something on grub4dos command line, even if it takes more time and more reboots it is easier for me to make changes to a menu.lst title on running OS, or WinPE.

 

alacran


  • antonino61 likes this

#180 wimb

wimb

    Platinum Member

  • Developer
  • 2683 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 12 March 2019 - 08:06 AM

 

There is (hd) which means next available driver number for hard drive. You can use together with (hd-1) (last existing harddrive). (ref : rmprebusb)
Map as (hd), then, after hook, it becomes (hd-1).
You don't have to use set, variable, string manipulation, calculation. It looks simple.
title win.vhd map next to last hd
find --set-root --ignore-floppies /win.vhd
map --mem --top /win.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

Thanks for interesting solution using mapping as (hd), which is working here ok.  :)

I have tested on one (not my own) computer, but next week I will be able to test on my own computer.



#181 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15111 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 March 2019 - 09:46 AM

I already know since long time ago this is your prefered way to work.
 
I can't talk for wimb, but in my case using an Spanish keyboard is a nightmare try to type something on grub4dos command line, even if it takes more time and more reboots it is easier for me to make changes to a menu.lst title on running OS, or WinPE.
 
alacran

If you cannot memorize the English keyboard "by touch", just §@ç#ing create a Spanish keyboard layout file and use it :frusty: :
http://reboot.pro/to...eyboard-layout/
http://reboot.pro/to...layout/?p=68522
As expected at the time, after the initial interest, the whole thing "faded away" into oblivion, maybe this is the occasion to re-vamp the spreadsheet I made. :unsure:


@karyonix
As always your is the "correct" approach :), though I still wonder if this is what is actually "required" and "why" it is actually required. :dubbio:
I mean, it seems like all is needed is that the vhd is mapped to a "non-existing-till-then" hard disk number.
And the report by alacran with the "undefined" variable (resulting in (hd0)) working remains puzzling.

Anyway, one could well use a "high" (and "fixed") disk number - say - (hd27) or (hd31) and be done with it?

Unless I am mistaken, (hd31) should be the last "hard disk" mappable, (hd32) is a CD-like device.

:duff:
Wonko

#182 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 12 March 2019 - 10:38 AM

Easy2Boot contains a number of keyboard scan code translation files for different languages, including Spanish, in the \_ISO\e2b\grub folder.



#183 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 12 March 2019 - 12:25 PM

@karyonix
As always your is the "correct" approach :), though I still wonder if this is what is actually "required" and "why" it is actually required. :dubbio:
I mean, it seems like all is needed is that the vhd is mapped to a "non-existing-till-then" hard disk number.
And the report by alacran with the "undefined" variable (resulting in (hd0)) working remains puzzling.

:duff:
Wonko

 

Yes it is required, WinSetup itself creates an internal BCD that we latter will use when Rambooting.

 

Wimb program only thing does to it is made some changes (all this can be seen/done on BootIce BCD tab easy mode) to adaptate it as: select Test Mode (testsingning), detect Hal and Kernell, select Optim, select No integrity Checks (not mandatory, it is mandatory for WinPE boot wims) and Unselecting Metro Boot Manager, some changes are required to let us install and boot using the unsingned SVBus driver, and also on BootIce BCD tab professional mode it verifies/changes BootMenuPolicy to legacy if required.

 

Attached two images from BCDs located into the VHD:

 

On 10 VHD on internal HD.png (VHD located on internal hd1), when VHD is loaded on Ram during Ramboot it becomes virtual hd2.

 

On 10 VHD on external HD.png (VHD located now on external USB disk hd2) the external USB disk adds another device before yet Rambooting so now VHD is located on hd2, then when Rambooting and VHD is loaded on Ram it becomes virtual hd3.

 

Then if the 10 VHD is not loaded on Ram on the right hd it can't find this path: \Windows\system32\winload.exe to boot.

 

About:

 

And the report by alacran with the "undefined" variable (resulting in (hd0)) working remains puzzling.

 

I perfectly understand you are right reading and interpreting the instructions but the fact is the 10 VHD had to be loaded in Ram on the right hd since if not it can't boot.  You may try to load it directly to the hd0 and it won't work, wimb have tested this since the first time as this was the clasical/obvious option to start with.

 

I have found on grub4dos, because on my frecuent misstyping of commands several cases where the program should not do something because latter i found it has a wrong syntax, but it does do the action fine, don't ask me why, it is obviously caused because the program itself allows it, this is not the place to talk about all this cases, but maybe I start a diferent thread about this latter.

 

Right now the important subject is the right/proper command to use. And I can say karyonix command is very clear and easy to remember and it works fantastic on my tests on 10 VHDs.

 

This is a winner:

title win.vhd map next to last hd
find --set-root --ignore-floppies /win.vhd
map --mem --top /win.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

Best Regards

 

alacran

Attached Thumbnails

  • 10 VHD on internal HD.png
  • 10 VHD on external HD.png


#184 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 12 March 2019 - 12:35 PM

@steve6375

 

Easy2Boot contains a number of keyboard scan code translation files for different languages, including Spanish, in the \_ISO\e2b\grub folder.

 

I have your Great Tool on my arsenal, and I think is the file KBD_SPANISH.G4B

 

Now, please tell me how I select on grub4dos to use the spanish keyboard (command to run this file).

 

alacran



#185 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 12 March 2019 - 12:39 PM

It is a grub4dos batch file - so just run it from grub4dos


  • alacran likes this

#186 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 12 March 2019 - 01:01 PM

re. 10 VHD on external USB - so if you try using that grub4dos menu on a different system with a different number of hard disks - does it boot?



#187 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 472 posts
  •  
    Thailand

Posted 12 March 2019 - 02:15 PM

As always your is the "correct" approach :), though I still wonder if this is what is actually "required" and "why" it is actually required. :dubbio:
I mean, it seems like all is needed is that the vhd is mapped to a "non-existing-till-then" hard disk number.

I guess the requirement that is not met in some recent failure reports is "WIM file must be accessible to boot loader" (via INT13H in legacy BIOS mode).
If drive number of the WIM-containing drive is mapped to RAMDISK, WIM-containing drive and WIM file would be inaccessible.
RAMDISK should have drive number different form WIM-containing drive.
A "non-existing-till-then" hard disk number is a sufficient condition but not a necessary condition.

And the report by alacran with the "undefined" variable (resulting in (hd0)) working remains puzzling.

In that test, WIM file is in a drive other than (hd0), so it is still accessible.

If WIM is in (hd0), and you simply make RAMDISK as (hd0), it would fail. But there is still a way to resolve the situation by mapping WIM-containing drive as (hd1), so it becomes visible.

These are unproven. It remains to be tested.
  • wimb likes this

#188 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 12 March 2019 - 03:08 PM

re. 10 VHD on external USB - so if you try using that grub4dos menu on a different system with a different number of hard disks - does it boot?

 

Yes, I have tested it on PCs with 1 and 2 internal HDs and wimb on his PC with 3 internal HDs.



#189 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 12 March 2019 - 03:10 PM

The question was - if you use exactly the same grub4dos menu and exactly the same VHD, can you boot it on many different systems which have a different number of internal hard disks?



#190 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 12 March 2019 - 03:21 PM

The question was - if you use exactly the same grub4dos menu and exactly the same VHD, can you boot it on many different systems which have a different number of internal hard disks?

 

NO, the VHD needs to load drivers and it fails (if VHD is too small), you can use same wimboot source, but VHD needs to be rebuild if hardware  is diferent.

 

EDIT: It seems it is solved now, see this post: http://reboot.pro/to...e-8#entry209810

 

The menu works on diferent number of internal drives.

 

Quote from wimb

 

 

For Portability it is good to have two VHD's
- On couple of other machines boot first with 10 GB VHD WIMBOOT as FILEDISK from Boot Manager Menu and  let Win10 Install all drivers
- At Home After booting with Win10 x64 OS then CAPTURE WIM of 10 GB VHD - Format and APPLY WIM on 1 or 2 GB VHD 
- Next time Boot with 1-2 GB VHD WIMBOOT on USB with Grub4dos menu from RAMDISK on all other machines
The 1 GB VHD will be handy for booting from RAMDISK on 4GB RAM machines, but in other cases a 2 GB VHD is preferred
 
In this way you have some learning on a couple of machines, but then the WIM has improved and can be used on all machines .... 
That principle of learning, where the SYSTEM registry is improving, is already working since the days of Windows eXPerience


#191 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 12 March 2019 - 03:30 PM

OK - in post #183, you are setting the BCD in BootIce to boot from a disk, not from RAM or VHD.

Have you tried changing it to RAM or VHD?



#192 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 12 March 2019 - 03:39 PM

In post 183 all talk is about Ramboot and the 2 pictures are of the BCDs located into the OS contained into the VHD, those BCDs are called by bootmanager to boot the VHD that is allready loaded on Ram.

 

Please read it again carefully.

 

title win.vhd map next to last hd
find
--set-root --ignore-floppies /win.vhd
map
--mem --top /win.vhd (hd)
map --hook
root
(hd-1,0)
chainloader /bootmgr   >>>>> This is the bootmanager allready loaded on Ram.

 

 

On 10 VHD on internal HD.png (VHD located on internal hd1), when VHD is loaded on Ram during Ramboot it becomes virtual hd2.

 

On 10 VHD on external HD.png (VHD located now on external USB disk hd2) the external USB disk adds another device before yet Rambooting so now VHD is located on hd2, then when Rambooting and VHD is loaded on Ram it becomes virtual hd3.



#193 wimb

wimb

    Platinum Member

  • Developer
  • 2683 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 12 March 2019 - 03:42 PM

There is a new version of UEFI MULTI available with new Grub4dos SVBus menu entries

 

Thanks to karyonix for solution to use map as (hd) for WIMBOOT  :worship: More Info here



#194 wimb

wimb

    Platinum Member

  • Developer
  • 2683 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 12 March 2019 - 03:54 PM

The question was - if you use exactly the same grub4dos menu and exactly the same VHD, can you boot it on many different systems which have a different number of internal hard disks?

 

The answer is YES, but you need sufficient FREE space inside the VHD for drivers to be loaded for the new hardware, but the grub4dos menu works on systems with variable configuration.

 

After booting 10-15 GB VHD as FILEDISK and having installed drivers on various equipment,

you can re-gain FREE space by doing CAPTURE - Format - APPLY sequence on the VHD.

The WIM file then contains all driver files instead of the VHD and you are able also to install that improved Vwim file on small 2 GB VHD.

WIMBOOT Capture of Full Win10x64 and Applied on VHD, occupies in VHD only 200 MB at rest, but on booting about 600 MB.

 

For booting from RAMDISK then a small 2 GB VHD is desired, which has limited space to install new drivers on unknown hardware.



#195 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 13 March 2019 - 05:50 PM

@wimb

 

Just to let you know here all is working fine now, still trying on some other PCs, if I find any trouble I'll let you know ASAP.

 

alacran


  • wimb likes this

#196 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 14 March 2019 - 10:29 AM

Please see this post: http://reboot.pro/to...hd/#entry209809

 

 

Portability seems to be feasible without the learning process, of course we need more test on more PCs to confirm this in a total way.

 

alacran



#197 wimb

wimb

    Platinum Member

  • Developer
  • 2683 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 22 March 2019 - 10:34 AM

VHD_WIMBOOT - Apply and Capture of WIM Files for OS in VHD

 

Download -  coming later

 

VHD_WIMBOOT-2019-03-22_095511.png == VHD_WIMBOOT-2019-03-22_095752.png


  • alacran likes this

#198 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 22 March 2019 - 03:49 PM

I used to test my 10x64-WB-LZX.wim (2.92 GB LZX compressed), VHD build was made on USB SSD drive using Win7 (just to test) without any issue.

 

My friend, I'm sorry to tell you all BCD(s) are wrong, no Ramboot, no bootmanager boot. But I thing it will be easy for you to fix this.

 

But after fixing the BCDs my W10x64_MX_1.vhd Rambooted very fine.

 

Well, after the report, let me tell you to make this tool was a very good idea, all is done with one single tool (fool prof). 

 

It was also a good idea to find the OS lang and apply it to VHD name and BCDs.

 

I noticed VHD_WIMBOOT\makebt\WimBootCompress.ini, I assume it is not hard coded into your program, and there is only a call to it, because sometime we may need to edit it, is that right?

 

Also let me suggest some additions to your program:

 

Add "Wimboot capture using LZX compression" as optional - it saves a lot of room, (20 % less) see: http://reboot.pro/to...am/#entry210021

 

Add "GZ compress the VHD" as optional - (only useful for Ramboot), it saves a lot of room (85 % less on my test with10x64-WB.vhd.gz)   and improves loading times on Ram, (and very useful for backup pourposes too), you could use 7-zip Format: gzip, Compression Livel: Maximum, not Ultra as I did, it is not almost as good as Ultra but it is very much faster, see: http://reboot.pro/to...am/#entry210031

 

Attached BCDs pictures, the first tree are as per the program is making them now, the second tree are the corrected BCDs.

 

Best Regards

 

alacran

Attached Thumbnails

  • BCD on Boot partition-Wrong.png
  • BCD into VHD-Wrong.png
  • EFI BCD on Boot partition-Wrong.png
  • BCD on Boot partition-Right.png
  • EFI BCD on Boot partition-Right.png
  • BCD into VHD- Right.png


#199 wimb

wimb

    Platinum Member

  • Developer
  • 2683 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 22 March 2019 - 04:36 PM

I need to test in Win 7 OS, which might be the cause of the problem.

 

Can you test in Windows 10 x64 OS  and using XPRESS 4K ? That is what I used.

 

There are some strange things like Boot into WinPE, which setting is not done by my program.

 

Also the Internal BCD is certainly wrong as made in your case and working fine in my case when using Win10 x64 OS.

 

The WimBootCompress.ini file can be modified and is not hardcoded in the program, but the filename is hardcoded.

 

The LZX Compression can be added as option.

 

GZ Compression has as disadvantage that you can only boot from RAMDISK.

That seems for me a matter of personal preference.

I like to have files that boot as FILEDISK and as RAMDISK.

Booting from RAMDISK is already very fast for the 1.5 GB, so the GZ Compression does not seem such an advantage.

 

Thanks for testing in Win 7 OS. I will try to fix it also for Win 7 OS



#200 alacran

alacran

    Gold Member

  • .script developer
  • 1181 posts
  •  
    Mexico

Posted 22 March 2019 - 05:33 PM

Now this time running VHD_WIMBOOT_x64.exe from 10x64 Pro 1709, this are my findings:

Since the only one VHD not made in the USB SSD, this time copied 8.1x64-WB.wim to Wimboot folder and selected it to create the VHD:

VHD file was created with wrong name W10x64_ES_1.vhd, it should be W8.1x64_ES_1.vhd or 8.1x64_ES_1.vhd.

On external legacy BCD (on Fat 32 drive): Wrong boot file, wrong OS name and wrong language.

On external EFI BCD (on Fat 32 drive): Same as previous.

On internal legacy BCD (on VHD drive): Wrong OS name and wrong language.

Also on menu.lst wrong VHD name.

 

But anyway without fixing anything I decided to Ramboot the VHD and it booted very fine, also confirmed this way it is in fact 8.1x64, without any dubt.

alacran







Also tagged with one or more of these keywords: aio boot, linux, uefi, wim, vhdx, ssd, windows 10, usb, multiboot

3 user(s) are reading this topic

0 members, 3 guests, 0 anonymous users