Jump to content











Photo
- - - - -

GRUB4DOS for UEFI


  • Please log in to reply
421 replies to this topic

#201 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 December 2020 - 04:09 AM

@ liuzhaoyzz

 

Well, as now our fellow a1ive confirmed:

 

xz and gz. lz4 is not supported.

 

I want to comment something else to you, I saw in a post from you http://wuyou.net/for...75&pid=4192808 that you talk about NTFS compression and Compact mode compression.

 

And I want to share some info with you:

 

Comments about Compact mode installations and NTFS compresed installations.

 

NTFS compression is the lowest, and also very slow, - it uses a single core thread on CPU when compressing on a Win OS - almost every single file ends highly frgmented, a full defragmentation is highly recommended.

 

Compact mode compression - 8K is the new standard on recent 10 OS versions (it used to be 4K), it has always used all CPU cores threads, so it is faster and you get even on 4K a higher compression , in all cases (4K, 8K, 16K or LZX) all files end unfragmented, but the used espace could be not 100% contiguous, defragmentation is not required, (but I usually prefer to defragment the VHD content).

 

Why my interest on gzip and lz4 compression:

 

About the gzip or lz4 compression, lz4 is faster to compress and decompress than gzip, (recommended parameters -12 --content-size --favor-decSpeed), I ran several tests and found a lz4 compressed VHD loads to Ram faster.

 

From: http://reboot.pro/to...-faster-on-ram/

 


All test ran on same I3 3225, 3.3 GHZ, 8 GB Ram at 1333 MHZ, Rambooting from SSD Adata SU650 into Adata XPG enclosure 3.0 USB.

 

This are my findings:

 

Speed:

VHD                                Time to load on RAM

1 - 10x64-WB.vhd Ramboot using g4d grub4dos-0.4.6a-2018-12-23        12 seconds

2 - 10x64-WB.vhd.gz Ramboot using g4d grub4dos-0.4.6a-2018-12-23    7 seconds

3 - 10x64-WB-EXP.vhd Ramboot using g4d 0.4.5c Modd by kyrionix        4 seconds

4 - 10x64-WB.vhd.lz4 Ramboot using g4d grub4dos-0.4.6a-2019-03-25    3.67 seconds

 

 LZ4_Compressor  >>> (GUI for lz4) It can compress and decompress to/from lz4 any file not only VHDs.

 

And also lz4 helps to improve a lot the loading to Ram time when only are available USB 2.0 ports, additionally it saves a lot of espace on USB devices.

 

From same link:

Saved espace:

VHD				Used	Saved espace

10x64-WB.vhd			1536 MB	0 % saved espace

10x64-WB.vhd Expandable		480 MB	68.75 % saved espace

10x64-WB.vhd.gz			233 MB	84.83 % saved espace

10x64-WB.vhd.lz4		135 MB	91.21 % saved espace

Then my RamOS on VHD is usually installed on Compact LZX mode or on Wimboot mode (for low Ram PCs), And both lz4 compressed to save space and loading time.

 

Hope previous info could be useful for you my friend.
 

alacran



#202 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 16 December 2020 - 04:52 AM

@ liuzhaoyzz

Well, as now our fellow a1ive confirmed:



I want to comment something else to you, I saw in a post from you http://wuyou.net/for...75&pid=4192808 that you talk about NTFS compression and Compact mode compression.

And I want to share some info with you:

Comments about Compact mode installations and NTFS compresed installations.

NTFS compression is the lowest, and also very slow, - it uses a single core thread on CPU when compressing on a Win OS - almost every single file ends highly frgmented, a full defragmentation is highly recommended.

Compact mode compression - 8K is the new standard on recent 10 OS versions (it used to be 4K), it has always used all CPU cores threads, so it is faster and you get even on 4K a higher compression , in all cases (4K, 8K, 16K or LZX) all files end unfragmented, but the used espace could be not 100% contiguous, defragmentation is not required, (but I usually prefer to defragment the VHD content).

Why my interest on gzip and lz4 compression:

About the gzip or lz4 compression, lz4 is faster to compress and decompress than gzip, (recommended parameters -12 --content-size --favor-decSpeed), I ran several tests and found a lz4 compressed VHD loads to Ram faster.

From: http://reboot.pro/to...-faster-on-ram/


