Jump to content











Photo
- - - - -

GRUB4DOS for UEFI


  • Please log in to reply
421 replies to this topic

#51 wimb

wimb

    Platinum Member

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

Posted 13 November 2020 - 01:01 PM

Does the VHD have a valid ESP partition and bootx64.efi?

 

The VHD can boot in UEFI Secure mode as FILEDISK using Windows Boot Manager in External ESP

 

The VHD does not have ESP inside but just consist of MBR NTFS partition and has internal EFI\Boot\bootx64.efi of Microsoft



#52 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 13 November 2020 - 01:06 PM

The VHD does not have ESP inside but just consist of MBR NTFS partition and has internal EFI\Boot\bootx64.efi of Microsoft


It's not UEFI bootable!

#53 wimb

wimb

    Platinum Member

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

Posted 13 November 2020 - 01:21 PM

It's not UEFI bootable!

 

It is UEFI Secure bootable as FILEDISK using external Windows Boot Manager in ESP partition and using Microsoft VHD driver vhdmp.sys

 

Do you mean that for UEFI Grub4dos the VHD must have GPT partitioning and have internal ESP FAT32 partition + NTFS Windows partition ?



#54 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 13 November 2020 - 01:30 PM

It is UEFI Secure bootable as FILEDISK using external Windows Boot Manager in ESP partition and using Microsoft VHD driver vhdmp.sys

 

Microsoft bootmgfw.efi doesn't even need bootx64.efi inside the VHD when booting VHD.

 

Do you mean that for UEFI Grub4dos the VHD must have GPT partitioning and have internal ESP FAT32 partition + NTFS Windows partition ?

Assuming this VHD is a real hard drive, first make sure it supports UEFI boot.


Edited by a1ive, 13 November 2020 - 01:30 PM.


#55 wimb

wimb

    Platinum Member

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

Posted 13 November 2020 - 01:40 PM

Microsoft bootmgfw.efi doesn't even need bootx64.efi inside the VHD when booting VHD.

 

Assuming this VHD is a real hard drive, first make sure it supports UEFI boot.

 

The VHD has MBR partitioning and one NTFS partition and supports UEFI booting - boot = OK

It is a VHD file as made with diskpart so it is Virtual Disk and not a real hard drive as you say, allthough when mounted it is seen as real hard drive.

 

What is the partitioning of your VHD ? Is it may be GPT with internal ESP ?



#56 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 13 November 2020 - 01:41 PM

I haven't started any experiments with UEFI grub4dos yet, but...

 

1. 'UEFI grub4dos' is a ridiculous name!  Even the old grub4dos name is outdated since it is usually used to boot Linux and Windows these days!  I suggest the new UEFI grub4dos is called   grub4efi.

grub4dos is not a good name. grldr itself has almost nothing to do with DOS.



#57 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 13 November 2020 - 01:46 PM

The VHD has MBR partitioning and one NTFS partition and supports UEFI booting - boot = OK

It is a VHD file as made with diskpart so it is Virtual Disk and not a real hard drive as you say, allthough when mounted it is seen as real hard drive.

 

What is the partitioning of your VHD ? Is it may be GPT with internal ESP ?

 

You can use a virtual machine (e.g. vbox, vmware player) to test if it supports UEFI boot.

In a virtual machine it's like a "real hard drive".



#58 steve6375

steve6375

    Platinum Member

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

Posted 13 November 2020 - 01:53 PM

First experiment with 'grub4efi'

 

I have an MBR partitioned USB drive

ptn1: NTFS

ptn2: FAT32

 

Problem 1:

ptn2 has /menu.lst but it is not found by grub4efi - I just get the command shell

 

ls /   shows  menu.lst

 

 

 

Problem 2: If I run   configfile (hd1,1)/menu.lst

using sample menu then it hangs

On experimenting, it is the hotkey line which causes the problem - if I remove the hotkey line then I get a good menu

 

hotkey is failing on VBOX 5 but on real system IdeaPad 300 it works!

