Jump to content











Photo
- - - - -

Grub4dos for UEFI for beginners [Questions and Help topic]

grub4dos for uefi beginners

  • Please log in to reply
115 replies to this topic

#26 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 17 August 2021 - 11:57 AM

OK, some of the feedback from my first tests, thank you Alacran for your answers by PM:

 

- I had to copy BOOTX64.EFI to *both* locations: \EFI\Microsoft\Boot\ and \EFI\Boot\

- Booting the first entry in your example now works on my system (the one pointing to bootmgfw.efi, renamed to bootmgfw_win.efi)

 

I can't get the second entry to work yet. At first I thought it could be my fault because I named the tag file "10X64-OS.tag" instead of using a lower case "x": 10x64-OS.tag, but that didn't help. I tried entering the commands from the Grub4UEFI command line (like Steve's example), but no success yet... The commands execute just fine on the command line, but the system does not boot (it hangs on a black screen).

 

It can't be a faulty Windows 10 setup, because as I mentioned booting it with the first entry works fine.

There's still a pretty good chance I'm doing something wrong though, so I will do some more testing before I'll bother you again.



#27 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 17 August 2021 - 03:58 PM

After more help from Alacran (thank you!) it seems "ntloader" by A1ive is not compatible with my specific DELL test laptop. My "Test Tuesday" is about finished, but one of these days I will repeat all of my tests from my notes, to make sure I run a "clean" test, there's is a (pretty big) chance I still overlooked something.

Alacran advised me to test GrubFM as well, which also allows to select an OS partition (from multitple partitions, like I wanted to do with Grub4UEFI), this worked OK, so until now the "suspect" is "ntloader".

I will try to post further findings as soon as possible, thanks again to all for your help.


  • alacran likes this

#28 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 17 August 2021 - 04:04 PM

If you get a black screen after ntloader, it could be that it has hung/crashed (press NumLock or CapsLock - does LED go on/off?)

or graphicsmode is wrong...

try one of these commands before ntloader

 

graphicsmode 3

or

graphicsmode -1 1024 768

or

terminal console



#29 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 17 August 2021 - 04:43 PM

Thanks for your suggestions. From your list, I did try the "graphicsmode -1 1024 768" before, unfortunately without success.

It does seem like a crash, because there's no CapsLock LED toggle anymore. I made sure the LED toggle was there BEFORE the crash, so this does seem like a good indicator to distinguish between crash or graphics mode.

I will now run my final checks...



#30 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 17 August 2021 - 05:50 PM

On the test laptop, I used Terabyte Image for Windows to restore the backup of my new Windows 10 install to a **second** partition on the GPT disk (until now it had 100mb EFI part + 40Gb OS part + empty space). The restore was done to a new partition in this empty space (TIW takes care of this automatically).

Instead of Grub4UEFI I used GrubFM (a1ive/grub2-filemanager) and it seems to boot without problems from both OS installs (Using the F3 option).

So this seems to be a solution to what I was looking for, but of course the initial idea was to do this with Grub4UEFI, with maybe ultimately finding out how to hide partitions from each other, adding colorful menus, etc...

Still, I consider this Test Tuesday a day well spent, I hope to learn more about this interesting topic from all you friendly people.

Easy on the coffee tonight, Alacran!!!


  • alacran likes this

#31 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 August 2021 - 08:57 PM

I assume there are no human mistakes in the tests made by Atari800XL, not because he's not human :D , but because I know him since long time ago and I have a pretty good idea of his skills. Also he is very meticulous and usually makes notes of each step.

 

So IMHO this confirms ntloader is not compatable with some MB UEFI firmwares, as I commented before I have one PC at home that does not boot on CSM or UEFI if using ntloader, so in fact ntloader is not very reliable to be used in all cases, which is really sad, because when it works it does a great work.

 

But not all was bad news, a1ve's grub File Manager (agFM) can be used alone as a viable alternative using a similar procedure, or chainloading to it from G4E if G4E + ntloader does not work on certain MBs.

 

But of course this topic is related to the use of G4E and not to agFM.

 

EDIT: For those problematic UEFI Bios see alternative menu commands, that worked fine for me to boot WIM and VHD files on them on post 50 and 53

 

alacran



#32 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 18 August 2021 - 12:20 AM

@ Atari800XL

 

I'm not ready to give up yet.

 

There is another test you can do if you want to use G4E to boot several OSs from several partitions.

Download the attached file, uncompress it and copy ntfs_x64.efi to \EFI\grub\ntfs_x64.efi

From a PE or from a OS create in elevated command prompt their respective EFI boot files/folders into same partition where that OS is.

 

Like this: bcdboot C:\Windows /s C: /f UEFI or this: E:\Windows /s E: /f UEFI  >>> and then the EFI folder is created in same partion of the OS.

 

NOTE: C: Is the drive letter as seen from the same OS, and E: represents a drive letter as seen from a PE, change it as required

 

Add following commands to UEFI menu.lst adapting them to your case(s):
 

 

title 10x64 OS from (hd0,3) internal HD
load /EFI/grub/ntfs_x64.efi
chainloader (hd0,3)

 

ntfs_x64.efi (NTFS driver) from refind-cd-0.11.4, contain x64 drivers for UEFI (usually only available on very few MBs), then this allows to read/load/run the files/folder of an EFI folder located on a NTFS partition/drive.

 

Useful tools.zip   693.69KB for more see this post.

 

Just tested this approach and the OS booted fine here but on low resolution, but similar approach works very fine to filedisk and ramdisk boot single NTFS partition VHDs without resolution issues.

 

For Ramboot a VHD this are the commands on UEFI menu.lst, and there is nothing related to resolution on it:

 

 

title Boot /VHD/Mini-10x64.vhd - UEFI Grub4dos  SVBus  RAMDISK  - 2 GB
load /EFI/grub/ntfs_x64.efi
find --set-root /VHD/Mini-10x64.vhd
map --mem --top /VHD/Mini-10x64.vhd (hd)
chainloader (hd-1)

 

NOTE: I found a way to fix the resolution issue using BootIce, on BCD tab select the BCD located into the OS partition/drive and open it on Professional mode, on the left panel select Windows Boot Manager, make a right clik on the right panel and select New element, select GraphicsForceHighestMode, on new window select True and OK. Please see attached picture made on another PC just for illustrative purposes.

 

It is very possible we can find a better way to fix the resolution issue, but for now this workaround works fine.

 

EDIT: This post was edited to try to make it more clear for future readers, additional info on Post 46.

 

alacran

Attached Thumbnails

  • ForceHighestMode.png


#33 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 August 2021 - 05:48 AM

How to know if your UEFI Bios/firmware has the required NTFS_x64 drivers to be capable to UEFI boot if the EFI folder is located on a NTFS partition, and not only if it is in a FAT-32 partition?

I never have seen on any Mother Board Manual any info related to UEFI NTFS_x64 drivers.

To test this I used a USB stick (MBR initialized) with a single NTFS First Primary Active Partition and by means of 7-zip extracted there the content of my Win10XPE_x64.iso, just avoided this files: CDUsb.y, XPEStartup.cmd and XPEStartup.ini because some time ago when I made a flat install on a VHD they created some issues. Then selected on the Bios to boot only in UEFI, without CSM, and disabled SB (just in case).

It seems now is becoming more common to find UEFI Bios/firmwares with NTFS_x64 drivers, so far I have tested three PCs at home, and two of them are capables to boot from a EFI folder located into NTFS partition/drive in UEFI environment, those two have AMI UEFI Bios, one from December 2015 and the other from May 2016. And I know liuzhaoyzz's PC and the Asus MB of wimb's PC also have NTFS_x64 drivers for UEFI.

If the mentioned drivers are present, this allows also to Filedisk boot a partition or Ramboot single NTFS partitioned VHDs, without the requirement to first pre-load the ntfs_x64.efi (NTFS x-64 driver for UEFI) from refind-cd-0.11.4 in our UEFI menu.lst (as I can confirm).

So to give you an example: it means in the two quoted menu entries in previous post, this PCs DO NOT require the load /EFI/grub/ntfs_x64.efi line.

Maybe in a near future we find an easier and faster way to detect if the NTFS_x64 drivers are present or not in the UEFI firmware.  Ideas are welcome.

alacran

Attached Thumbnails

  • USB stick.png
  • UEFI booting from NTFS.png

  • wimb likes this

#34 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 19 August 2021 - 07:15 AM

For resolution issues, in grub4efi try one of these before booting

 

terminal console

or

graphicsmode -1 1024 768

or

graphicsmode 3



#35 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 19 August 2021 - 09:33 AM

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


  • wimb and alacran like this

#36 wimb

wimb

    Platinum Member

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

Posted 19 August 2021 - 10:41 AM

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

 

Thanks, it is working great and my ASUS Z170I PRO GAMING mobo has indeed the NTFS driver in UEFI AMI BIOS available

 

UEFI_NTFS_Driver_IMG_20210819_123526.jpg == AMI_BIOS_2021-08-19_124919.jpg



#37 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 19 August 2021 - 01:20 PM

Sorry for the late reply, but I didn't have time to test yesterday.

Thank you all so much for your hints and tips, I seem to be making some excellent progress that I must admit I didn't expect anymore! Thanks to Alacran for not giving up! And a big thanks to Steve for the "drivers" command in the EFI shell (which I start through GrubFM).

I'm not as experienced in all this stuff as you guys are, so it takes some time for me to wrap my mind about some of these concepts.

 

So here's what I did:

(1) GrubFM - EFI shell - "drivers" command (suggested by Steve)

I expected an NTFS driver to be there, because I assumed that otherwise GrubFM woudn't have been able to boot Windows from the first and second NTFS partitions either in my UEFI/GPT test setup. As you experts know, this was a wrong conclusion.

 

(2) Now I understood Alacran's post about the EFI NTFS driver better. So actually it's not a bad thing that I tried Steve's suggestion *before* I read Alacran's post.

 

(3) I now understood that I should load the NTFS driver in Grub4UEFI (I used the command line):

"load /ntfs_x64.efi"

(I copied this file to the root of the EFI partition, in PE)

 

(4) But I still didn't understand why I should use the BCDBoot commands to add the UEFI boot files to my Windows 10 partitions. Weren't these files supposed to be there already? In my OS apply scripts, I'm using this BCDBoot command already:

"bcdboot c:\windows /s s:\"

 

(5) After some more testing I discovered that this command did **not** copy the \EFI folder!!!

I will look into that issue later, but it seems the EFI files are just not present in the source I'm using in that command. Once again: I didn't realise what was going on there, because in a normal apply of the OS files to a (single boot) GPT disk, this has never been a problem.

 

So my preliminary conclusion is that these are the things that allow me to multiboot using Grub4UEFI on my test system:

-A- Load the NTFS driver

-B- Make sure the EFI folder (boot files) is on the Windows OS partitions.

 

From the Grub4UEFI command line, this is working now (partitions: EFI, NTFS 40gb, another NTFS 40gb, empty space for later tests):

 

load /ntfs_x64.efi

chainloader (hd0,1)    --or--   chainloader (hd0,2)  --or--   etc.

boot  (only needed from the command line, I guess)

 

A very big thanks again to everybody for your help.

 

 

I hope I made no errors in this write-up, if I did: please point them out to me and I will edit this post.

This thread is called "for beginners", and Wonko told me to report my findings in this thread (not in PMs to Alacran), so I hope you don't mind these posts, that might seem obvious to some of the pros around here.

 

 

 

 

 



#38 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 19 August 2021 - 01:31 PM

grubfm does not add in an NTFS driver

So are you saying that cannot boot via grubfm to (hd0,1) using any option in the F3 menu (or which menu options work and which don't)?



#39 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 19 August 2021 - 01:37 PM

I now accept suggestions for making the partitions invisible to each other after Windows boots.  :-)

 

This doesn't have to be a Grub4UEFI command/ responsibilty, it could also be a (scripted/ unattended) tool in Windows, that I can execute in my PostInstall tool (I like unattended OS setup and also unattended software installs, but combining the two is not necessary in my opinion, it usually created more problems that it solves).

This might be slightly off-topic here, but for beginners, it might also be a good suggestion to conclude: "No, don't try to do this in Grub4UEFI, do it in Windows".



#40 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 19 August 2021 - 01:39 PM

grubfm does not add in an NTFS driver

So are you saying that cannot boot via grubfm to (hd0,1) using any option in the F3 menu (or which menu options work and which don't)?

In my early testing, booting with Grub4UEFI didn't work, but booting with GrubFM **did** work (F3).

Sorry for being unclear, please let me know which sentence was not clear.



#41 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 19 August 2021 - 01:42 PM

well grubfm does not need an NTFS driver to boot so why does grub4efi?

Which specific menu entry in grubfm F3 are you using to boot successfully to the disk?

If you press 'e' on that menu entry, what commands is grubfm using in the menu entry for that working menu option?



#42 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 19 August 2021 - 04:20 PM

I now accept suggestions for making the partitions invisible to each other after Windows boots.  :-)

 

This doesn't have to be a Grub4UEFI command/ responsibilty, it could also be a (scripted/ unattended) tool in Windows, that I can execute in my PostInstall tool (I like unattended OS setup and also unattended software installs, but combining the two is not necessary in my opinion, it usually created more problems that it solves).

This might be slightly off-topic here, but for beginners, it might also be a good suggestion to conclude: "No, don't try to do this in Grub4UEFI, do it in Windows".

This might be tricky (and OS dependent).

 

The "right" way is to set the partition "hidden".

On MBR this means normally "add 0x10 to the existing partition id". (this is what hide/unhide in grub4dos does)

On GPT *something* like this can be obtained (on Windows) by flipping the bit 62 in the "attributes" field of the GPT partition table entry and/or flipping the bit 63 BUT this seemingly works ONLY for "basic data partitions", i.e. those whose human readable (but not human friendly) GUID is EBD0A0A2-B9E5-4433-87C0-68B6B72699C7:

https://en.wikipedia..._data_partition

 

For other types of partition the only way is to have diskpart or disk manager remove the assigned drive letter.

 

The ESP should already (by its GUID) be not assigned a drive letter.

 

What happens on other OS is all to be found out.

 

:duff:

Wonko


  • Atari800XL likes this

#43 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 19 August 2021 - 05:13 PM

well grubfm does not need an NTFS driver to boot so why does grub4efi?

Which specific menu entry in grubfm F3 are you using to boot successfully to the disk?

If you press 'e' on that menu entry, what commands is grubfm using in the menu entry for that working menu option?

For example, the second entry in the menu:

set root="${2}";
set lang=en_US;
terminal_output console;
loopback wimboot ${prefix}/wimboot.xz;
ntboot --win --efi=(wimboot)/bootmgfw.efi "(${root})";


#44 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 19 August 2021 - 05:45 PM

The "right" way is to set the partition "hidden".
<>
For other types of partition the only way is to have diskpart or disk manager remove the assigned drive letter.

 

Diskpart doesn't sound bad at all, I'm already using something similar (just some hidden scripts) to restore driveletters to fixed data partitions after OS setup.

The "right" way you mention sounds interesting as well, but the GUID bits are new to me, I would have to research that a bit better, maybe in a new topic.

Thanks for the suggestions.

 

PS: Just remembered, I also use Nirsoft Driveletterview for similar cases, it has a great UI, but can also run from the command line, so something like this should also be possible:

DriveLetterView.exe /delete local d:

 



#45 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 19 August 2021 - 05:59 PM

 

For example, the second entry in the menu:

set root="${2}";
set lang=en_US;
terminal_output console;
loopback wimboot ${prefix}/wimboot.xz;
ntboot --win --efi=(wimboot)/bootmgfw.efi "(${root})";

 

So it is uses the Windows bootmgfw.efi file to start off the process which is kind of cheating!

 

If you copy a 64-bit bootmgfw.efi to your drive somewhere, then maybe this will work?

assumes partition has the /10x64-OS.tag file and /bootmgfw.efi exists

 

or maybe \EFI\Microsoft\BOOT\bootmgfw.efi or bootx64.efi already exists on the target drive?

title Boot 10x64 OS by ntloader from Intermal HD
find /10x64-OS.tag | set ptn=
uuid %ptn% > nul ;; set UUID=%?%
kernel /ntloader uuid=%UUID% file=/bootmgfw.efi
initrd /initrd.lz1
terminal console
boot

Edited by steve6375, 19 August 2021 - 06:00 PM.


#46 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 August 2021 - 08:53 PM

(4) But I still didn't understand why I should use the BCDBoot commands to add the UEFI boot files to my Windows 10 partitions. Weren't these files supposed to be there already? In my OS apply scripts, I'm using this BCDBoot command already:

"bcdboot c:\windows /s s:\"

 

Because when using:

 

 

title 10x64 OS from (hd0,3) internal HD
load /EFI/grub/ntfs_x64.efi
chainloader (hd0,3)

 

load /EFI/grub/ntfs_x64.efi  >>> Loads the ntfs_x64 to let UEFI boot from a NTFS partition/drive (only required if your UEFI Bios lacks this drivers).

 

chainload to (hd0,3) >>> just change the focus to that partition,  and then the EFI folder into that partition makes the OS boot, if the EFI folder is not there then that partition/drive DO NOT boot.

 

And you need to use: 

 

Like this: bcdboot C:\Windows /s C: /f UEFI or this: E:\Windows /s E: /f UEFI  >>> and then the EFI folder is created in same partion of the OS.

 

NOTE: C: Is the drive letter as seen from the same OS, and E: represents a drive letter as seen from a PE, change it as required

 

If you are using instead: bcdboot c:\windows /s s:\  >>> then the EFI folder will be created on S: drive, not on the same partition where the OS resides, where we need it in this particular case.

 

I think that should be more clear now.

 

We have being using this approach for a long time to Ramboot in UEFI single partition NTFS VHDs by means of G4E, and there is an EFI folder into the VHD that makes it boot after loaded to Ram.

 

Of course into the VHD is not only the EFI folder, but there is also all required to make same VHD Ramboot on MBR/CSM too, then in this case the commands are:

 

C:\Windows /s C: /f ALL  or  E:\Windows /s E: /f ALL >>> and the VHD can then Ramboot on MBR/CSM and UEFI by means of grub4dos MBR or UEFI versions.

 

NOTE: C: Is the drive letter as seen from the same OS, and E: represents a drive letter as seen from a PE, change it as required,

 

alacran



#47 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 August 2021 - 09:18 PM

Forgot to coment this:

 

If we are booting from a Win PE the partitions on the internal drive get different dive letters, running BootIce, selecting the internal drive and Parts Manage we can see the right partitions numbers we can use in our grub4dos commands to boot each internal partition we want, it is recommended to use the right names for each partition to make it clear to identify them in BootIce, then we can avoid the need of tag files on our commands.

 

EDIT: On folowing pictures you can see on Partitions.png the partitions numbers, and on EFI on a NTFS.png you can see I added a new entry in the UEFI Bios/firmware NVRAM named Windows Boot Manager-2 pointing to the EFI folder located on GPT NTFS partition 2 where the booted OS resides, in this case G4E was not used to boot from that partition all was done by means of UEFI firmware to ilustrate how booting from the EFI folder on a NTFS partition works fine as long as the PC UEFI Bios has the NTFS_X64 drivers, or if the PC lacks this drivers pre-loading them in our G4E commands works same way.

 

NOTE: 10x86 OS on GPT partition 3, DO NOT boot this way in this UEFI environment, because the UEFI Bios only allows x64 OSs on CPUs x64 capables, by design, to comply with MS requirements (not sure if also UEFI specs requirements too, but very possible), AFAIK only the OEM PCs/Tablets with x86 CPUs, (not x64 capables), get UEFI Bios capables to boot x86 OSs.

 

alacran

Attached Thumbnails

  • Partitions.png
  • EFI on a NTFS.png


#48 wimb

wimb

    Platinum Member

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

Posted 20 August 2021 - 10:10 AM

@Atari800XL
@alacran
 
For UEFI Booting Windows from GPT located on different NTFS partitions or in several VHD's as FILEDISK it is not needed to use ntloader or UEFI Grub4dos or Grub2.
You can simply boot with Windows Boot Manager in EFI folder on hidden FAT32 ESP drive or MBR FAT32 drive, where menu entries are created easily with WinNTSetup or UEFI_MULTI programs.
Windows OS in VHD has the advantage that there is no need to create partitions for your different OS since VHD's can live next to eachother and also can be copied to any location.
UEFI Grub4dos or a1ive Grub2 are needed only if you want to boot Windows VHD's from RAMDISK using SVBus driver
and UEFI Grub4dos or a1ive Grub2 load ntfs_x64.efi driver is only needed for booting 1 partition VHD from RAMDISK when driver is missing in UEFI BIOS.


#49 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 20 August 2021 - 11:18 AM

Thank you wimb, you are correct of course, there are easier/ better ways to achieve something similar, but to me it was still satisfying to know how to achieve this with UEFI Grub4dos, GrubFM etc.

As this topic is named "...for beginners", it is good to have your comment here, so people who are only interested in the easiest way to achieve something like this, they can read your suggestion.


  • wimb likes this

#50 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 20 August 2021 - 11:31 AM

@ wimb

 

Yes my friend, totally agree, I allready use that approach since long time ago, I can boot both ways MBR/CSM and UEFI as I have 2 HDs. and suggested Atari800XL to use VHDs about 3 moths ago, but he wants to boot from plain installed OSs not VHDs, and from G4E, as he has being doing for many time with grub4dos MBR version.  And this has being a good exercise.

 

By the way I solved the issue in the PC that didn't boot using G4E + ntloader, using different commands it boots fine now:

 

 

title Start 10XPE_x64.wim using chainloader
find --set-root /10XPE_x64.wim
uuid %@root%
chainloader /ntloader initrd=/initrd.lz1 uuid=%?_UUID% file=/10XPE_x64.wim

title Start Mini-10x64-WB.vhd FILEDISK using chainloader
find --set-root /U-NTFS.tag
uuid %@root%
chainloader /ntloader initrd=/initrd.lz1 uuid=%?_UUID% file=/VHD/Mini-10x64-WB.vhd

title Mini-10x64-WB.vhd.lz4 -SVBUS RAMDISK-using chainloader
find --ignore-floppies --ignore-cd /EFI/grub/ntloader | set x=
echo x=%x%
find --ignore-floppies --ignore-cd --set-root /U-NTFS.tag
map --mem --top /VHD/Mini-10x64-WB.vhd.lz4 (hd)
uuid (hd-1,0)
chainloader %x%/EFI/grub/ntloader hires=0 uuid=%?_UUID% initrd=/EFI/grub/initrd.lz1
 

 

Version used: grub4dos-for_UEFI-2021-08-18.7z 980K  (It has an issue, ISO files do not boot).

 

EDIT: Last known version without the ISO issue is grub4dos-for_UEFI-2021-07-23.7z 976K as mentioned on the chinese forum topic of G4E.

 

So now all the three PCs that I have tested are capables to boot on UEFI environment using G4E + ntloader

 

alacran







Also tagged with one or more of these keywords: grub4dos for uefi, beginners

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users