LZ4_Compressor >>> (GUI for lz4) It can compress and decompress to/from lz4 any file not only VHDs.

And also lz4 helps to improve a lot the loading to Ram time when only are available USB 2.0 ports, additionally it saves a lot of espace on USB devices.

From same link:

Saved espace:VHD				Used	Saved espace10x64-WB.vhd			1536 MB	0 % saved espace10x64-WB.vhd Expandable		480 MB	68.75 % saved espace10x64-WB.vhd.gz			233 MB	84.83 % saved espace10x64-WB.vhd.lz4		135 MB	91.21 % saved espace
Then my RamOS on VHD is usually installed on Compact LZX mode or on Wimboot mode (for low Ram PCs), And both lz4 compressed to save space and loading time.

Hope previous info could be useful for you my friend.

alacran
Thank you for your detailed explanation!

NTFS compress rate is about 70%.compact lzx is about 55%.
I think NTFS compress is stabler and more compatible than compact lzx.Some program/dll/exes run not well in compact lzx,but they run well in NTFS compress.I tested them under BIOS RAMOS.

It seems gz/lz4 is hard to modify,but vhd file can be easily modified,just boot with bootmgfw.efi,install program/drivers.So I am not very interested in gz/lz4,and I didn't try it for RAMOS.

Edited by liuzhaoyzz, 16 December 2020 - 04:59 AM.


#203 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 December 2020 - 05:19 AM

Thank you for your detailed explanation!

NTFS compress rate is about 70%.compact lzx is about 55%.
I think NTFS compress is stabler and more compatible than compact lzx.Some program/dll/exes run not well in compact lzx,but they run well in NTFS compress.I tested them under BIOS RAMOS.

It seems gz/lz4 is hard to modify,but vhd file can be easily modified,just boot with bootmgfw.efi,install program/drivers.So I am not very interested in gz/lz4,and I didn't try it for RAMOS.

 

We use the attached custom WimBootCompres.ini (valid from 7 to 10) and apply the OS using wimlib, we can include on [PrepopulateList] all those files that we want to be deployed fully uncompressed or as real files on Wimboot mode.

 

I think the idea of running a RamOS is keep a immutable VHD, that always boots in a pristine state, if not better run it from a uncompressed file as Filedisk, directly booting with Win bootmanager, and then we don't need to use SvBus + G4E or grub2

 

But of course it is a matter of preferences.

 

alacran

Attached Files

  • Attached File  File.7z   1.19KB   1069 downloads


#204 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 16 December 2020 - 05:46 AM

We use the attached custom WimBootCompres.ini (valid from 7 to 10) and apply the OS using wimlib, you can include on [PrepopulateList] all those files that you want to be deployed fully uncompressed or as real files on Wimboot mode.

I think the idea of running a RamOS is keep a immutable VHD, that always boots in a pristine state, if not better run it from a uncompressed file as Filedisk, directly booting with Win bootmanager, and then we don't need to use SvBus + G4E or grub2

But of course it is a matter of preferences.

alacran

We used WimBootCompres.ini in WIN7/8/10 wimboot just like you, It need a lot of technology and experience to maintain the [PrepopulateList],various Windows version,various programs,the list cost me a lot of time to test,for the stability and the compatiblity,under BIOS-RAMOS.

We used microsoft dependency walker and other tools to find out the exe/dlls dependency.It is really a hard work.

Edited by liuzhaoyzz, 16 December 2020 - 05:56 AM.


#205 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 December 2020 - 05:47 AM

On [PrepopulateList] almost all lines belong to Win excluding the following two lines:  

 

\Windows\System32\pwdrvio.sys
\Windows\System32\pwdspio.sys

 

Created for PartitionWizard v9.x, if they are compressed or are pointers in case of Wimboot, the boot fails

 

alacran



#206 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 December 2020 - 06:06 AM

We used WimBootCompres.ini in WIN7/8/10 wimboot just like you, It need a lot of technology and experience to maintain the [PrepopulateList],various Windows version,various programs,the list cost me a lot of time to test,for the stability and the compatiblity,under BIOS-RAMOS.

We used micrisoft dependency walker and other tools to find out the exe/dlls dependency.It is really a hard work.

 

Yes, you are right my friend, your arguments are good, now I understand why you recommend NTFS compression, and don't use additional gz or lz4 compression, no need to worry about potential issues or if the user wants to install latter additional programs after creating the VHD.

 

