Jump to content











Photo
- - - - -

Summary of new tools for UEFI and MBR/CSM boot and Ramboot

mbr csm uefi grud4dos grub2 ramboot

  • Please log in to reply
20 replies to this topic

#1 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 24 July 2021 - 06:44 PM

This topic will be dedicated to all the recent tools we have now to boot on UEFI and MBR/CSM environments.

 

Many of this info is dispersed in a lot of topics and posts in this forum, and I thing it is not a bad idea to have at least a single location with a summary with quotes and links, that can help the readers know what is possible to do with this tools, and also what is not possible to do (at least so far).

 

Also will include a comparative of the options available to get desired results, and alternatives available to let us use the best features of a first loader and chainload to a second loader to also use its best features, to gain improved speed and use certain features not available on the initial loader.

 

The more known projects available so far are (in alphabetical order):

 

a1ve Grub2 - link on the forum - link on the Web

a1ive grub2-filemanager - link on the web

grub4dos (for MBR) - link on the forum - link on the Web

grub4dos for UEFI - link on the forum - link on the Web

Ventoy - link on the forum - link on the Web

 

On following post I will make a comparative of features related to all this tools.

 

alacran


Edited by alacran, 25 August 2021 - 07:13 AM.
Forgot to include a1ive grub2-filemanager

  • anhphong likes this

#2 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 24 July 2021 - 08:27 PM

Comparative of features:

 

NOTE: In all cases boot WIM files strictly means boot WinPE WIM files.

 

a1ve Grub2:

 

Capable to boot on UEFI and CSM/MBR environments, usefull to boot and Ramboot ISO, WIM, OSs and VHDs but does not support VHDs externally compressed as *.gz or *. lz4, but support VHDs externally compressed as *.xz, loading to Ram is very slow compared with grub4dos for MBR or for UEFI.

 

a1ive grub2-filemanager:

 

We could consider it as a GUI version of a1ve Grub2,  it is capable to boot on UEFI and CSM/MBR environments, usefull to boot ISO, WIM, OSs and VHDs, please see attached picture of files supported.

 

grub4dos (for MBR):

 

Capable to boot only on CSM/MBR environments, usefull to boot and Ramboot ISO, WIM, OSs and VHDs including VHDs installed in Wimboot mode. Also capable to boot the mentioned files when they were compressed as *.gz and *. lz4, saving a lot of space and loading to Ram time. Also is very good for TFTP PXE boot.

 

grub4dos for UEFI:

 

Capable to boot only on UEFI environments with Secure Boot disabled, but if chainloaded from a1ve's Grub 2 it can be used also when Secure Boot is enabled, usefull to boot and Ramboot ISO, WIM, OSs and VHDs including VHDs installed in Wimboot mode. Also capable to boot the mentioned files when they were compressed as *.gz and *. lz4, saving a lot of space and loading to Ram time. Its TFTP PXE boot was not working fine until 2021-06-19 version, there are 2 more recent versions after that but unfortunatelly I don't have more info related to this feature yet, I will update this info later.

 

Ventoy:

 

Capable to boot on UEFI and CSM/MBR environments, usefull to boot ISO, WIM, OSs and VHDs but does not support VHDs installed in Wimboot mode, Do not support VHDs compressed as *.xz, *.gz or *. lz4.  This project is mainly dedicated to create its own Bootable USB device, and recent versions do not allow very easily to use it combined with other tools, but it is capable to boot almost all Linux distro ISOs and also installed on VHD/VDI/RAW.

 

All of them are under active development of new features.

 

alacran

Attached Thumbnails

  • Files supported.png

Edited by alacran, 25 August 2021 - 07:40 AM.
Info updated to include a1ive grub2-filemanager

  • anhphong likes this

#3 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 24 July 2021 - 09:41 PM

Other projects that combine some of the mentioned tools (in alphabetical order):

 

AIO Boot - link on the Web

Easy to Boot (E2B) - link on the Web

Wimb programs - link on the Web

 

Comparative of features:

 

AIO Boot:

 