timeout 5
default 0
echo 1
graphicsmode -1 800
echo 2
font (hd1,0)/_ISO/e2b/grub/unifont.hex.gz
echo 3
splashimage (hd1,0)/_ISO/e2b/grub/background.bmp.gz
echo 4
color normal=0x55ffff highlight=0xff00ff helptext=0xffff55 standard=0x55ffff border=0xaaaaaa
echo 5
setmenu --box x=4 w=60 y=6 h=9 l=2
echo 6
#setmenu --keyhelp=1 --lang=zh
setmenu --keyhelp=1
echo 7
setmenu --auto-num-on
echo 8
setmenu --keyhelp=1=0x66ff00
echo 9
setmenu --string=m=2=0x0000000000ffff="G4D 维  护  菜  单"
echo 10
setmenu --string=s=1=0x8800000000ffff="date&time=yyyy-MM-dd  HH:mm:ss"
echo 11
setmenu --timeout=90=2=0x88000000ffff
echo 12
setmenu --hotkey -A [F4] commandline
echo 12
title Reload
configfile (hd1,1)/menu.lst
boot

Attached Thumbnails

  • grub4efi_firstboot.JPG
  • grub4efi_menu_nohotkey.JPG
  • grub4efi_menu1.JPG


#59 steve6375

steve6375

    Platinum Member

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

Posted 13 November 2020 - 07:47 PM

I found the cause of issue #1 - I had a /boot/grub/menu.lst which is used for legacy grub4dos in ptn2

 

It seems the search order for grub4efi is different from grub4dos

 

for grub4efi it is:

 

  1. /boot/grub/menu.lst
  2. /grub/menu.lst
  3. /menu.lst

 

It is not practical to use the same file and paths for grub4dos and grub4efi and this should be changed imho !!! 



#60 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 13 November 2020 - 08:28 PM

My thoughts about Rambooting a VHD (with SVBus driver installed) on UEFI environment:

 

To boot from MBR/CSM the boot files/folders can be on a FAT-32 drive/partition or on a NTFS drive/partition, even same NTFS drive/partition where the OS is, as we usually have being doing when Rambooting a VHD on MBR/CSM.

 

But to boot from UEFI it is required to have the boot files/folders on a FAT-32 drive/partition.

 

Then:

 

 

I don't use VHD RamOS.

Maybe you could use the following commands:

map --mem /xxx.vhd (hd)
chainloader (hd-1)

 

And the usual OS loader should do its job, (if located on FAT-32 partition/drive).

 

Does the VHD have a valid ESP partition and bootx64.efi?

 

In this case bootx64.efi runs from a FAT-32 partition/drive

 

The VHD can boot in UEFI Secure mode as FILEDISK using Windows Boot Manager in External ESP

 

The VHD does not have ESP inside but just consist of MBR NTFS partition and has internal EFI\Boot\bootx64.efi of Microsoft

 

The Boot Manager is running from a FAT-32 partition/drive, so no problem.

 

In this case EFI\Boot\bootx64.efi loader don't run fine from a NTFS partition.

 

It's not UEFI bootable!

 

Yes, this is true, under UEFI environment the following possible lines (we may use) require to run from a FAT-32 partition, because Bootx64.efi and bootmgfw.efi DO NOT run fine on NTFS:

  • chainloader (hd-1)
  • chainloader (hd-1,0)/bootmgr
  • chainloader (hd-1,0)/EFI/Boot/Bootx64.efi
  • chainloader (hd-1,0)/EFI/Microsoft/Boot/bootmgfw.efi

Perhaps as a remote possibility chainloader (hd-1,0)/Windows/System32/winload.efi could work, as on usuall installs it is located on a NTFS partition.

 

It is UEFI Secure bootable as FILEDISK using external Windows Boot Manager in ESP partition and using Microsoft VHD driver vhdmp.sys

 

Do you mean that for UEFI Grub4dos the VHD must have GPT partitioning and have internal ESP FAT32 partition + NTFS Windows partition ?

 