That way it is a trouble free installation.

 

I usually install all I can need (preferable external portables) before capture and reinstall, and I don't install additional programs latter.

 

But there is WOF_Compress  by wimb to recompress if required.

 

alacran



#207 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 299 posts

Posted 16 December 2020 - 07:23 AM

Hello,

 

Still trying to figure out the reason of the error out of map memory. I created a small VHD sized 100 Mb. It contains only a blank FAT32 partition ( GPT disk )  I get again the same error message. Simply, converting GPT to MBR solved the problem. It looks like that --mem option of the map command does not like GPT disks.

Attached Thumbnails

  • test.PNG


#208 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 16 December 2020 - 06:35 PM

Now we can use MBR + NTFS single actived partition to boot svbus RAMOS

1、g4e 2020-12-15 version or later

it is necessary to load ntfs_x64.efi driver with load /EFI/grub/ntfs_x64.efi, otherwise g4e will get the error of "boot_image_handle not found".

title WIN7X64-SVBUS (/VHD/SX70211.vhd)
load /EFI/grub/ntfs_x64.efi
find --ignore-floppies --ignore-cd --set-root /VHD/SX70211.vhd
map --mem --top /VHD/SX70211.vhd (hd)
chainloader (hd-1)
 
2、grub2 2020-12-17 version
you need to edit grub2-latest 2020-12-17 \ arch \ x64 \ builtin.txt, add efiload module, customize grubx64.efi with build_grub.bat, and then load ntfs_x64.efi driver with efiload /EFI/grub/ntfs_x64.efi, otherwise g4e will back to menu when g4e is loading
menuentry "SX70211.vhd" "/VHD/SX70211.vhd" {
        efiload /EFI/grub/ntfs_x64.efi
        search --no-floppy --set --file $2
        map --mem --rt $2
}
 
I have updated the tutorial.

Edited by liuzhaoyzz, 16 December 2020 - 06:38 PM.

  • wimb and alacran like this

#209 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 December 2020 - 03:08 AM

JFYI

 

About the ntfs_x64.efi, we can find it in:

 

You could download NTFS driver from rEFInd project: https://sourceforge....rojects/refind/

pbatard's NTFS driver doesn't work on my PC.

 

Last rEFInd version that contains the ntfs_x64.efi is v11.4:  Download  refind-cd-0.11.4.zip (6.11 MB) from:  refind-cd-0.11.4.zip

 

The driver is located on: refind-cd-0.11.4.zip\refind-cd-0.11.4.iso\refind\drivers_x64\ntfs_x64.efi

 

alacran


  • wimb likes this

#210 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 December 2020 - 04:28 AM

Grub4dos-for_UEFI-2020-12-15 Test Report

 

Tested booting as Ramdisk and Filedisk and all booted fine (ntfs_x64.efi not used):

 

Win10XPE_x64.iso

Win10XPE_x64.vhd  >>> Single partition FAT-32

Mini-10-UEFI-WB.vhd  >>>  2 partitions (64MB FAT-32 + NTFS)

Mini-10x64-2004-2.vhd>>>  2 partitions (64MB FAT-32 + NTFS)

 

Grub4dos-for_UEFI-2020-12-15 + ntfs_x64.efi Test Report

 

Mini-10x64-2004.vhd  >>> Single partition NTFS Active booted very fine  >>> 2004 - release.191206-1406

 

Booted very fine.

 

title Mini-10x64-2004.vhd (2360 MB only NTFS) as RAMDISK UEFI boot from HD
load /EFI/grub/ntfs_x64.efi
find --ignore-floppies --ignore-cd --set-root /Mini-10x64-2004.vhd
map --mem --top /Mini-10x64-2004.vhd (hd)
chainloader (hd-1)

 

Used ntfs_x64.efi  mentioned on my previous post.

 

NOTE: I will update the English translation of liuzhaoyzz Tutorial and reupload it ASAP.

 

alacran


  • wimb likes this

#211 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 17 December 2020 - 04:52 AM

Grub4dos-for_UEFI-2020-12-15 Test Report

Tested booting as Ramdisk and Filedisk and all booted fine (ntfs_x64.efi not used):

