1025 replies to this topic

[wimb]

There is something wrong on UEFI_MULTI v4.5.

 

I recicled a 3 GB VHD with two partitions deleting both partitions and making a single NTFS partition with Win10 tools, then rebooted from Win10XPE_x64 to deploy the WIM file and decided to do it with UEFI_MULTI v4.5, to test this new version, but just after it mounted the VHD it stop working and showed a message, after acepting the message UEFI_MULTI v4.5 closed immediately, please see attached pictures.

 

On first picture I selected to keep the VHD mounted, and didn't make any other change, on second intent after reformating the NTFS partition with Win10 and unmount the VHD, I didn't select to keep the VHD mounted but selected 1 partition just to check if this time it was able to finish the task, but the result was the same.

 

 

The report is about VHD_WIMBOOT-45 and not UEFI_MULTI v4.5 

 

I tried to reproduce, but in my case I don't get the message.

There was no Mounting VHD file related change in version 45 as compared to previous versions.

 

The message is normal to occur in case your VHD file was mounted in advance of using VHD_WIMBOOT.

In that case simply unmounting the VHD will solve the issue.

 

The 1 Partition setting is used in case of creating New VHD, but has no influence in case of selecting existing VHD file.

The Keep Mounted setting is used when VHD_WIMBOOT finishes to keep the processed VHD mounted, but that setting is not involved when you get the message.

 

In any case check what drives occur before using VHD_WIMBOOT and Unmount Drives related to VHD files.

May be you try again with other New VHD MBR 1 Partition Fixed VHD made with VHD_WIMBOOT.

Can you give VHD_WIMBOOT-45\makebt\wim_info\vhdlist.txt in case of trouble when you get the message 

 

I will keep trying to get the message in case of Unmounted VHD, but until now it did not occur in my case.

[alacran]

Yes you are right it is about VHD_WIMBOOT-45. Allready edited my previous post to avoid confusion to future readers.

 

Could it be caused because the VHD was empty?

 

I'll try again and let you know.

 

alacran

[alacran]

@ wimb

 

New test, same failure. This time this is an empty 3.5 GB VHD, single partition NTFS active, tried twice, attached pictures and the files you requested from both intents.

 

