Jump to content











Photo
* * * * * 1 votes

UEFI MULTI - Make Multi-Boot USB-Drive

uefi linux aio boot multiboot windows 10 wim ssd usb vhdx

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: Attached File  VHD_WIMBOOT.pdf   500.28KB   149 downloads

 

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.

 

== == 

 

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
233 replies to this topic

#151 wimb

wimb

    Platinum Member

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

Posted 28 February 2019 - 10:21 AM

So, in a nutshell an offset to the first NTFS partition volume of:

16, 32, 64, 128, 256, 512 or 2048

is "good" and there is NO difference in using the one or the other (if the page size is 8 kb)

 

If the page size is 16 Kb (or 8 Kb), any of:

32, 64, 128, 256, 512 or 2048

is "good" and there is NO difference in using the one or the other.

 

In practice:

64, 128, 256, 512 and 1024

will "cover" page sizes up to 32 Kb in EXACTLY the same manner, and 

128, 256, 512 and 1024 will "cover" page sizes up to 64 Kb in EXACTLY the same manner.

 

 

Thanks Wonko for giving details on first sector value and page sizes.

 

So I may conclude that my USSD hosting VHD is OK in this respect  :)



#152 wimb

wimb

    Platinum Member

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

Posted 02 March 2019 - 09:49 AM   Best Answer

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: Attached File  VHD_WIMBOOT.pdf   500.28KB   149 downloads

 

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.

 

UEFI_MULTI-2019-03-02_140545.png == W10x64-RAM-HelloWorld-2019-03-01_155130.png == 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

  • alacran likes this

#153 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 03 March 2019 - 06:23 PM

Tested  on 2 external USB devices and working great.

 

Thanks for all your work adding new code to make appropiate changes to all BCDs (op to 4 on wimboot OSs when the USB device has Fat-32 and NTFS drives), and also the new grub4dos lines on menu.lst

 

Very usefull for creating Multibootable portable devices.  I haven't tested the program with my wimboot VHDs located on internal (hd1,5), also having source wimboot file on same partition, since only wanted RamBoot, then was easier to just add the titles to my menu.lst

 

alacran



#154 wimb

wimb

    Platinum Member

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

Posted 03 March 2019 - 06:52 PM

Thanks alacran for testing UEFI_MULTI in making BCD and menu.lst entries on USB for VHD WIMBOOT.

 

I have used UEFI_MULTI also for the case of booting from USB and VHD + WIM located on NTFS partition of GPT Or MBR internal hardddisk.

 

And I have also tested booting from Internal harddisk and VHD + WIM located on Internal harddisk

 

I think now all possible cases are treated allright by UEFI_MULTI for making the boot entries.



#155 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 03 March 2019 - 10:49 PM

And I have also tested booting from Internal harddisk and VHD + WIM located on Internal harddisk

 

I think now all possible cases are treated allright by UEFI_MULTI for making the boot entries.

 

You read my mind, I was thinking on this scenario and coming to comment it to you, but as you allready said now all possible cases are allready covered by your great tool.

 

By the way thinking in diferences and benefits from Ramboot and WinPEs, when running a portable wimboot install only thing I miss from WinPE's is usually they do not care about NTFS permissions, to facilitate the work when making offline changes to other OSs.  I know ChrisPE uses AccessGain, but since you have your own tools to make WinPE's since long time ago, I think you may have some other candidates we may add to our VHD before wimboot Capture and Install.

 

alacran



#156 wimb

wimb

    Platinum Member

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

Posted 04 March 2019 - 05:59 AM

By the way thinking in diferences and benefits from Ramboot and WinPEs, when running a portable wimboot install only thing I miss from WinPE's is usually they do not care about NTFS permissions, to facilitate the work when making offline changes to other OSs.  I know ChrisPE uses AccessGain, but since you have your own tools to make WinPE's since long time ago, I think you may have some other candidates we may add to our VHD before wimboot Capture and Install.

 

 

I think AccessGain is the way to go and I don't have another tool for this purpose.



#157 wimb

wimb

    Platinum Member

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

Posted 04 March 2019 - 11:52 AM

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

 

Manual available: 

 

:cheers:

 