Capable to boot on UEFI and CSM/MBR environments, usefull to boot ISO, WIM, and limited support for VHDs. It uses internally grub2 and grub4dos (for MBR) as boot loaders, also includes Clover (MBR and UEFI versions) it let us boot a only MBR PC on UEFI, it is also capable to boot many Linux distros, it is mainly intended to create a Bootable USB device but can be installed on HD (replacing all Win boot files/folders) or on a partition (only on MBR). I will not talk more extensively of this project as in its web page there is all possible info you could need.

 

Easy to Boot (E2B):

 

Made by our forum fellow steve6375. Capable to boot on UEFI and CSM/MBR environments, usefull to boot ISO, WIM, and limited support for VHDs. It uses internally grub4dos (for MBR) and a modded version of Ventoy (for UEFI) as boot loaders, it is mainly intended to create a Bootable USB device, not intended to be used on a HD, it is also capable to boot many Linux distros, and useful to install Win OSs from the ISO. This is a very good project, but it is so extense and with so many options the user has to make manually, that IMHO becomes very complicated and hard to use for new users. I will not talk more extensively of this project as in its web page there is all possible info you could need.

 

Wimb's programs:

 

Made by our forum fellow wimb, this is not a single project but a set of programs, capables to create a USB device bootable on UEFI and CSM/MBR environments.

 

NOTE: wimb has not incorporated ntloader to his programs yet.

 

USB_FORMAT - link on the forum  - link in github

 

On MBR:

Using Windows bootmanger as main boot loader

Chainload to boot from grub4dos for MBR

Chainload to boot from Grub2 File Manager of a1ive

Chainload to boot from Grub2 Menu of a1ive

 

On UEFI:

Using a1ve's grub2 as main boot loader

Chainload to boot from grub4dos for UEFI

Chainload to boot from Windows bootmanger

Chainload to boot from Grub2 File Manager of a1ive

 

UEFI_MULTI - link on the forum  - link in github

 

Useful to add WIM, ISO or VHD files to our BCDs and config menus for MBR and UEFI.

 

VHD_WIMBOOT - link on the forum  - link in github

 

Useful to create Normal, Wimboot and Compact mode Win OSs installations on VHDs and to add them to our BCDs and config menus for MBR and UEFI, and also to capture an image of a VHD, PDF file with instructions included.

 

Win_Reduce_Trusted

 

Valid for Win 10, 8.x and 7.  During the tests ran for this topic we have achieved a 1.57 GB used size on a 2.3 GB VHD, by means of cutting several non critical parts on the 10 OS. Download link is located in VHD_WIMBOOT link in github.

 

As we all can notice all this projects are mainly focused on create a Multi Bootable USB device capable to boot on UEFI and MBR/CSM environments.

 

But on following topic I will comment how to create a Multi Bootable internal HD capable to boot and Ramboot on UEFI and MBR/CSM environments, as long as your PC is capable to boot on both environments. Using VHDs to install our OSs or distros in same partition.

 

alacran


  • Tokener and anhphong like this

#4 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 24 July 2021 - 10:01 PM

Easy way to create same structure of a USB device created with USB_FORMAT by wimb in a internal HD to be able to boot as MBR/CSM and UEFI on a PC capable to boot both ways.

 

If your PC Bios/Firmware only allow to boot one way that will be only option available.

 

My test machine layout is:

  • HD-0 is MBR formated where first primary active partition is NTFS as usuall, this is the usually default boot disk for every day use, but it always can be switched permanently at will with HD-1 in all Bios/firmwares.
  • HD-1 MBR formated first primary active partition is FAT-32, and as you know, then it is capable to boot fine as MBR and/or UEFI.
  • Several Win OSs and some Linux distros are installed on VHDs.

My procedure to get exactly same content created by a just made USB device using USB_FORMAT program on the HD-1 was the following:

  • Using a spare USB, format it by means of USB_FORMAT using Super UEFI option.
  • Make a 7-zip file of the FAT-32 partition contend.
  • Create HD-1 MBR formated first primary active partition FAT-32, 32 GB Max., this will allow to add many Linux distro ISOs to boot in Live mode if you want.
  • Extract all 7-zip file content to the new just formated FAT-32 partition and keep the 7-zip file for a possible future use.