I made sure the VHD was not attached before running VHD_WIMBOOT-45 (on first and second intents), and I got same message just after the program mounted the VHD, made a copy of the vhdlist.txt, before acepting the message, after acepting the message I closed the program (it didn't close as I said before, sorry), unmounted the VHD and tried again.

 

Finally I deleted the VHD and let VHD_WIMBOOT-45 create a new 3.5 GB 2 partitions VHD and all was successful.

 

EDIT: It Rambooted fine too, see: http://reboot.pro/to...-11#entry217565

 

alacran

Attached Thumbnails

• 
• 
• 

Attached Files

•  vhdlists.7z   1.31KB   836 downloads

[antonino61]

@ alacrán (and wimb)

 

sorry to butt in, but I wonder why u did not let vhd_wimboot make its own vhd (and then change its name as u see fit) instead of using the old one. I also tried to do the same as u with one partition only thru so many previous editions of vhd_wimboot, and I don't remember one single time it has ever worked. I also remembered asking wimb about it and he said "better let vhd_wimboot do it on its own" - It hardly ever has failed. fair enough for me as I changed the name to my own liking at the end of the process. I have not tried to apply a wim to an old vhd anymore for the past 3 editions now.  

[alacran]

Then after reading your Post, this means something is wrong since some versions ago, I'm only informing my findings to wimb to let him know about the issue.

 

But yes, in the meantime your proposal is a good solution, unfortunately some sizes are not available on the program.

 

alacran

[antonino61]

Same here, I reported that to wimb, as I wanted smaller sizes than 1gb for vhd+wim combos, but he said why should I bother making vhd's smaller than 1gb, and in view of ur theory and findings, he might be right. anyway, how about vhd_resizer? I use that when I am not happy with the resulting size.

 

As for your "something wrong with...", I am not sure I have understood u correctly: if u r talking of updating and booting-remaking, it has always worked, including this last version; if u r talking of applying wim to vhd, as I told u above, it has never rebooted ok (most common errors being winload.exe or the system part of the registry).

[alacran]

how about vhd_resizer? I use that when I am not happy with the resulting size.

 

As for your "something wrong with...", I am not sure I have understood u correctly: if u r talking of updating and booting-remaking, it has always worked, including this last version; if u r talking of applying wim to vhd, as I told u above, it has never rebooted ok (most common errors being winload.exe or the system part of the registry).

 

In the especific case you want a certain exact size on VHD, it is faster and easier to make your VHD manually only once and apply the WIM image with wimlib-clc and you may use latter UEFI_MULTI to make the enties on BCDs and menu.lst, and also on grub.cfg (if you use it).

 

But to increase the size of a VHd it is very easy to do it on command line, as an example to expand the 3.8 GB to 4000 MB, (one line at the time):

 

DiskPart
Select vdisk file = H:\VHD\10x64-38.vhd
expand vdisk maximum=4000      >>> Final Size, Always on MB.

exit

exit

 

Then just mount it and using Disk management (diskmgmt.msc) just expand the internal partition and that's all. Of course it is always good to defragment the VHD file.

 

vhd_resizer in fact creates a new VHD and just clone the content from the previous to it. And in some cases this may be a long process.

 

alacran

[wimb]

Update VHD_WIMBOOT-46-E

 

Download:  from wimb GitHub  -    VHD_WIMBOOT-46-E

 

Download File E = Encrypted Password = bootwimb

 

- Always Shut-Off AntVirus Software and Disable Windows Defender when working with signed SVBus driver !!

otherwise wimlib and Boot errors will occur .....

 

- STOP - VHD Drive Not Found issue in case of empty drive solved

  issue caused by testing for Windows folder in Mounted VHD - issue present since version 41 with support for 2 partition VHD

  the STOP - VHD Drive Not Found error occurs when Windows folder was not present

 

Thanks alacran for reporting error     

 

- UEFI_MAN\EFI\grub\tools will be copied to \EFI\grub\tools on Boot Drive if \EFI\grub\tools does not exist

- autoload of CrScreenshotDxe.efi in case of booting with Grub2 and the chainloaded UEFI Grub4dos

- requires update of existing \grub\grub.cfg according to:

if [ "${grub_platform}" == "efi" ] -a [ -e "/EFI/BOOT/BOOTx64.EFI" ]; then
	efiload /EFI/grub/tools/CrScreenshotDxe.efi
	menuentry "Reboot EFI Main Menu - ScreenShot - Use Left Ctrl + Left Alt + F12" {
	  chainloader /EFI/BOOT/BOOTx64.EFI
}
fi
 

 To take ScreenShot - Use Left Ctrl + Left Alt + F12 - ScreenShot saved on FAT32 drive

menuentry Reboot EFI Main Menu is just (mis)used to present Info to the user on how to take ScreenShot 

 

- Update UEFI Grub4dos as file UEFI_MAN\EFI\Boot\bootx64_g4d.efi from version 2020-12-31 BOOTX64_ok.rar

  solves 2 GB VHD size limit for RAMOS as occurring in case of hardware corresponding to alacran

 

- makebt\WimBootCompress.ini files adjusted so that VHD internal Boot and EFI folder are Excluded from Capture of WIM file

 

[ExclusionList]

....
\bootmgr
\BOOTNXT
\Boot
\EFI
\x-*Boot
\x-*EFI

[antonino61]

latest vhd_wimboot working ok

[wimb]

latest vhd_wimboot working ok

 

You mean all earlier encountered problems have been solved. That's nice 

[antonino61]

no no no, ahahhah, I meant this one worked ok too, as I did with all the previous ones.

 

btw, I have just discovered that lz4 files preramload faster if u add -B7 to the other parameters upon vhd compression in Alacrán's lz4compressor.

[alacran]

 

Update VHD_WIMBOOT-46-E

 

 

Thanks my friend, just downloaded and will test it later, I assume all is fine now, as it have being always, with only previous exception.

 

Even if the user is able to make all the process manually, it is good to have this tool to make a new build automatically, and don't have to make everything manually as there are many steps, and it is boring and time consuming doing it manually, and there is always the possibility to forget to update/create some of the entries to make it boot.

 

alacran

[alacran]

Just a hint for other users:

 

After download, (with the AV disabled) extract it and rename the folder to only VHD_WIMBOOT deleting the -46 (or any number it will be latter), and copy it to the final location when you will use it usually, create an empty text folder as Version-4.6.txt (in this case) into that folder, and create an exception on your AV for this VHD_WIMBOOT folder, doing this way on new versions you will not have to change the folder name on the AV exceptions on every new version, and also same shortcut on your desktop will work with any new version.

 

Of course this trick works fine for other portable programs too.

 

alacran

[alacran]

 

Update VHD_WIMBOOT-46-E

 

 

Just tested with a manually made 1640 MB VHD single NTFS partition, and all working fine.

 

alacran

[wimb]

Update VHD_WIMBOOT-47-E

 

Download:  from wimb GitHub  -    VHD_WIMBOOT-47-E

 

Download File E = Encrypted Password = bootwimb

 

- Always Shut-Off AntVirus Software and Disable Windows Defender when working with signed SVBus driver !!

otherwise wimlib and Boot errors will occur .....

 

- Update Grub2 to latest version

- Added Checkbox Update G - Forces Update of UEFI Grub2 and UEFI Grub4dos and MBR Grub4dos Boot files

- Added UEFI Grub2 menuentry using ntboot instead of efiload ntfs_x64.efi driver in case of 1 Partion VHD for RAMOS booting

- Added WARNING in case FileSystem of existing VHD is not FAT32 + NTFS in case of 2 Partitions Or NTFS in case of 1 Partition VHD

menuentry "Boot /1P_10_NT.vhd - UEFI Grub2 ntboot SVBus  RAMDISK  - 3.0 GB" {
  search --file --set=vhd_drive --no-floppy /1P_10_NT.vhd
  map --mem --rt ($vhd_drive)/1P_10_NT.vhd
  ntboot --win --highest=no --efi=(vd0,1)/EFI/Microsoft/Boot/bootmgfw.efi --winload=\\Windows\\System32\\winload.efi (vd0,1)
}

Disadvantage of UEFI Grub2 ntboot is that Display resolution is fixed in my case to 1280x1024 (aspect ratio is deformed - not good)

I prefer the normal UEFI Grub2 boot or even better the faster loading UEFI Grub4dos

 

EDIT: ntboot option --highest=no  solves the resolution issue

 

[alacran]

Hey my friend you are very fast!

 

When booting from a single NTFS VHD and previously loading ntfs_x64.efi, I have found 2 or maybe 3 times that it boots fine but there is no mouse and the keyboard is dead, but the PC button to shut off works fine, usually rebooting fixes the issue, but so far I haven't noticed this when booting from a 2 partitions VHD.

 

I will download and test it, but after reading your comments I think I will not like ntboot too.

 

Have you tried setting a resolution of lets say 1600x900 for the grub.cfg to test if the RamOS inherits that resolution when booting with ntboot?

 

Edit: Well, this means after all the 2 partitions VHD is the best option, as this way no additional driver is required.

 

alacran

[wimb]

Have you tried setting a resolution of lets say 1600x900 for the grub.cfg to test if the RamOS inherits that resolution when booting with ntboot?

 

Edit: Well, this means after all the 2 partitions VHD is the best option, as this way no additional driver is required.

 

 

I have tried 

set gfxmode=1920x1080,auto
set gfxpayload=keep

but ntboot still results in graphics mode 1280x1024 which is not adjustable anymore .....

[alacran]

AFAIK ntboot was made by Chenall long time ago to boot VHD and also WIM files, and he last updated it on 2014 (up to Win 8), steve6375 has found it do not work fine with some Win 10 bootmanger versions, on his E2B he recomends to use Win 8 bootmanager to boot fine VHD or Wim files, and during install it is downloaded with JFX 's Get Waik Tools.

 

As the original from Chenall used to work from Win 2000 to Win 8, it is very possible its max resolution is then 1280x1024.

But it is hard to believe a1ive hasn't  extended its resolution capabilities when he added it to his grub2 version.

 

alacran

[antonino61]

Update VHD_WIMBOOT-47-E

 

Download:  from wimb GitHub  -    VHD_WIMBOOT-47-E

 

- Added Checkbox Update G - Forces Update of UEFI Grub2 and UEFI Grub4dos and MBR Grub4dos Boot files

 

I still have the non-uefi version of g4d

What happens if I check the Update G boxlet? Will I still be able to boot ok, will I boot faster, or will I not boot at all anymore?

[wimb]

I still have the non-uefi version of g4d

What happens if I check the Update G boxlet? Will I still be able to boot ok, will I boot faster, or will I not boot at all anymore?

 

Update G checkbox when selected will not cause problems. You don't use the UEFI Grub2 and UEFI Grub4dos files.

 

In case of MBR booting you will experience that MBR Grub4dos Boot files are Updated and Grub4dos entry in Windows Boot Manager is recreated and set as default.

[wimb]

Update VHD_WIMBOOT-47-E

 

Download:  from wimb GitHub  -    VHD_WIMBOOT-47-E

 

Download File E = Encrypted Password = bootwimb

 

- Always Shut-Off AntVirus Software and Disable Windows Defender when working with signed SVBus driver !!

otherwise wimlib and Boot errors will occur .....

 

- Update Grub2 to latest version

- Added Checkbox Update G - Forces Update of UEFI Grub2 and UEFI Grub4dos and MBR Grub4dos Boot files

- Added UEFI Grub2 menuentry using ntboot instead of efiload ntfs_x64.efi driver in case of 1 Partion VHD for RAMOS booting

- Added WARNING in case FileSystem of existing VHD is not FAT32 + NTFS in case of 2 Partitions Or NTFS in case of 1 Partition VHD

menuentry "Boot /1P_10_NT.vhd - UEFI Grub2 ntboot SVBus  RAMDISK  - 3.0 GB" {
  search --file --set=vhd_drive --no-floppy /1P_10_NT.vhd
  map --mem --rt ($vhd_drive)/1P_10_NT.vhd
  ntboot --win --highest=no --efi=(vd0,1)/EFI/Microsoft/Boot/bootmgfw.efi --winload=\\Windows\\System32\\winload.efi (vd0,1)
}

Disadvantage of UEFI Grub2 ntboot is that Display resolution is fixed in my case to 1280x1024 (aspect ratio is deformed - not good)

I prefer the normal UEFI Grub2 boot or even better the faster loading UEFI Grub4dos

 

EDIT: ntboot option --highest-no  solves the resolution issue

 

VHD_WIMBOOT_47_2021-01-04_100522.jpg

 

ntboot option --highest=no  solves the resolution issue

 

please redownload updated VHD_WIMBOOT-47

[alacran]

@ wimb

 

There is something that do not match on your previous post:

 

You say you are using: ntboot option --highest-no

 

But the info on the link mentioned in your post says: --highest=no

 

alacran

[wimb]

@ wimb

 

There is something that do not match on your previous post:

 

You say you are using: ntboot option --highest-no

 

But the info on the link mentioned in your post says: --highest=no

 

alacran

 

Is language issue. English translated says --highest-no which is working in my case ....

 

got to check what grub2 says about ntboot

 

EDIT:  yes you are right - the ntboot option is --highest=no

[alacran]

Attached is a picture of the post just as seen on chinese, and it made me think it was a typo. And just tried to let you know as soon as I saw it.

 

I belive in your info, if it works for you it is ok then. Edit: It seems it was in fact a typo, good thing is it is solved now, before creating issues to the users of the program.

 

alacran

Attached Thumbnails

• 

[wimb]

ntboot option --highest=no is the right option that solves the resolution issue

 

please redownload updated VHD_WIMBOOT-47