Actually the Full Win10 x64 in  2GB VHD at rest uses only 206 MB  :w00t: and  all drivers including the large NVIDIA driver are working properly  :magic:

 

F2-C-206MB-2019-03-04_160039.png == F2-VHD-USB-Ready-2019-03-03_113112.png


  • alacran and devdevadev like this

#158 wimb

wimb

    Platinum Member

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

Posted 06 March 2019 - 03:03 PM

I have used VHD WIMBOOT booting from Portable SSD now on different hardware.

 

On Unknown hardware first a VHD of 5 GB is preferred in booting as FILEDISK so that there is enough space to install all drivers.
After this learning step we can do CAPTURE and APPLY to VHD of Size 2 GB and boot from USB with Grub4dos from RAMDISK.
 
On each machine it takes extra boottime to adjust the drivers for that machine.
Also returning on original machine takes extra time to readjust the drivers.
 
The VHD WIMBOOT solution is Portable, but not as flexible as Win10XPE, where boottime is not dependant on machine hardware.


#159 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 06 March 2019 - 03:26 PM

@ wimb

 

After reading your VHD_WIMBOOT.pdf  I noticed you capture with wimboot option twice (capt_f.wim and capt_f2.wim), and install as wimboot twice too. Do you have any particular reason for doing it twice? If not, then you may consider doing it this way:

 

I use to create my first full standard install on VHD from 10 or 15 GB and I have used also expandable VHD only on this first install, (yes now WinNTSetup let you use smaller sizes, some time ago 25 GB was the minimun possible), then on this VHD I install all I will need running on my final OS, and a single wimboot mode capture is enought, and finally a wimboot mode install to VHD is required.

 

SVBus driver can be added latter on FileDisk booted small wimboot VHD, or could be installed on first Full size VHD and if we want, for some reason, it not compressed latter on our wimboot VHD and (only in this case) just add to your WimBootCompress_BCD.ini on [PrepopulateList] before capture, as the other you recommed (good idea by the way):

 

\Windows\System32\drivers\svbusx64.sys  -----> This should be the only required (if any).
\Windows\System32\DriverStore\FileRepository\svbus.inf_amd64_de3077296e6085bf\*  -----> I think this is not mandatory, but it do not hurt.

 

And the full section [PinningFolderList] can be deleted to do not have anymore the warning about Unrecogniced Section: [PinningFolderList], this section is a new addition on 1809, it do not exists on the WimBootCompress.ini of my running 1709.

 

Another comment is select tricks during WinNTSetup install (like disable hibernate and no pagefile) is required only the first time you make an install, since when we capture the OS on the VHD all this is allready done and we do not need to do it againg next time we deploy new captured image, since it is as a Backup image, for that reason I usually run CCleaner and defragment before a capture.

 

Best Regards

 

alacran



#160 wimb

wimb

    Platinum Member

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

Posted 06 March 2019 - 03:45 PM

Twice using Capture is not really needed, but it reduced again the used size inside the VHD after Install of the driver and booting from USB.

Also I found it a nice illustration on how you can reduce the size after install of extra programs or after adding drivers of other machines.

In that case the sequence CAPTURE - Format - APPLY carried out on mounted VHD results quickly in the original present free space, since all file data go in the WIM file.

 

Good idea to further improve the custom WimBootCompress_BCD.ini file by adding svbus driver and removing the [PinningFolderList] Section  :) 

 

You are quite right that the second time in WinNTSetup we must not use any tweaks or tricks since they are already present in the CAPTURE wim file.

 

Nice to hear your comments on the VHD_WIMBOOT.pdf manual.

 

:cheers:


  • alacran likes this

#161 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 07 March 2019 - 01:32 PM

@ wimb

 

Twice using Capture is not really needed, but it reduced again the used size inside the VHD after Install of the driver and booting from USB.

Also I found it a nice illustration on how you can reduce the size after install of extra programs or after adding drivers of other machines.

In that case the sequence CAPTURE - Format - APPLY carried out on mounted VHD results quickly in the original present free space, since all file data go in the WIM file.

 

 

:cheers:

 

Yes, this is a good way to re-gain space on the VHD after some time of use and/or installing more programs since first install.

 

alacran


  • wimb likes this