Maybe not necessarily GPT partitioned, but at least have a FAT-32 partition, to locate the UEFI boot files/folders.

 

Another option could be use the UEFI:NTFS loader used on Rufus by Akeo: https://github.com/pbatard/uefi-ntfs

 

I would be good if once loaded on Ram we could use the Windows Boot Manager located in External ESP or into an external FAT-32 using EFI\Microsoft\Boot\bootmgfw.efi and the respective BCD entry pointing to the Ram drive where is loaded the VHD.

 

 

alacran



#61 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 26 November 2020 - 11:57 PM

JFYI

 

There is a new version of grub4dos for UEFI, made by yaya, this is his third version: http://grub4dos.chen...EFI-2020-11-26/

yaya's post on http://bbs.wuyou.net...read&tid=422652

Please remember this is a work in progress so it is an experimental version.

 

ChangeLog_UEFI.txt translated to English with Google Translate for your convenience, also attached:

 

Release Notes:
2020-11-26 (yaya)
  Merged i386 and x86_64 source code.
  Fix the hotkey and exit_g4d functions.

2020-11-19 (a1ive)
  Support to use the kernel and initrd commands to start the linux kernel.
2020-11-18 (yaya)
  1. Change the menu directory to: /efi/grub/menu.lst
  2. Support physical CD, hard disk boot.
  3. When there are multiple CDs, adjust the boot CD to the first CD to suit windows.
  4. Add the function exit_g4d to exit GRUB4DOS.
  5. Batch changes:
     The function subscript remains unchanged, and the parameter is changed from 32 bits to 64 bits. (Fn. subscript parameter 1 parameter 2 ...)
     The variable address is changed from 0x8304 to 0x8308, from 32 bits to 64 bits.
     Reading general memory value is still ‘read memory address’, while reading GRUB4DOS internal value, use ‘read *memory address’ (eg read *0x8308).
     Add else function to batch processing. Added {script set} notation.
     Such as:
     if condition
     {
       Script set
       if condition {
         Script set}
       else {
         Script set}
     }
     else if condition
     {
       Script set
     }
     else
     {
       Script set
     }
     note:
     1. The curly brace must be the end of a line.
     2. The script set can be written in multiple lines.
     3. The braces can be nested inside.

2020-10-29 (yaya)
  GRUB4DOS for UEFI environment.
 
  This is a huge project, almost all the code has been stroked. Modified console keyboard input and output, console screen output, memory control,
  Drive control, get date and time, pause control, graphics mode and Unicode font implementation, PXE net start, etc.
 
  During the development process, the GRUB2 source code was referenced. For the mapping, refer to the source code of wintoflash.
 
  1. You can start efi files.
  2. You can start iso and img files.
  3. Built-in hot key function. Example: setmenu --hotkey parameter
 
  Differences from the old version:
  1. You can view the graphics modes supported by the system through the graphicsmode command.
  2. Mount after the map function is executed. There is no need to execute the --hook command.
  3. Cancel the --hook, --unhook, --rehook, --unmap=, --floppies=, --harddrives= commands.
  4. In the UEFI environment, you can boot from a disk other than 0x80, so there is no need to swap disk operations, such as map (hd0) (hd1).
  5. Cancel the delete disk function, such as map (hd1) (hd1).
  6. Currently, PXE Netstart only supports tftp.

 

And this is a sample menu.lst translated to English with Google Translate for your convenience, also attached:

 