Usage:

  • Create a second primary NTFS partition and optionally an extended partition with several logical partitions on HD-1.
  • Into NTFS HD-1, create VHD folder to content the VHDs, for easy edition of config files during my tests using ntloader by a1ve, the WIM files are on the root of the partition, ntloader info is in post between  this  and  this
  • Copy all VHD and Wim files to NTFS partition.
  • Copy the ISO files to folder images on FAT-32 partition, or cut and paste images folder to NTFS partition before copy, if you have ISO files exceeding the FAT-32 limit of 4 GB for a single file.
  • Also it is possible to copy a big number of Linux distro ISOs into its respective folder located on iso folder on FAT-32 partition to boot from them in Live mode. (I omited this in my test machine).
  • Optionally Integrate Linux Portable distros to FAT-32 partition, see: this topic
  • Use UEFI_MULTI and/or VHD_WIMBOOT to make all entries required to MBR/UEFI boot.
  • Use VHD_WIMBOOT to create new Win OS VHDs.
  • Easy to run many test manually editing or adding new entries on BCs or config files of a1ve Grub2 and grub4dos (MBR and UEFI versions).
  • On this machine Asus MB, I can select in Bios the Auto option which basically is: CSM + UEFI, SB can be enabled or disabled, and during boot just pressing the Boot Overwrite Key (F8 in my case) I can select booting from HD-0 or HD-1, but for HD-1 also UEFI option will be available.
  • If SB is enabled when booting, an option to install the Security Certificate to NVRAM will appear on screen, once installed, this option will not appear anymore.

NOTE-1: All this can be done also with a single HD.

 

NOTE-2: With this layout almost all in this machine on HD-1 can Filedisk or Ramboot on MBR or UEFI, by means of a1ve Grub2 and grub4dos (MBR and UEFI versions) environments, as long as Win OS VHDs have SVBusdriver installed for Ramboot.

 

NOTE-3: My Linux-Mint.vhd.vtoy (20 GB) and my Linux-Lite.vhd.vtoy (10 GB) located on the root of NTFS partition, were tested booting as filedisk on MBR and UEFI. They can't boot from Ram, there is not a Linux driver similar to SVBus driver available for this. For more info to create a bootable Linux VHD/VDI/RAW see: this post, additional info on this post and following and also on this topic.

 

Note-4: Portable distros: Porteus, FossaDog, Fossapup64_9.5, puppy_slacko64_7.0, that Boot on Ram by design, were also only tested booting fine on MBR, I haven't made and test entries to boot on UEFI, just forgot to do it.

 

alacran



#5 Guest_AnonVendetta_*

Guest_AnonVendetta_*
  • Guests

Posted 25 July 2021 - 06:23 AM

@alacran: In another topic I created, I EXPLICITLY asked if it was possible to boot a wim...you said no.

And yet, you now post in this topic stating that al1ve GRUB2 can boot WIMs.

I'd be very interested to hear your personal definition of "not possible" there, but yet seemingly possible with this loader.

Receiving this kind of contradictory statements is enough to make me want to go off, but I figured I would ask for an explanation first.

#6 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 25 July 2021 - 03:55 PM

@alacran: In another topic I created, I EXPLICITLY asked if it was possible to boot a wim...you said no.

And yet, you now post in this topic stating that al1ve GRUB2 can boot WIMs.

I'd be very interested to hear your personal definition of "not possible" there, but yet seemingly possible with this loader.

Receiving this kind of contradictory statements is enough to make me want to go off, but I figured I would ask for an explanation first.

 

I never talk with you about a1ve's Grub2, if your comment is related to grub4dos for UEFI (G4E), it was since the very first version un-capable to load WinPE WIM files, until the external module ntloader was developed by a1ve, I made this post after testing it extensively: Summary of ntloader by A1ive

 