#162 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 10 March 2019 - 12:50 PM

@ wimb

 

I am sorry to tell you I found an issue on UEFI_MULTI my friend, From your post No. 152

 

 

VHD + WIM located on NTFS drive of Internal Disk 1

title W10x64_S3_1D.vhd - SVBus RAMDISK - 2048 MB - map for WIMBOOT
find
--set-root --ignore-floppies /W10x64_S3_1D.vhd
map
--top --mem /W10x64_S3_1D.vhd (hd1)
map --hook
root
(hd1,0)
chainloader /bootmgr

 

Something like this are the lines for grub4dos menu.lst, applied by UEFI_MULTI when VHD is located on any partition of internal HD 1 (hd1), but they generate a BSOD.

 

The lines quoted are used as an example, actual title applied is a little different.

 

After some tests I have found the following:

 

The right lines when VHD is located on internal disk 1 (hd1,X) are:

VHD + WIM located on NTFS drive of Internal Disk 1
title W10x64_S3_1D.vhd - SVBus RAMDISK - 2048 MB - map for WIMBOOT
find --set-root --ignore-floppies /W10x64_S3_1D.vhd
map --top --mem /W10x64_S3_1D.vhd (hd2)
map --hook
root (hd2,0)
chainloader /bootmgr

This is when VHD is located on internal disk 2 (hd2,X) are:

VHD + WIM located on NTFS drive of Internal Disk 2
title W10x64_S3_1D.vhd - SVBus RAMDISK - 2048 MB - map for WIMBOOT
find --set-root --ignore-floppies /W10x64_S3_1D.vhd
map --top --mem /W10x64_S3_1D.vhd (hd3)
map --hook
root (hd3,0)
chainloader /bootmgr

And when VHD is located on internal disk 0 (hd0,X) are:

VHD + WIM located on NTFS drive of Internal Disk 0
title W10x64_S3_1D.vhd - SVBus RAMDISK - 2048 MB - map for WIMBOOT
find --set-root --ignore-floppies /W10x64_S3_1D.vhd
map --top --mem /W10x64_S3_1D.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr

So we may say for RamBooting a VHD from internal disks, we need to use hd number (according to grub4dos) where VHD is located + 1 in our menu.lst for grub4dos RamBoot.

 

EDIT: On one PC VHD and wim file are located on internal MBR HD (hd1,5), on another PC VHD and wim file are located on internal MBR HD (hd0,6), and both work fine with my approach.

 

Best Regards

 

alacran



#163 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 10 March 2019 - 03:46 PM

@alacran

I suspect that the way different BIOSes will react may be different.

 

Anyway AGAIN the "right" approach REMAINS dynamically getting the disk/drive numbers *like*:

http://reboot.pro/to...drive/?p=209497

 

Of course if needed increasing the disk number, i.e.:



title W10x64_W82.vhd - SVBus  RAMDISK  - 2048 MB - map as disk+1
find --set-root --ignore-floppies /W10x64_W82.vhd
root | set myroot=
set mydisk=%myroot:~3,1%
map --top --mem /W10x64_W82.vhd (hd%mydisk%)
map --hook
root (hd%mydisk%,0)
chainloader /bootmgr

:duff:

Wonko


  • alacran likes this

#164 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 472 posts
  •  
    Thailand

Posted 10 March 2019 - 07:24 PM

@alacran
@Wonko the Sane

How about map mem as (hd1) and WIM-containing drive as (hd0). This will make sure WIM-containing drive is not hidden.
title W10x64_S3_1D.vhd - SVBus RAMDISK - 2048 MB - map for WIMBOOT
find --set-root --ignore-floppies /W10x64_S3_1D.vhd
map --top --mem /W10x64_S3_1D.vhd (hd1)
# read saved_drive
set /a drive=*0x82A0&0xFF
map (%drive%) (hd0)
map --hook
root (hd1,0)
chainloader /bootmgr
or
mem as (hd0) and WIM-containing drive as (hd1).
title W10x64_S3_1D.vhd - SVBus RAMDISK - 2048 MB - map for WIMBOOT
find --set-root --ignore-floppies /W10x64_S3_1D.vhd
map --top --mem /W10x64_S3_1D.vhd (hd0)
# read saved_drive
set /a drive=*0x82A0&0xFF
map (%drive%) (hd1)
map --hook
root (hd0,0)
chainloader /bootmgr