Win10XPE_x64.iso
Win10XPE_x64.vhd >>> Single partition FAT-32
Mini-10-UEFI-WB.vhd >>> 2 partitions (64MB FAT-32 + NTFS)
Mini-10x64-2004-2.vhd>>> 2 partitions (64MB FAT-32 + NTFS)

Grub4dos-for_UEFI-2020-12-15 + ntfs_x64.efi Test Report

Mini-10x64-2004.vhd >>> Single partition NTFS Active booted very fine >>> 2004 - release.191206-1406

title Mini-10x64-2004.vhd (2360 MB only NTFS) as RAMDISK UEFI boot from HD
load /EFI/grub/ntfs_x64.efi
find --ignore-floppies --ignore-cd --set-root /Mini-10x64-2004.vhd
map --mem --top /Mini-10x64-2004.vhd (hd)
chainloader (hd-1)

Used ntfs_x64.efi mentioned on my previous post.

NOTE: I will update the English translation of liuzhaoyzz Tutorial and reupload it ASAP.

alacran


Good report!

Thank you for your translation!
  • alacran likes this

#212 wimb

wimb

    Platinum Member

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

Posted 17 December 2020 - 05:02 AM

JFYI

 

About the ntfs_x64.efi, we can find it in:

 

 

Last rEFInd version that contains the ntfs_x64.efi is v11.4: https://sourceforge....4.zip/download (6.11 MB)

 

The driver is located on: refind-cd-0.11.4.zip\refind-cd-0.11.4.iso\refind\drivers_x64\ntfs_x64.efi

 

alacran

 

Thanks for interesting info on NTFS efi driver

 

The download link does not work, but can be given as refind-cd-0.11.4.zip



#213 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 December 2020 - 05:34 AM

Thanks wimb, already fixed.

 

Grub4dos-for_UEFI-2020-12-15 + ntfs_x64.efi (from Rufus) Test Report

 

The VHD fail to boot:

 

Mini-10x64-2004.vhd  >>> Single partition NTFS Active booted very fine  >>> 2004 - release.191206-1406

 

title Mini-10x64-2004.vhd (2360 MB) Rufus as RAMDISK UEFI boot from HD NTFS
load /EFI/grub/ntfs_x64-R.efi
find --ignore-floppies --ignore-cd --set-root /Mini-10x64-2004.vhd
map --mem --top /Mini-10x64-2004.vhd (hd)
chainloader (hd-1)

 

Used ntfs_x64.efi from Akeo (Rufus) renamed to ntfs_x64-R.efi: https://efi.akeo.ie/...64/ntfs_x64.efi

 

The VHD was loaded to Ram but I got the message: Boot_image_handle not found, this means the driver do not work fine with G4E

 

alacran



#214 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 December 2020 - 01:52 PM

I want to comment about the use of ntfs_x64.efi from rEFInd:

 

The fact that this driver allows us boot a single partition NTFS VHD, does not mean we should stop using the new 2 partition layout for VHDs.

 

Last available version is from 2018 and it seems it's not under development anymore, so sooner or latter I expect it will not work on new 10 versions, so I strongly suggest to try and use it with your already made single NTFS partition VHDs only.

 

To be on the safe side it is better to make all new VHDs with the new 2 partitions layout.

 

EDIT: It is a shame the ntfs_x64.efi driver from Akeo (Rufus), which is under active development yet, do not work fine under grub4dos for UEFI, the version tested is the newest, from 2020-11-18.

 

alacran



#215 wimb

wimb

    Platinum Member

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

Posted 17 December 2020 - 01:55 PM

UEFI Grub2 and UEFI Grub4dos booting Win8x64 UsedSize=2.33 GB in VHD from RAMDISK using signed SVBus driver is working OK  :)

 

attachicon.gifUEFI_Grub2_RAM_W8x64_2020-12-15_193515.jpg

 

:cheers:

 

UEFI Grub2 and UEFI Grub4dos booting USB SSD with Mini-7x64 UsedSize=1.93 GB in VHD from RAMDISK using signed SVBus driver is working OK   :)

 

:1st:  :cheerleader:  :magic:  :worship:  UEFI RAMOS 7x64 UsedSize=1.93 GB in VHD

 

UEFI_G4E_RAMOS_Mini-7x64_VHD_2020-12-17_144349.jpg

 

:cheers:



#216 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 December 2020 - 03:00 PM

Grub4dos-for_UEFI-2020-12-15 additional test

 