Anyway other things have changed on G4E and many more may also change, some samples: hotkey command was embeded and now is an external command, menu.lst default location was changed to /EFI/grub/menu.lst to avoid collition with grub4dos for MBR menu.lst.

 

I have readen all the (so far) 60 pages, post by post on the Chinese page of G4E, and I always answer with the info available, but there is always the posivility that I haven't read yet certain very new info generated on the Chinese page of G4E.

 

alacran



#7 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 25 July 2021 - 05:36 PM

@ AnonVendetta

 

And if you are talking about this post: How to capture Windows (10) to an install.wim, then boot that wim?

 

In second post of that topic I answered you:

 

You can't make a bootable WIM file from a captured image of a OS and use it as a WinPE.

 

Your post No. 3:

 

As to your 1st statement...WHY NOT?...explain. I just love it when people make statements but then don't bother providing an explanation to back up their statement.

 

My post No. 4:

 

My first statement is based on my own experiments trying to boot as a WinPE a WIM file made from a captured OS, see my posts about this subject, and you will learn why it is not possible because of very big differences on the registry:

 

http://reboot.pro/in...e=3#entry216517
http://reboot.pro/in...e=5#entry216627
http://reboot.pro/in...e=4#entry216558

 

So all is very clear, and it seems to me your memory is failing in this case and you make a mess with the info.

 

Anyway to avoid any potential confusion for non advanced users I added this note to Post No. 2 of the current topic:

 

NOTE: In all cases boot WIM files strictly means boot WinPE WIM files.

 

alacran



#8 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 25 July 2021 - 09:11 PM

I think it may be good to put together on this topic the relevant info about ntloader from a1ve:

 

The page in Github is: https://github.com/grub4dos/ntloader

 

This is a quote of the README.md on Github:

 

Spoiler

 

The topic on chinese forum is: http://bbs.c3.wuyou....40&extra=page=1

 

For future readers convenience I will quote here the English translation of the first post of that topic on the wuyou.net forum (from my post):

 

Spoiler

 

NOTE-1: Blue remarks are mine.

 

NOTE-2: Even if it says: The project has stopped development, no longer maintained; on Github last release is from 2021-06-26

 

alacran



#9 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 25 July 2021 - 09:28 PM

I tested ntloader extensively and this is my Summary of ntloader by A1ive:

 

 

Summary of ntloader by A1ive

 

Useful to boot:

  • WinPE WIM files
  • VHD files
  • OS

 

Valid environments:

  • Bios  - MBR partition table logical partition is not supported.
  • x64 UEFI, ia32 UEFI

 

How it works:

 

When using ntloader the info located into the BCD store is not used or required, its internal code recognize a WinPE WIM file, a VHD file or a OS and then it loads/run the right boot file in each case.

 

Advantages:

  • It can be used with A1ive's grub2, grub2 and grub4dos on MBR and/or UEFI.
  • There is no need to create boot files/folders into our VHDs when using ntloader.
  • It can run a VHD as Filedik or as Ramdisk (as long as SVBus is installed).
  • There is no need to edit the BCDs if we use SVBus driver for Ramboot.
  • It works fine if Secure Boot is enabled or not.
  • Our VHDs can have only a single NTFS partition without boot files/folders and there is no need to additionaly include in our menu entries the commands to preload ntfs_x64.efi on PCs with usual firmwares for only FAT.

 