# This is a sample menu.lst file. You should make some changes to it.
    # It must be UTF-8 encoding to support multiple languages.
    # The font should be in unifont.hex format.



    #Set countdown (seconds)
    timeout 30

    #Set the first item as the default value
    default 1

    #Set the character color (the upper 32 bits are the background color, and the lower 32 bits are the foreground color)
    color normal=0xff9933 highlight=0xffff00 helptext=0xff00ff heading=0x66ff00

    #Set graphics mode (you can use graphicsmode to detect graphics modes supported by the system)
    graphicsmode -1 800

    #Load background image
    splashimage /efi/grub/splashimage.jpg || splashimage /boot/grub/splashimage.bmp

    #Load font (if it is not a 16*16 font, add parameters, such as --font-high=24)
    font /efi/grub/unifont.hex.gz

    #Settings menu box
    setmenu --box x=4 w=60 y=6 h=9 l=2
    #Set Chinese menu button help
    setmenu --lang=zh
    #Set automatic menu number
    setmenu --auto-num-on
    #Set string information
    setmenu --string=80=2=0x0000000000ffff="G4D maintenance menu"
    #Set date and time
    #setmenu --string=s=1=0x8800000000ffff="date&time=yyyy-MM-dd HH:mm:ss"
    #Set countdown
    setmenu --timeout=90=2=0x88000000ffff

    title starts efi file
    chainloader /efi/boot/grub2x64.efi

    title Start virtual CD
    find --set-root /cdrom.iso
    map /cdrom.iso (0xff)
    chainloader (0xff)

    title Start virtual CD (loaded into memory)
    find --set-root /cdrom.iso
    map --mem /cdrom.iso (0xff)
    chainloader (0xff)

    title Start the existing CD (cd0)
    chainloader (cd0)

    title Start virtual hard disk
    find --set-root /boot/hdd.img
    map /boot/hdd.img (hd)
    chainloader (hd-1)

    title Start virtual hard disk (loaded into memory)
    find --set-root /boot/hdd.img
    map --mem /boot/hdd.img (hd)
    chainloader (hd-1)

    title starts the existing hard disk (hd0)
    chainloader (hd0)

    title starts other menus
    configfile /efi/grub/menu2.lst

    title Start Linux Porteus 5.0 x86_64 openbox
    kernel /porteus/vmlinuz copy2ram
    initrd /porteus/initrd.xz

    title command line
    commandline

    title Exit grub4dos
    exit_g4d

    title restart
    reboot

    title shutdown
    halt
 

 

NOTE: Just in case of any future troubles with reboot.pro forum, there is also this topic on MSFN forum, I suggest to take note of this link, and it will be good if our fellow a1ive also make note of this: https://msfn.org/boa...comment-1191114

 

alacran

Attached Files



#62 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 29 November 2020 - 02:04 AM

My testing results with the grub4dos-0.4.6a_for_UEFI-2020-11-26:

 

I created a fixed size 2.3 GB VHD (unformated) on a partition of my internal HD, initialized it as MBR, then formated as Win 6.x MBR, first partition is 128 MB FAT-32 0C Active, and second is NTFS (the rest of the espace), by means of wimlib-clc I installed (on Compact LZX mode) the Mini-10-x64 on NTFS partition and created manually the Boot Files/folders on the FAT-32 partition, and edited both BCDs with BootIce, See attached pictures), latter made a new  Ramboot entry on old menu.lst (for grub4dos for MBR) as usuall for the VHD located on internal HD:

 

title 10x64-UEFI.vhd - SVBus  RAMDISK - 2.3 GB - map as (hd) for MBR boot
find --set-root --ignore-floppies /10x64-UEFI.vhd
map --top --mem /10x64-UEFI.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

It booted very fine, not a single issue, so this confirms a VHD with 2 partitions (having boot files/folders on FAT-32 partition) is capable to Ramboot very fine (at least when MBR booting).

 

So far I have being able to UEFI boot Win10XPE_x64.ISO from internal HD or USB, this is my very simple menu.lst (good to start testing with the minimum features):

 

 

timeout 10
default 0

title Start Win10XPE_x64.ISO - UEFI boot
find --set-root /images/Win10XPE_x64.ISO
map /images/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

title 10x64-UEFI.vhd  SVBus  RAMDISK - UEFI boot
find --set-root /10x64-UEFI.vhd
map --mem /10x64-UEFI.vhd (hd)
chainloader (hd-1)

title start Grub2 menu
find --set-root /EFI/Boot/BOOTX64.EFI
chainloader /EFI/Boot/BOOTX64.EFI

title command line
commandline