#165 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 10 March 2019 - 08:47 PM

@ Wonko

 

@alacran


Of course if needed increasing the disk number, i.e.:



title W10x64_W82.vhd - SVBus  RAMDISK  - 2048 MB - map as disk+1
find --set-root --ignore-floppies /W10x64_W82.vhd
root | set myroot=
set mydisk=%myroot:~3,1%
map --top --mem /W10x64_W82.vhd (hd%mydisk%)
map --hook
root (hd%mydisk%,0)
chainloader /bootmgr

:duff:

Wonko

 

Once again you had the answer.

 

This map as disk+1 worked fine, thanks, I think now having it working as it should be, will be easier for wimb to code this grub4dos menu lines into UEFI_MULTI

 

EDIT: JFYI VHD and wim file on this PC are located on internal MBR HD (hd1,5).

Haven't tested on another PC where VHD and wim file are located on internal MBR HD (hd0,6), but I don't see any reason to fail.

 

alacran



#166 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 10 March 2019 - 09:01 PM

@ karyonix

 

@alacran
@Wonko the Sane

How about map mem as (hd1) and WIM-containing drive as (hd0). This will make sure WIM-containing drive is not hidden.


 

 

Thanks very much for your interest in trying to help in this subject.

 

Tested first Wonko suggestion and it worked fine, haven't tested any of your suggestions since the problem seems solved.

 

On the other hand IMHO it is better to deal only with one variable (the VHD location) than two (the VHD location + the souce wim file location) since the number of possible combinations will be increased.    Anyway that's only my opinion as user, I am not the developer of UEFI_MULTI, wimb will have to take all decisions.

 

alacran



#167 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 March 2019 - 10:30 AM

@alacran
@karyonix
I don't know.  :huh:
wimb reported something, and then reported that that same something once automated in grub4dos didn't work, and that something else (automated in grub4dos) worked,   then alacran reported yet something else, and that yet something else once automated in grub4dos worked, now you propose yet another something.
 
As said I suspect that different BIOSes may number disks differently (or that how many disks are present in a given system may make a difference) and I am pretty sure that reports are either incorrect or partial or "a suffusion of yellow"   :frusty:
 
@alacran
What you reported makes no sense.
The snippet I posted was an example to let you make tests, it cannot possibly work as "disk+1" because I simply (intentionally) did NOT increase the disk number, and ONLY showed a way to have the disk number.
Let's see together the posted snippet:

title W10x64_W82.vhd - SVBus RAMDISK - 2048 MB - map as disk+1
find --set-root --ignore-floppies /W10x64_W82.vhd <- let's say that the .vhd is on disk 1 (hd1,0)
root | set myroot= <- root and thus myroot value  is  (hd1,0)  Filesystem type bla bla bla ...
set mydisk=%myroot:~3,1% <- mydisk value becomes 1
map --top --mem /W10x64_W82.vhd (hd%mydisk%) <- this becomes map --top --mem /W10x64_W82.vhd (hd1)
map --hook
root (hd%mydisk%,0) <- this becomes root (hd1,0)
chainloader /bootmgr

 
Now this actually makes "disk+1":
 

title W10x64_W82.vhd - SVBus RAMDISK - 2048 MB - map as disk+1
find --set-root --ignore-floppies /W10x64_W82.vhd <- let's say that the .vhd is on disk 1 (hd1,0)
root | set myroot= <- root and thus myroot value  is  (hd1,0)  Filesystem type bla bla bla ...
set mydisk=%myroot:~3,1% <- mydisk value becomes 1
set /a mydisk=%mydisk%+1 <- mydisk value becomes 2
map --top --mem /W10x64_W82.vhd (hd%mydisk%) <- this becomes map --top --mem /W10x64_W82.vhd (hd2)
map --hook
root (hd%mydisk%,0) <- this becomes root (hd2,0)
chainloader /bootmgr

 

:duff:

Wonko



#168 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 11 March 2019 - 02:08 PM

@ Wonko

 

