262 replies to this topic

[alacran]

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

[Wonko the Sane]

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

Wonko

[karyonix]

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

[alacran]

 

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) 
 

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

[wimb]

 

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.

[Wonko the Sane]

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


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


Wonko

[steve6375]

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

[alacran]

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


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

• 
• 

[alacran]

@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

[steve6375]

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

[steve6375]

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?

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

[alacran]

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.

[steve6375]

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?

[alacran]

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

[steve6375]

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?

[alacran]

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.

[wimb]

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   More Info here

[wimb]

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.

[alacran]

@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

[alacran]

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

[wimb]

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

 

Download -  coming later

 

== 

[alacran]

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

• 
• 
• 
• 
• 
• 

[wimb]

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

[alacran]

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