title Exit grub4dos
exit_g4d

title restart
reboot

title shutdown
halt
 

 

NOTE-1: CSM and Secure Boot are disabled, menu.lst is located on: \EFI\grub\menu.lst; \images\Win10XPE_x64.ISO is on FAT-32 partition; 10x64-UEFI.vhd is on the root of a NTFS partition, BOOTX64.EFI from grub4dos for UEFI was renamed to g4ex64.efi and copied to: \EFI\Boot\g4ex64.efi and an alternative UEFI boot option pointing to it was created on UEFI using BootIce, used when booting from internal HD, not required when booting from USB

 

Win10XPE_x64.ISO boots very fine with no issues from USB or internal HD

 

10x64-UEFI.vhd is not found on USB or internal HD, even if using (hd0,1), (hd1,1) or (hd2,1)/10x64-UEFI.vhd, it looks like the NTFS partitions can't be accessed/readen by grub4dos for UEFI.

 

NOTE-2: This were all MBR partitions, but also tested making a GPT partitioned USB device and botting from it got same results, 10x64-UEFI.vhd is not found on the GPT NTFS of this USB.

 

Also noticed the entry:

 

title shutdown
halt

 

Makes the PC reboot not shutdown

 

alacran

Attached Thumbnails

  • EFI-BCD.png
  • MBR-BCD.png
  • VHD-Partitions.png


#63 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 29 November 2020 - 08:28 AM

I decided to run another test, this time the VHD is located into VHD folder on the root of the second (MBR) NTFS primary partition of the second internal HD.

 

Using this menu.lst entries (usefull also to check if Gziped files can be loaded to Ram as in the MBR version):

 

 

timeout 10
default 0

title Start Win10XPE_x64.ISO
find --set-root /images/Win10XPE_x64.ISO
map /images/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

title 10x64-UEFI.vhd.gz SVBus  RAMDISK for UEFI boot from HD -1
find --set-root /VHD/10x64-UEFI.vhd.gz
map --mem /VHD/10x64-UEFI.vhd.gz (hd)
chainloader (hd-1)

title 10x64-UEFI.vhd SVBus  RAMDISK for UEFI boot from HD -2
find --set-root /VHD/10x64-UEFI.vhd
map --mem /VHD/10x64-UEFI.vhd (hd)
chainloader (hd-1)

title grubfm x64 EFI Boot Manager of a1ive
find --set-root /efi/boot/grubfmx64.efi
chainloader /efi/boot/grubfmx64.efi

title command line
commandline

title Exit grub4dos
exit_g4d

title restart
reboot

title shutdown
halt

 

No luck, with any of both options for the VHD, I got this message (See attached picture):


(hd0,1)
Out of memory
boot_image_handle not found


Press any key to continue....


My comments about the message:

(hd0,1) Seems OK, this means the VHD was located, since I'm booting from the only valid UEFI device and the VHD is located then on (hd0,1).

Out of memory this is not possible, something is wrong here, this PC has 8 GB of Ram and the VHD is only 2.3 GB

boot_image_handle not found I don't understand the meaning of this message.

NOTE: Sorry for the photo quality, it was made with the celphone.

alacran

Attached Thumbnails

  • UEFI booting.jpeg


#64 wimb

wimb

    Platinum Member

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

Posted 29 November 2020 - 01:43 PM

 

boot_image_handle not found I don't understand the meaning of this message.
 

 

That corresponds to my earlier observation in trying to use UEFI grub4dos in booting Mini 10x64 VHD from RAMDISK using SVBus driver.



#65 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 29 November 2020 - 09:37 PM

Yes, that paragraph also appears on your picture but in my case (using a newer grub4dos for UEFI version) it is not even loaded to Ram.

 

 

Out of memory this is not possible, something is wrong here, this PC has 8 GB of Ram and the VHD is only 2.3 GB

 

alacran



#66 wimb

wimb

    Platinum Member

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

Posted 30 November 2020 - 07:35 AM