Yes there was a mistake on my previous test, I had duplicated the entrance used to test, sorry my mistake, see my menu.lst

 

EDIT: I thought I was selected the wrong title, but it was not the case. I was using this time 8.1x64-WB.vhd to run the test.

 

After all I have found 8.1x64-WB.vhd do not matter what hd we map it Ramboots anyway, see post No. 170 for detailed tests.

 

All this were wrong assumtions generated because files are located on a drive diferent to hd0 and on this case then this applies:

 

Mapped drive number has to be the drive number of files location +/- 1.

 

See: http://reboot.pro/to...er/#entry209844

http://reboot.pro/to...er/#entry209846

But the only condition that can satisfy all cases is:

 

Mapped drive number has to be the drive number of files location + 1.

 

See: http://reboot.pro/to...er/#entry209851

 

alacran



#169 wimb

wimb

    Platinum Member

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

Posted 11 March 2019 - 02:33 PM

Thanks alacran for reporting issue with WIMBOOT menu.lst entry for the case of VHD + WIM located on internal harddisk and booting from RAMDISK.

 

I am working now on other computer and have similar issue as you reported.

 

Thanks to Wonko for giving elegant solution  :worship: which is working here OK for that other computer.  

Next week I will be able to test on my original computer, but hopefully the menu.lst code will be good for that case too.

 

Thanks karyonix for help in finding a solution, but I think the code given by Wonko can be used quite well.


  • alacran likes this

#170 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 11 March 2019 - 04:01 PM

@Wonko

@ wimb

 

Well, after some more extensive tests this are my findings:

 

After all, my previous report was correct. I thought I was selected the wrong title, but it was not the case.

 

Having VHD and source wimboot wim file on (hd1,5)

 

8.1x64-WB.vhd do not matter what hd we map it Ramboots anyway, as on:

title 8.1x64-WB.vhd - SVBus  RAMDISK  - 1024 MB - map for WIMBOOT root (hd0,0)
find --set-root --ignore-floppies /8.1x64-WB.vhd
map --top --mem /8.1x64-WB.vhd (hd1)
map --hook
root (hd0,0)
chainloader /bootmgr

title 8.1x64-WB.vhd - SVBus  RAMDISK  - 1024 MB - map for WIMBOOT root (hd2,0)
find --set-root --ignore-floppies /8.1x64-WB.vhd
map --top --mem /8.1x64-WB.vhd (hd2)
map --hook
root (hd2,0)
chainloader /bootmgr

Also on wonko codes:

title 8.1x64-WB.vhd - SVBus RAMDISK - 1024 MB - map as disk+1 (FAKE)
find --set-root --ignore-floppies /8.1x64-WB.vhd
root | set myroot=
set mydisk=%myroot:~3,1%
map --top --mem /8.1x64-WB.vhd (hd%mydisk%)
map --hook
root (hd%mydisk%,0)
chainloader /bootmgr

title 8.1x64-WB.vhd - SVBus  RAMDISK  - 1024 MB - map as disk+1 (RIGHT)
find --set-root --ignore-floppies /8.1x64-WB.vhd
root | set myroot=
set /a mydisk=%mydisk%+1 
map --top --mem /8.1x64-WB.vhd (hd%mydisk%)
map --hook
root (hd%mydisk%,0)
chainloader /bootmgr

But 10x64-WB.vhd is another beast, it only Ramboots on this titles:

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map for WIMBOOT root (hd2,0)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd2)
map --hook
root (hd2,0)
chainloader /bootmgr

Or Wonko code:

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as disk+1 (RIGHT)
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

And DO NOT run on following:

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map for WIMBOOT root (hd1,0)
find --set-root --ignore-floppies /10x64-WB.vhd
map --top --mem /10x64-WB.vhd (hd1)
map --hook
root (hd1,0)
chainloader /bootmgr

Or Wonko code:

title 10x64-WB.vhd - SVBus RAMDISK - 1536 MB - map as disk+1 (FAKE)
find --set-root --ignore-floppies /10x64-WB.vhd
root | set myroot=
set mydisk=%myroot:~3,1%
map --top --mem /10x64-WB.vhd (hd%mydisk%)
map --hook
root (hd%mydisk%,0)
chainloader /bootmgr