Disadvantages:

  • It do not work on MBR logical partitions, (My tests confirm this).
  • The VHDs do not boot from FAT partitions preferable from NTFS, only recent 10 versions could boot from ExFAT partitions (I haven't tested this).
  • It do not work for VHDs installed on Wimboot mode as I read on its topic.
  • A VHD made from a WinPE do not boot using ntloader, (My tests confirm this).

 

Then I can conclude:

 

It is very clear to me the advantages overcome the disadvantages, and I can say it is a very good tool for our tool box.  Anyway for all cases where ntloader can't be used we can use other options.

 

alacran

 

alacran



#10 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 25 July 2021 - 09:44 PM

For examples of commands for filedisk booting when using G4E + ntloader: See this post

 

For an example of commands used to Ramboot a VHD using G4E + ntloader: See this post

 

Forgot to mention something I learned later: it is recommended to include the parameter hires=0, if not the file on the path will boot with ntloader default max resolution, and may not change the resolution after booting.  See the sample for VHD Ramboot to use it as a guide of its use.

 

alacran



#11 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 07 August 2021 - 09:39 PM

JFYI

 

In order to have all relevant info concentrated on this topic:

 

About a week ago I suggested wimb to integrate ntloader into his programs on this post, but a few later when I was testing to boot from same USB device (using same files and same menus) on a different machine: It can't boot anything if ntloader is involved.

 

It seems to me on this case the UEFI firmware (on CSM or UEFI mode) is interfering with the right uuid reading of the USB device partitions.

 

So be aware ntloader may have some issues in certain MBs depending on its firmware, for more info see this post.

 

 

On the machine where ntloader do not work the USB device is seen as a USB flash drive (no way to change that on it), so it seems to me this affects the uuid reading, and then the WIM or VHD do not boot, same on MBR/CSM or UEFI

 

wimb ran some tests and finaly decided to not include ntloader on his programs.

 

From post:

 

After all my testing of ntloader, I think it is better to keep UEFI_MULTI and VHD_WIMBOOT program the way it is now.

 

That means for RAMDISK booting VHD with 1 partition we use the ntboot command as supported by a1ive Grub2 and for 2 partition VHD we don't need ntboot or ntloader.

 

ntloader does not have sufficient extra value to add it to the programs.

 

alacran



#12 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 22 August 2021 - 12:56 PM

After more tests with ntloader commands on several PCs, I found there is a set of commands that work fine on easy MBR and UEFI Bios, and also a set of commands that work on the problematic MBR and UEFI Bios.

 

The parameter hires=0 (skips the max resolution value coded into ntloader or inherited from a previous loader used) is included in all commands, it takes care of resolution issues, and restores the OS full range of resolutions available.

 

The commands are to let us boot by means of grub4dos for MBR or UEFI versions + ntloader the following:

 

For MBR: A OS, a WinPE WIM file or a VHD file including Wimboot installed VHD, from MBR primary partitions, VHD only if NTFS.

For UEFI: A OS, a WinPE WIM file or a VHD file including Wimboot installed VHD from any GPT NTFS partition.

 

Commands to Ramboot Wimboot installed VHDs included, contrary to previous info I got from the ntloader topic on the chinese forum, it works very fine.

 

Remember grub4dos for UEFI do not work if Secure Boot is enabled.

 

For your convenience I attached them to this post, there is a REAME.txt file included with instructions.

 

Be aware that when some of this commands fail the PC gets blocked some times, and it's required to reboot the PC.
You have being warned, use them under your own risk and don't blame me, I don't take any responsibility in case of troubles or a machine or hard disk failure.

 

The commands that say: using ntloader or using ntloader.i383 should be tested first in your PC.

The commands that say: using chainloader + ntloader or using chainloader + ntloader.i386 should be used only if the others do not work.

 

NOTE: On UEFI environments ntloader.i386 only works if your UEFI Bios is for only x86 CPU, very uncommon and only used mainly on some tablets.

 

PassWord is: ntloader

 

alacran

Attached Files


  • wimb likes this

#13 wimb

wimb

    Platinum Member

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

Posted 22 August 2021 - 01:19 PM

Very nice that you share all these ntloader commands so that these menu entries can be used by all of us  :)

 

It must have taken quite some testing to acquire all this knowledge that is now present in these ntloader commands.

 

BTW the reboot.pro server is extremely slow lately .... What is going on ?


  • alacran likes this

#14 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 22 August 2021 - 02:32 PM

Very nice that you share all these ntloader commands so that these menu entries can be used by all of us  :)

 

It must have taken quite some testing to acquire all this knowledge that is now present in these ntloader commands.

 

BTW the reboot.pro server is extremely slow lately .... What is going on ?

Thanks my friend, and yes a lot of tests, including testing some other commands options for Ramboot not included as they fail sometimes on UEFI.