Yes, that paragraph also appears on your picture but in my case (using a newer grub4dos for UEFI version) it is not even loaded to Ram.

 

 

Yes you are right.

 

No support yet for UEFI grub4dos booting VHD from RAMDISK, which would be the most important and wanted use of UEFI grub4dos .....

 

Also in normal Grub4dos booting we need to use --top switch which is not available in UEFI Grub4dos and might be part of the boot problem .....



#67 wimb

wimb

    Platinum Member

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

Posted 02 December 2020 - 09:12 AM

Out of memory this is not possible, something is wrong here, this PC has 8 GB of Ram and the VHD is only 2.3 GB

boot_image_handle not found I don't understand the meaning of this message.

 

 

Indeed latest version grub4dos-0.4.6a_for_UEFI-2020-11-26 is giving Out of memory and menu.lst does not appear,

 

whereas version grub4dos-0.4.6a_for_UEFI-2020-10-29 presents correctly menu.lst and VHD can be loaded into memory , but RAMDISK booting fails ....

 

Grub4dos_UEFI_IMG_20201202_095648.jpg



#68 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 December 2020 - 12:12 PM

When booting from HD or USB and using this entry (VHD was on root of a partition):

 

title 10x64-UEFI.vhd  SVBus  RAMDISK - UEFI boot
find --set-root /10x64-UEFI.vhd
map --mem /10x64-UEFI.vhd (hd)
chainloader (hd-1)

 

I had problems when calling the renamed *.efi file of grub4dos for UEFI from grub2, I was able to see the menu but as soon as executed the command to load the VHD on Ram it desapeared and the screen went back to grub2 config.

 

Only the entry:

 

title Start Win10XPE_x64.ISO
find --set-root /images/Win10XPE_x64.ISO
map /images/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

 

Was able to boot

 

Then I decided to create an the entry on UEFI with BootIce and disabled Secure Boot to boot directly (with F8 Key) from the renamed *.efi of grub4dos for UEFI and put the VHD into VHD folder on same partition it was, and then was when I got the message:

 

(hd0,1)
Out of memory
boot_image_handle not found

 

I'm testing on an old Asus B75M-A MB with AMI UEFI firmware v2.7 from 2014, I know you have mentioned your MB is Asus too, as obviously our firmwares are different that can explain the different behaviours.

 

So far I have being able to try (from internal HD):

 

 

timeout 10
default 0

title Start Win10XPE_x64.ISO
find --set-root /images/Win10XPE_x64.ISO
map /images/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

title Start Win10XPE_x64.ISO.gz
find --set-root /images/Win10XPE_x64.ISO.gz
map --mem /images/Win10XPE_x64.ISO.gz (0xff)
chainloader (0xff)

title Start Win10XPE_x64.ISO.lz4
find --set-root /images/Win10XPE_x64.ISO.lz4
map --mem /images/Win10XPE_x64.ISO.lz4 (0xff)
chainloader (0xff)

title Start /Isos/pcunlocker.iso.gz
find --set-root /Isos/pcunlocker.iso.gz
map --mem /Isos/pcunlocker.iso.gz (0xff)
chainloader (0xff)

title Start /Isos/AcronisTrueImage.iso.gz
find --set-root /Isos/AcronisTrueImage.iso.gz
map --mem /Isos/AcronisTrueImage.iso.gz (0xff)
chainloader (0xff)

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso
map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff)
chainloader (0xff)

title 10x64-UEFI.vhd SVBus  RAMDISK for UEFI boot from HD
find --set-root /VHD/10x64-UEFI.vhd
map --mem /VHD/10x64-UEFI.vhd (hd)
chainloader (hd-1)

title grubfm x64 EFI Boot Manager of a1ive
find --set-root /efi/boot/grubfmx64.efi
chainloader /efi/boot/grubfmx64.efi

title command line
commandline

title Exit grub4dos
exit_g4d

title restart
reboot

title shutdown
halt
 

 

10x64-UEFI.vhd >>> Do not boot, I got the mentioned message about out of memory.

 