Mini8x64.vhd 2.3 GB 2 partitions MBR (FAT-32 active is 64 MB, NTFS the rest) RamOS booted fine, it is 8.1x64 reduced and installed as Compact LZX mode:

 

title Boot  /Mini8x64.vhd (2360 MB) as RAMDISK UEFI boot from HD
find --set-root --ignore-floppies --ignore-cd /Mini8x64.vhd
map --mem --top /Mini8x64.vhd (hd)
chainloader (hd-1)

 

FAT-32 used espace  = 11.2 MB            NTFS used espace = 1.61 GB

 

alacran

Attached Thumbnails

  • Mini8x64.png

  • wimb likes this

#217 wimb

wimb

    Platinum Member

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

Posted 19 December 2020 - 06:59 AM

How to return from UEFI Grub4dos back to Grub2 Menu ?

 

Chainloading UEFI Grub4dos from Grub2 works quite well and UEFI Grub4dos Menu is displayed.

 

The reverse does not work, it means chanloader Grub2 from UEFI Grub4dos results in Grub2 commandline and Grub2 Menu is not displayed.

 

How come ?

 

It turns out that root and prefix does not get the right value.

 

root is set to disk hd0 whereas it should be set to partition hd0,1

prefix is set to (hd0)/grub whereas it should be set to (hd0,1)/grub

 

After setting the right values in root and prefix then everything is working ok

Now we can arrive at Grub2 menu by using

configfile $prefix/grub.cfg

IMG_20201219_071055.jpg == IMG_20201219_071126.jpg == IMG_20201219_071204.jpg

 

Is it possible to Fix UEFI Grub4dos so that chainloader Grub2 will display the Grub2 Menu ?



#218 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 December 2020 - 07:28 AM

If you boot to G2 and chainload to G4E, and want to go back to G2 just exit G4E and you return to the G2 menu.

 

title Exit grub4dos
exit_g4d

 

alacran



#219 wimb

wimb

    Platinum Member

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

Posted 19 December 2020 - 07:34 AM

If you boot to G2 and chainload to G4E, and want to go back to G2 just exit G4E and you return to the G2 menu.

 

title Exit grub4dos
exit_g4d

 

 

Yes this works OK and also you can use

title Return to Boot Manager
chainloader

But it remains strange that 

title Grub2 Commandline - chainloader /efi/boot/grubx64_real.efi
find --set-root /grub/grub.cfg
chainloader /efi/boot/grubx64_real.efi

results in wrong settings  of root and prefix

 

 

root is set to disk hd0 whereas it should be set to partition hd0,1

prefix is set to (hd0)/grub whereas it should be set to (hd0,1)/grub

 

I think this might be fixed in UEFI Grub4dos



#220 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 20 December 2020 - 11:18 PM

English translation of updated liuzhaoyzz Tutorial.

 

With all due respect to our friend liuzhaoyzz  IMHO I think it is better to make all our new VHDs with 2 partitions, MBR (FAT-32 Active 64 to 100 MB + NTFS the rest).

 

From: http://reboot.pro/to...e-9#entry217428

I want to comment about the use of ntfs_x64.efi from rEFInd:

 

The fact that this driver allows us boot a single partition NTFS VHD, does not mean we should stop using the new 2 partition layout for VHDs.

 

Last available version is from 2018 and it seems it's not under development anymore, so sooner or latter I expect it will not work on new 10 versions, so I strongly suggest to try and use it with your already made single NTFS partition VHDs only.

 

To be on the safe side it is better to make all new VHDs with the new 2 partitions layout.

 

EDIT: It is a shame the ntfs_x64.efi driver from Akeo (Rufus), which is under active development yet, do not work fine under grub4dos for UEFI, the version tested is the newest, from 2020-11-18.

 

alacran

 

For more info about ntfs_x64.efi driver, and the link to download it, see this Post.

 

alacran

Attached Files


  • wimb and liuzhaoyzz like this

#221 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 299 posts

Posted 21 December 2020 - 02:07 PM

Hello,

 

Here is my report. The size of the VHD is reduced to 11 Gb. Memory allocated to 17 Gb.

 

Testing  the setup :

 

Mbr disk , 100 Mb FAT 32 Active + the rest NTFS, Boot as filedisk -> BSOD 0xc000000E 