And about the forum, it is very slow since about 2 or 3 weeks, but today is the worst day.

 

JFYI:

 

In fact on MBR environments we may use ntloader to boot x64 and x86 Os or files.

 

But if using the chainloader command to load ntloader then it is required to use ntloader.i386 to boot a x86 OS or file.

 

Also on UEFI x86 environments the use of ntloader.i386 is mandatory always.

 

So to be consistent on previous commands, I always used ntloader.i386 when dealing with x86 OS or files.

 

alacran



#15 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 23 August 2021 - 12:52 AM

grub4dos-0.4.6a-2021-08-13.7z 520K

 

grub4dos-for_UEFI-2021-08-18.7z 980K


  • Atari800XL likes this

#16 wimb

wimb

    Platinum Member

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

Posted 25 August 2021 - 06:44 AM

There is a lot of useful info in this topic, but I think that more info and a link to a1ive grub2-filemanager is missing here.

 

And that is of course a very powerful tool that deserves to be mentioned here.


  • alacran likes this

#17 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 25 August 2021 - 07:43 AM

Thanks, I already fixed the posts Nos. 1 and 2.

 

alacran



#18 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted 25 August 2021 - 08:44 AM

In order to keep the relevant info available on this topic.

 

Talking a few more about a1ive grub2-filemanager, if running it and using the option F5, we can access the UEFI Shell and typing drivers + enter, and making use of the page-up key we can check if our UEFI Bios contains NTFS drivers, useful to boot having the EFI folder into a NTFS partition, not only on a FAT-32 partition.

 

steve6375, on 19 Aug 2021 - 04:33 AM, said:snapback.png

You can go into the UEFI Shell (e.g via grubfm or the BIOS menu) and type

drivers

then use the page-up key to look for an NTFS driver entry (e.g. 'AMI NTFS Driver').

 

It would be nice if there was a 'drivers' function/utility in grub4efi...

 

But it seems in a new version a similar option will be also available on G4E.

 

 

yaya has add a new 'uefidriver' command to latest beta of grub4efi.

When released, you can test for presence of NTFS driver support from grub4efi

uefidriver > (md)0x300+10
#load ntfs driver if not already present
cat --locatei=NTFS (md)0x300+10 > nul || load /ntfs_x64.efi

 

 

EDIT:

Our fellow wimb just found on Win versions from August 2021 Additional Requirements, from this post:

 

 

- Recent Windows Boot Manager - August 2021 - requires for SVBus driver to Disable driver signature enforcement
   On Boot Menu item press F8 for Advanced Menu and Select Disable driver signature enforcement

 

But fortunately a workaround was found using EfiGuardDxe.efi, from this post:

 

 

alacran, on 25 Aug 2021 - 02:55 AM, said:snapback.png

It is included here:  Useful tools.zip   693.69KB

 

And can be pre-loaded just like ntfs_x64.efi, before all the other commands.

 

Could you please try it, I haven't downloaded the August 2021 version to test it myself.

 

 

Pre-Load of EfiGuardDxe.efi is working great  :)

Tested for Recent Windows Boot Manager August 2021 of Windows 10x64 and Windows 11x64

On the fly patching allows indeed to Boot Mini 10 and 11 straight from RAMDISK using UEFI Grub4dos (Grub4efi G4E)

So there is no need anymore to Enter OS Selection and on Boot Entry to press F8 for Advanced menu

and Select Disable driver signature enforcement as needed without using EfiGuardDxe.efi

 

title Mini-10x64b.vhd - EfiGuardDxe.efi UEFI Grub4dos SVBus RAMDISK - 3.8 GB
load /EFI/grub/tools/EfiGuardDxe.efi
find --set-root --ignore-floppies --ignore-cd /Mini-10x64b.vhd
map
--mem --top /Mini-10x64b.vhd (hd)
chainloader (hd-1)

EfiGuardDxe.efi is already available on USB drives in EFI\grub\tools when using USB_FORMAT or UEFI_MULTI or VHD_WIMBOOT

So to make use of it you only need to add in your menu.lst entry the line:   load /EFI/grub/tools/EfiGuardDxe.efi 

 