linuxmint-19.3-cinnamon-64bit.iso  >>> Do not boot, message: (initramfs) unable to find a medium containing a live file system. Same message we get if we try the map or map --mem commands on the grub4dos for MBR without the especial (cheat) code. So it seems a especial code will be nedded on UEFI environment too.

 

All the other entries booted fine  >>> At least this tests had proven that (ISO) files compressed *.gz and *.lz4 are loaded fine to Ram and boot without any issue, same as on the MBR version.

 

alacran



#69 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 December 2020 - 02:58 PM

In order to test booting linuxmint-19.3-cinnamon-64bit.iso by means of grub4dos for UEFI, I had to adapt a little the usual especial (cheat code) menu entries as map --hook command is not available and/or required on UEFI version of grub4dos, also avoided the use of variables (just in case), but I think using variables will give same results too, I'll test the use of variables latter.

 

Tried this entries on \EFI\grub\menu.lst

 

 

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso
map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff)
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=/CD/linuxmint-19.3-cinnamon-64bit.iso quiet splash --
initrd /casper/initrd.lz

 

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting as Filedisk
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso
map /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff)
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=/CD/linuxmint-19.3-cinnamon-64bit.iso quiet splash --
initrd /casper/initrd.lz

 

In both cases the linuxmint-19.3-cinnamon-64bit.iso booted fine without any issue.

 

So far it seems Linux Live ISOs capables to boot on MBR and/or UEFI, can be booted on UEFI environment just making very minor adaptations to the cheat code used on MBR.

 

alacran



#70 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 December 2020 - 06:52 PM

In order to test the use of variables I made following entry on \EFI\grub\menu.lst

 

 

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram
set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso
find --set-root %iso_path%
map --mem %iso_path% (0xff)
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash --
initrd /casper/initrd.lz

 

The linuxmint-19.3-cinnamon-64bit.iso Live CD booted flawlessly as expected, so this confirms it is also valid to use variables on the grub4dos for UEFI menu.lst, just same as the MBR version.

 

alacran


  • wimb likes this

#71 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 December 2020 - 12:53 PM

A new test trying to Ramboot a VHD by means of grub4dos for UEFI:

 

This time I created on my HD a 10x64-WB.vhd, 800 MB VHD inicialized it as MBR, first primary partition is FAT-32 0C Active 64 MB, second partition is NTFS the rest of espace.  Then installed on Wimboot mode the Mini-10x64 on NTFS partition by means of wimlib-clc and created manually boot files and folders on Fat-32 partition, and edited both BCDs as on this post to test if it was capable to boot fine, I tested it Rambooting with grub4dos for MBR, and it booted very fine.

 

Then by means of WinImage I made a 10x64-WB.ima file from the VHD, and added following entries on EFI\grub\menu.lst to test if it can be loaded to Ram and check if it was possible to Ramboot it on UEFI:

 

title 10x64-WB.ima SVBus RAMDISK for UEFI boot from HD
find --set-root /VHD/10x64-WB.ima
map --mem /VHD/10x64-WB.ima (hd)
chainloader (hd-1)

title 10x64-WB.ima SVBus  RAMDISK for UEFI boot from HD
find --set-root /VHD/10x64-WB.ima
map --mem /VHD/10x64-WB.ima (hd)
chainloader (hd-1,0)

 

I got same result with both, the IMA file was loaded to Ram very fine, and it started booting as I was able to see the dots moving in circle, but it wasn't able to totally boot and a few time latter I got the BSOD:  INACCESSIBLE BOOT DEVICE

 

alacran



#72 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 December 2020 - 11:16 PM

Just to confirm if there could be something wrong during the creation of the IMA file from the VHD file, I decided to test it Rambooting on the grub4dos MBR version, using following commands on my vhd.lst, which is called by the menu.lst on root of the partition/drive:

 

 