Then the option to satisfy 10 also satisfy 8 , and it is:

 

 

So we may say for RamBooting a VHD from internal disks, we need to use hd number (according to grub4dos) where VHD is located + 1 in our menu.lst for grub4dos RamBoot.

 

As said on post No. 162

 

alacran



#171 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 March 2019 - 04:03 PM

Thanks karyonix for help in finding a solution, but I think the code given by Wonko can be used quite well.

 

To be fair, my code is (I believe) more readable, as it uses the common grub4dos convention of (hd0) first disk, (hd1) second disk, etc., BUT falls short in case (rare) there are more than 10 disks (i.e. any disk higher than (hd9)).

The code by karyonix uses the BIOS disk number, i.e. (128) first disk, (129) second disk, etc. and has not the same (not common to happen in practice) issue as mine.

 

:duff:

Wonko



#172 wimb

wimb

    Platinum Member

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

Posted 11 March 2019 - 04:37 PM

@alacran

 

The code given by Wonko and according to my tests working OK contains the two lines

set mydisk=%myroot:~3,1%
set /a mydisk=%mydisk%+1

wheras you published in post #170 only one of these lines, so it is difficult to decide which code you have found to be working ok and which one fails and why it fails

May be a typing error ?



#173 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 March 2019 - 05:11 PM

@alacran

 

The code given by Wonko and according to my tests working OK contains the two lines



set mydisk=%myroot:~3,1%
set /a mydisk=%mydisk%+1

wheras you published in post #170 only one of these lines, so it is difficult to decide which code you have found to be working ok and which one fails and why it fails

May be a typing error ?

 

And - not so surprisingly - we can make those a single line:

set /a mydisk=%myroot:~3,1%+1

though what alacran posted:

root | set myroot=
set /a mydisk=%mydisk%+1

cannot actually work (again typos/copy&paste error/whatever. :frusty:

mydisk is NOT DEFINED

 

:duff:

Wonko


  • wimb likes this

#174 alacran

alacran

    Silver Member

  • .script developer
  • 969 posts
  •  
    Mexico

Posted 11 March 2019 - 05:24 PM

@ wimb

 

In fact I deleted:    set mydisk=%myroot:~3,1%

 

And only used.

 

title 10x64-WB.vhd - SVBus  RAMDISK  - 1536 MB - map as disk+1 (RIGHT-1)
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

 

And it worked fine, I deleted intentionally the line, thinking it was not required in my case.

 

From Wonko post:

 

 

title W10x64_W82.vhd - SVBus RAMDISK - 2048 MB - map as disk+1
find --set-root --ignore-floppies /W10x64_W82.vhd <- let's say that the .vhd is on disk 1 (hd1,0)
root | set myroot= <- root and thus myroot value  is  (hd1,0)  Filesystem type bla bla bla ...
set mydisk=%myroot:~3,1% <- mydisk value becomes 1
set /a mydisk=%mydisk%+1 <- mydisk value becomes 2
map --top --mem /W10x64_W82.vhd (hd%mydisk%) <- this becomes map --top --mem /W10x64_W82.vhd (hd2)
map --hook
root (hd%mydisk%,0) <- this becomes root (hd2,0)
chainloader /bootmgr

 

I understud it this way:

 

1 - Use: set mydisk=%myroot:~3,1% <- mydisk value becomes 1 -----------------> If you want actual hd where VHD is located

 

2 - Use: set /a mydisk=%mydisk%+1 <- mydisk value becomes 2 ----------------> If you want actual hd where VHD is located + 1

 

Since from: root | set myroot= <- root and thus myroot value  is  (hd1,0)  Filesystem type bla bla bla ------> we are rooted on hd where VHD is located.

 

Anyway I already tested again without and with the line I errased, (just as Wonko example) and both ways Ramboot fine, it seems to me line 2 overwrites line 1.

 

alacran



#175 wimb

wimb

    Platinum Member

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

Posted 11 March 2019 - 06:01 PM

In fact I deleted:    set mydisk=%myroot:~3,1%

 

 

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

 

The single line that Wonko proposes is OK.

 

Tomorrow I will do some more testing ....







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

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users