Thanks to alacran for making me aware of this useful tool  :)

 

 

alacran


Edited by alacran, 25 August 2021 - 11:01 PM.
New info was added

  • Atari800XL and antonino61 like this

#19 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1229 posts
  •  
    Italy

Posted 3 weeks ago

Attaboy Alacrán!!!



#20 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted A week ago

Experiments with UEFI:NTFS - Booting internal MBR HDD in UEFI from NTFS

 

About a month ago our fellow Akeo informed us about the new Rufus 3.17

 

After reading his post, this comment seemed to me very interesting and I decided to test it, but didn't do it until today.

 

 

Update UEFI:NTFS to latest and remove Secure Boot notice since this version is Secure Boot signed

 

UEFI:NTFS

 

I will quote here some relevant parts:
 

 

UEFI:NTFS is a generic bootloader, that is designed to allow boot from NTFS or exFAT partitions, in pure UEFI mode, even if your system does not natively support it. This is primarily intended for use with Rufus, but can also be used independently.

 

 

  • Overview

    The way UEFI:NTFS works, in conjunction with Rufus, is as follows:

  • Rufus creates 2 partitions on the target USB disk (these can be MBR or GPT partitions). The first one is an NTFS partition occupying almost all the drive, that contains the Windows files (for Windows To Go, or for regular installation), and the second is a very small FAT partition, located at the very end, that contains an NTFS UEFI driver (see https://efi.akeo.ie) as well as the UEFI:NTFS bootloader.
  • When the USB drive boots in UEFI mode, the first NTFS partition gets ignored by the UEFI firmware (unless that firmware already includes an NTFS driver, in which case 2 boot options will be available, that perform the same thing) and the UEFI:NTFS bootloader from the bootable FAT partition is executed.
  • UEFI:NTFS then loads the relevant NTFS UEFI driver, locates the existing NTFS partition on the same media, and executes the /efi/boot/bootia32.efi, /efi/boot/bootx64.efi, /efi/boot/bootarm.efi or /efi/boot/bootaa64.efi that resides there. This achieves the exact same outcome as if the UEFI firmware had native support for NTFS and could boot straight from it.

 

 

UEFI:NTFS is compatible with Secure Boot and has been signed by Microsoft.

 

 

You can find a ready-to-use FAT partition image, containing the x86 and ARM versions of the UEFI:NTFS loader (both 32 and 64 bit) and driver in the Rufus project, under /res/uefi.

If you create a partition of the same size at the end of your drive and copy uefi-ntfs.img there (in DD mode of course), then you should have everything you need to make the first NTFS partition on that drive UEFI bootable.

 

Experiments with UEFI:NTFS - Booting internal MBR HDD in UEFI from NTFS

 

In my post No. 4 is the recommended MBR layout using first primary active partition FAT-32, this PC is not able to boot in UEFI from a NTFS partition as it lacks required drivers in the Bios, so I was using a MBR Primary Active FAT-32 partition to Boot in UEFI before this experiment.

 

To make things easier I selected all the content of the FAT-32 partition and made a 7z compressed file.

 

The disk was MBR formated with 4 primay partitions, It was necessary to change the 2 final partitions to Logical partitions to accomodate a new primary partition as you all know we can have only 3 primary and a extended partition on MBR formated disks. This was made offline booting from Win10XPE_x64 and using free DiskGenius

 

Then formated the first partition as MBR NTFS active partition and reduced its size to have space for the new FAT-32 partition and created it.

 

After this using 7-zip extrated the just created 7z file content into the first NTFS partition and also extracted uefi-ntfs.img content (or the uefi-ntfs.zip content, attached for your convenience) into the new Fat-32 partition.

 

All my VHDs and PE are now on third primary partition, and a standart installed 10x64 is now located in partition 5 (second logical partition), edited the BCDs as required, and ready for testing.

 

During boot just applied the Boot overwrite Key (F8 in this PC) and selected boot from UEFI OS, I had that entry you can see in the picture since previous boots, but you may need to create it if required booting in UEFI from Win10XPE_x64 and using BootIce.

 

The boot sequence in UEFI is (All located on same HDD):

  1. (UEFI_NTFS FAT partition)\EFI\Boot\bootx64.efi
  2. (UEFI_NTFS FAT partition)\EFI\Rufus\ntfs_x64.efi (or automatically any other *.efi into that folder as required)
  3. (SYSTEM First NTFS active partition)\EFI\Boot\BOOT.EFI

The PC booted very fine using original \EFI\Boot\BOOT.EFI from Win, located into the first NTFS, and 10x64 booted in UEFI environment from partition 5 (second logical partition), please see attached picture.

 

I was able to also load A1ive's grub2 and grub4dos for UEFI, just changing their *.efi files names in the \EFI\Boot folder, located into the first NTFS partition to BOOT.EFI, and from them load same 10x64 OS and some VHDs.

 

NOTE: All tests were made with Secure Boot disabled. But original \EFI\Boot\BOOT.EFI from Win should work fine with Secure Boot enabled.

 

More info in following post.

 

alacran

Attached Thumbnails

  • Booting from NTFS.png

Attached Files



#21 alacran

alacran

    Gold Member

  • .script developer
  • 2303 posts
  •  
    Mexico

Posted A week ago

Experiments with UEFI:NTFS - Booting internal MBR HDD in UEFI from NTFS - Additional comments.

 

In previous post the initial first MBR primary active partition was 11 GB before re-formated as NTFS, and latter reduced to 10 GB to accomodate a new FAT-32 partition of 1 GB, as you were able to see in previous picture, I made it so big just for testing pourposes, as I always like to have plenty of space during running tests, just in case.

 

That is in fact an excesive size as the content of the uefi-ntfs.img (that I extracted with 7-zip for easy copy it, and latter attached as uefi-ntfs.zip for users convenience), is only 848 KB (868,417 bytes), and a very little 1 MB FAT-16 primary partition is enought for it.

 

When using Rufus 3.17 to create a USB device for Win installations or when we create a "Windows to go" VHD. It creates a hidden 1 MB FAT-16 ID: EF partition (EF = EFI System Partition). Please see attached pictures.

 

My partition is not ID: EF, as partitions with this ID can't be easily mounted to copy there the content of the uefi-ntfs.zip file, but if you want it this type just follow instructions from UEFI:NTFS:

 


Download and installation

You can find a ready-to-use FAT partition image, containing the x86 and ARM versions of the UEFI:NTFS loader (both 32 and 64 bit) and driver in the Rufus project, under /res/uefi.

If you create a partition of the same size at the end of your drive and copy uefi-ntfs.img there (in DD mode of course), then you should have everything you need to make the first NTFS partition on that drive UEFI bootable.

 

By the way I know dd is a command-line utility for Linux, but I don't know a good program capable to copy uefi-ntfs.img as a single partition in Windows, Any suggestion will be highly appreciated.

 

But this can be done using the free version of DiskGenius, after creating a FAT-16 empty partition, for users convenience I cloned the UEFI_NTFS partition shown on the second picture and attached it here, just extract the file UEFI_NTFS.pmf before use it in DiskGenius.

 

The file Cloned-UEFI_NTFS-E.zip contains Cloned-UEFI_NTFS.zip that is password protected to avoid issues during download (a txt file with password is included just in case)

 

Cloned-UEFI_NTFS.zip Password is my user name = alacran

 

As said in previous post:

 

The boot sequence in UEFI is (All located on same HDD):

  1. (UEFI_NTFS FAT partition)\EFI\Boot\bootx64.efi
  2. (UEFI_NTFS FAT partition)\EFI\Rufus\ntfs_x64.efi (or automatically any other *.efi into that folder as required)
  3. (SYSTEM First NTFS active partition)\EFI\Boot\BOOT.EFI

 

alacran

Attached Thumbnails

  • Size.png
  • VHD made with Rufus.png

Attached Files







Also tagged with one or more of these keywords: mbr, csm, uefi, grud4dos, grub2, ramboot

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users