title 10x64-WB.ima.lz4 - from HD 144 MB - SVBus RAMDISK for MBR boot
find --set-root /VHD/10x64-WB.ima.lz4
map --top --mem /VHD/10x64-WB.ima.lz4 (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

title 10x64-WB.ima - from HD 800 MB - SVBus RAMDISK for MBR boot
find --set-root /VHD/10x64-WB.ima
map --top --mem /VHD/10x64-WB.ima (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

And it booted very fine (even lz4 compressed) on MBR version, this confirms nothing was wrong during making the IMA file from the VHD file.

 

Then the BSOD:  INACCESSIBLE BOOT DEVICE got when using UEFI version is related to something else, I guess the current intent on this third version of grub4dos for UEFI to find/locate on memory the IMA second NTFS partition by means of translating/relocating the SVBus driver info to info that can be valid/used on UEFI environment is not working fine yet.

 

alacran



#73 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 05 December 2020 - 02:34 AM

Just to confirm if there could be something wrong during the creation of the IMA file from the VHD file, I decided to test it Rambooting on the grub4dos MBR version, using following commands on my vhd.lst, which is called by the menu.lst on root of the partition/drive:

 

 

And it booted very fine (even lz4 compressed) on MBR version, this confirms nothing was wrong during making the IMA file from the VHD file.

 

Then the BSOD:  INACCESSIBLE BOOT DEVICE got when using UEFI version is related to something else, I guess the current intent on this third version of grub4dos for UEFI to find/locate on memory the IMA second NTFS partition by means of translating/relocating the SVBus driver info to info that can be valid/used on UEFI environment is not working fine yet.

 

alacran

please try this : https://drive.google...iew?usp=sharing

 

Since reboot.pro is not very stable, I suggest discussing it in the github issue: https://github.com/c...grub4dos/issues


Edited by a1ive, 05 December 2020 - 02:40 AM.

  • alacran likes this

#74 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 05 December 2020 - 02:51 AM

Just for testing pourposes, (as I do not see any practical use for it), I created a 900 MB VHD, inicialized it as MBR, single partition FAT-32 0C, and extracted there the content of my Win10XPE_x64.ISO (843 MB), only excluded the CDUsb.y file to let it find on internal HDs the partition where it is contained.

 

Made following entrie on \EFI\grub\menu.lst:

 

 

title Win10XPE_x64.vhd SVBus RAMDISK for UEFI boot from HD
find --set-root /VHD/Win10XPE_x64.vhd
map --mem /VHD/Win10XPE_x64.vhd (hd)
chainloader (hd-1)

NOTE: In this case SVBus driver was not installed as it is not required. Thanks to Vortex for making me notice my mistake on the title: http://reboot.pro/to...e-8#entry217393

 

The VHD was loaded to Ram very fine and it booted flawlessly, this confirms the grub4dos for UEFI is working very fine. Then my statement on previous post is valid:

 

 

I guess the current intent on this third version of grub4dos for UEFI to find/locate on memory the IMA second NTFS partition by means of translating/relocating the SVBus driver info to info that can be valid/used on UEFI environment is not working fine yet.

 

I can say only issues pending to solve are Rambooting VHDs when using SVBus driver, and load to RAM big size VHDs (2+ GB).

 

In fact I don't know which it the actual size limit to load on Ram some item, so far a 2.3 GB VHD or IMA file is not loaded, it reports not enought Ram, but I was able to load and boot from Ram linuxmint-19.3-cinnamon-64bit.iso which size is 1.89 GB, based on this I assume the limit is currently about 2 GB.

 

alacran



#75 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 05 December 2020 - 02:59 AM

please try this : https://drive.google...iew?usp=sharing

 

Since reboot.pro is not very stable, I suggest discussing it in the github issue: https://github.com/c...grub4dos/issues

I also opened a topic on MSFN forum about grb4dos for UEFI to continue the talk if reboot.pro is offline, I try to keep it updated with same info I write here, it will be good to see you there too: https://msfn.org/boa...b4dos-for-uefi/

 

Thanks for new version, I will try it inmediatly and report back.

 

alacran






4 user(s) are reading this topic

0 members, 4 guests, 0 anonymous users