Mbr disk ,100 Mb FAT 32 Active + the rest NTFS, Boot to RAM -> BSOD 0xc000000E 

 

Another test :

 

Gpt disk , 100 Mb FAT 32  + Rest NTFS, Boot as filedisk -> Successfull
Gpt disk , 100 Mb FAT 32  + Rest NTFS, Boot to Ram , out of map memory error message by UEFI grub4dos


#222 wimb

wimb

    Platinum Member

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

Posted 22 December 2020 - 10:31 AM

 

Hello,

 

Here is my report. The size of the VHD is reduced to 11 Gb. Memory allocated to 17 Gb.

 

Testing  the setup :

 

Mbr disk , 100 Mb FAT 32 Active + the rest NTFS, Boot as filedisk -> BSOD 0xc000000E 

Mbr disk ,100 Mb FAT 32 Active + the rest NTFS, Boot to RAM -> BSOD 0xc000000E 

 

Another test :

 

Gpt disk , 100 Mb FAT 32  + Rest NTFS, Boot as filedisk -> Successfull
Gpt disk , 100 Mb FAT 32  + Rest NTFS, Boot to Ram , out of map memory error message by UEFI grub4dos

 

 

BSOD 0xc000000E  indicates BCD error

 

Use BOOTICE to Inspect EFI\Microsoft\Boot\BCD on internal VHD FAT32 and on external Boot Drive

Show Screenshots in MBR case of your VHD BCD internal and external entries in BOOTICE Easy mode and Professional mode

 

What tools did you use in MBR case to make BCD Boot files ?

Where is your VHD located (internal SSD / USB SSD - NTFS ) ?

Where is your Boot Drive located (internal SSD / USB SSD - FAT32 ) ?



#223 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 299 posts

Posted 22 December 2020 - 11:25 AM

Hello wimb,

 

I don't use any USB dive. All everything goes to my internal disk. While working with the MBR disk layout, I used the following command to create the BCD file

bcdboot F:\Windows /s E: /f ALL

The latest setup is the GPT partitioning scheme. Attached are the screenshots taken from this setup. ( E ->  FAT32 , F -> NTFS )

Attached Thumbnails

  • bcd1.PNG
  • bcd2.PNG
  • bcd3.PNG


#224 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 22 December 2020 - 12:36 PM

English translation of updated liuzhaoyzz Tutorial.

 

With all due respect to our friend liuzhaoyzz  IMHO I think it is better to make all our new VHDs with 2 partitions, MBR (FAT-32 Active 64 to 100 MB + NTFS the rest).

 

From: http://reboot.pro/to...e-9#entry217428

 

For more info about ntfs_x64.efi driver, and the link to download it, see this Post.

 

alacran

alacran,

    Thank you for your translation.You can modify it with your own opinion.It doesn't matter.

 

If the ntfs_x64.efi driver work fine,VHD with 1 partition will be simpler than 2 partitions IMHO.

Because you must edit the BCD in the VHD and the BCD in the real disk carefully.If the BCD has fault,you will get some strange error like 0xc000000f,0xc000000e and so on.

 

I test ntfs_x64.efi driver work fine on 2 PCs.


Edited by liuzhaoyzz, 22 December 2020 - 12:42 PM.


#225 wimb

wimb

    Platinum Member

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

Posted 22 December 2020 - 01:20 PM

Hello wimb,

 

I don't use any USB dive. All everything goes to my internal disk. While working with the MBR disk layout, I used the following command to create the BCD file

bcdboot F:\Windows /s E: /f ALL

The latest setup is the GPT partitioning scheme. Attached are the screenshots taken from this setup. ( E ->  FAT32 , F -> NTFS )

 

This is the way to make BCD on VHD internal FAT32 drive.

 

But what about your hidden EFI bootdrive of GPT internal disk mounted as drive Z: and your VHD mounted as drive E: FAT32, F: NTFS

bcdboot F:\Windows /s Z: /f UEFI

What does this BCD needed to boot the VHD given as  Z:\EFI\Microsoft\Boot\BCD looks like in BOOTICE ?

In this BCD you need to create BCD entry for the VHD filename.

 

You see you need to make two BCD entries: a VHD internal BCD entry for VHD Windows and a VHD external BCD entry for the VHD filename.

 

Or much easier use UEFI_MULTI or VHD_WIMBOOT to make boot entry for VHD .....






2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users