272 replies to this topic

[a1ive]

See http://bbs.wuyou.net...read&tid=422652 for details.

 

Download: https://drive.google...o_PLu1LdE2f6xXC

 

GRUB4DOS now adds experimental UEFI support (by @yaya2007).

 

The following features are currently supported in the UEFI version.

1. Boot ISO and IMG files. ('map' command)

2. Boot EFI files.

3. Built-in hotkey support.

4. You can use ‘graphicsmode’ command to see which graphics modes are supported by the UEFI firmware.

5. TFTP PXE boot.

Most other commands are not supported.

 

Example menu:

timeout 5
default 0
graphicsmode -1 800
font /grub/unifont.hex.gz
splashimage /grub/lt.jpg

color normal=0x55ffff highlight=0xff00ff helptext=0xffff55 standard=0x55ffff border=0xaaaaaa
setmenu --box x=4 w=60 y=6 h=9 l=2
setmenu --keyhelp=1 --lang=zh
setmenu --auto-num-on 
setmenu --keyhelp=1=0x66ff00
setmenu --string=m=2=0x0000000000ffff="GRUB4DOS UEFI MENU"
setmenu --string=s=1=0x8800000000ffff="date&time=yyyy-MM-dd  HH:mm:ss"
setmenu --timeout=90=2=0x88000000ffff
setmenu --hotkey -A [F4] commandline

title grub2x64.efi
chainloader /efi/boot/grub2x64.efi

title hdd_boot.ima
map /hdd_boot.ima (hd)
chainloader (hd-1)

title z.iso
map /z.iso (0xff)
chainloader (0xff)

title ^Ctrl+d commandline
commandline

title [F3] reboot
reboot

title halt
halt

Edited by a1ive, 31 October 2020 - 12:45 PM.

[alacran]

Fantastic, this are very good news, hope they continue the development of the UEFI support, adding all the other features available on grub4dos v0.46a.

 

alacran

[wimb]

UEFI booting with Grub4dos works for me and Win10XPE_x64.ISO is booting OK in UEFI mode. 

 

Unfortunately booting VHD is not (yet) supported and that is what we need for booting Mini10x64 VHD in UEFI mode from RAMDISK using SVBus driver

[alacran]

Have you tried making an IMG file of the VHD content?

 

I don't know if it respect the Compact LZX mode or not, but if it does it could be a good option in the meantime.

 

alacran

[a1ive]

SVBus and other vdisk drivers does not support UEFI virtual disk.
https://github.com/a.../grub/issues/24

[alacran]

@ a1ve

 

The talk on your link is about Firadisk, and ISO images.

 

I'm talking of making an IMG of a (virtual) HD. it is very possible SVBus can also fail, but IMHO it needs to be tested to be sure it doesn't work.

 

Because, once the IMG (containing a RAW image of a [virtual] HD which basically is same as a VHD [excluding the header] for grub4dos), is loaded on Ram then bootmgr takes the control.

 

Unfortunatelly I don't have available at the moment an UEFI machine to test this.

 

 

alacran

[wimb]

With UEFI Grub4dos I can load VHD into memory (I can see the progress counter running fine)

But the VHD with SVBus driver does not boot. Also I cannot make use of --top ---mem but only --mem is working.

Tried several ways to boot the VHD loaded into memory, but it fails ......

[alacran]

For your convenience this is the Google translation of yaya2007's post mentioned on on the link of first post:

GRUB4DOS used in 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 realization, PXE net start, etc.
  
  During the development process, the GRUB2 source code was referenced. For mapping, refer to the source code of wintoflash.
  
  1. The efi file can be launched.
  2. Can start iso and img files.
  3. Built-in hot key function.
  
  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 --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 delete disk function, such as map (hd1) (hd1).
  6. Currently, PXE Netstart only supports tftp.
  
  Menu example:
timeout 5
default 0
graphicsmode -1 800
font /grub/unifont.hex.gz
splashimage /grub/lt.jpg
color normal=0x55ffff highlight=0xff00ff helptext=0xffff55 standard=0x55ffff border=0xaaaaaa
setmenu --box x=4 w=60 y=6 h=9 l=2
setmenu --keyhelp=1 --lang=zh
setmenu --auto-num-on
setmenu --keyhelp=1=0x66ff00
setmenu --string=m=2=0x0000000000ffff="G4D maintenance menu"
setmenu --string=s=1=0x8800000000ffff="date&time=yyyy-MM-dd HH:mm:ss"
setmenu --timeout=90=2=0x88000000ffff
setmenu --hotkey -A [F4] commandline

Friendly reminder, the menu should be in utf-8 format, and the default location is
/menu.lst
/boot/grub/menu.lst
/grub/menu.lst

alacran

[a1ive]

 

 

Because, once the IMG (containing a RAW image of a [virtual] HD which basically is same as a VHD [excluding the header] for grub4dos), is loaded on Ram then bootmgr takes the control.

 

Virtual disks created with the 'map' command can only be recognized by the bootloader (bootmgr/bootmgfw.efi), not the OS.

 

The int13h handler installed by grub4dos is still present even if bootmgr takes over control, or even if the OS is booted. SVBus (and Firadisk) will look for virtual disks created by grub4dos via the bios int13h drivemap.

 

There is no BIOS int13h interrupt under UEFI. GRUB4DOS registers the virtual disk via BlockIo Protocol, which is recognized by bootmgfw.efi. However, after the OS starts and ExitBootServices is called, the virtual disk does not exist.

So you need to find another way to pass the info of the virtual disk to the driver (e.g. via UEFI environment variable/ACPI/SMBIOS).

 

NTSTATUS BusAddDevice(IN PDRIVER_OBJECT DriverObject,IN PDEVICE_OBJECT PhysicalDeviceObject)
{

	...

	// get interrupt vector for int13h
	intVector = ((INTERRUPT_VECTOR*)(VOID*)(virtAddr))[0x13];
	
	// unmap real mode RAM range 0 - 1024 bytes
	MmUnmapIoSpace(virtAddr,mapSize);

	// map real mode RAM INT13 segment for a size of interrupt vector offset + 1024 bytes
	physAddr.QuadPart = (LONGLONG)intVector.Segment << 4;
	mapSize = intVector.Offset + 0x400;
	// map physical address range to nonpaged system space
	// we should map this non cached, otherwise Driver Verifier shows the following error in WinDbg: Iospace mapping overlap
	// the reason is because the OS has already mapped the same address range with another cache type
	virtAddr = (PUCHAR)MmMapIoSpace(physAddr,mapSize,MmNonCached);
	if(virtAddr == NULL)
	{
		IoDeleteSymbolicLink(&DosDeviceName);
		IoDetachDevice(DeviceExtension->Bus.LowerDeviceObject);
		IoDeleteDevice(DeviceObject);
		return STATUS_INSUFFICIENT_RESOURCES;			
	}

	// check for the GRUB4DOS identify string "$INT13SFGRUB4DOS" at int13h offset + 0x03
	if(RtlCompareMemory(&virtAddr[intVector.Offset + 0x03],"$INT13SFGRUB4DOS",(SIZE_T)0x10) == 0x10)
	{
		// GRUB4DOS identify string "$INT13SFGRUB4DOS" found
		
		// copy all GRUB4DOS drive map slots to our driver context area slot structure
		RtlCopyMemory(&DriverExtension->slot[0],&virtAddr[0x20],sizeof(GRUB4DOS_DRIVE_MAP_SLOT) * MAXIMUM_GRUB4DOS_DRIVE_MAP_SLOTS);

		// unmap real mode RAM INT13 segment for a size of interrupt vector offset + 1024 bytes
		MmUnmapIoSpace(virtAddr,mapSize);

		return STATUS_SUCCESS;
	}

	// unmap real mode RAM INT13 segment for a size of interrupt vector offset + 1024 bytes
	MmUnmapIoSpace(virtAddr,mapSize);

	// GRUB4DOS identify string "$INT13SFGRUB4DOS" not found
	// we now try to search for the GRUB4DOS INT13 handler in the first 640 KB

	// check the first 640 KB for the GRUB4DOS identify string "$INT13SFGRUB4DOS"
	// we search in reverse order from top to down, because this is faster
	for(i = 0x9F000; i >= 0; i -= 0x1000)
	{
		// map real mode RAM address for a size of 4096 bytes
		physAddr.QuadPart = (LONGLONG)i;
		mapSize = 0x1000;
		// map physical address range to nonpaged system space
		// we should map this non cached, otherwise Driver Verifier shows the following error in WinDbg: Iospace mapping overlap
		// the reason is because the OS has already mapped the same address range with another cache type
		virtAddr = (PUCHAR)MmMapIoSpace(physAddr,mapSize,MmNonCached);
		if(virtAddr == NULL)
		{
			IoDeleteSymbolicLink(&DosDeviceName);
			IoDetachDevice(DeviceExtension->Bus.LowerDeviceObject);
			IoDeleteDevice(DeviceObject);
			return STATUS_INSUFFICIENT_RESOURCES;			
		}

		// do this for 4096 bytes - 16 bytes for the GRUB4DOS identify string "$INT13SFGRUB4DOS"
		for(k = 0; k < 0xFF0; k++)
		{
			// check for the GRUB4DOS identify string "$INT13SFGRUB4DOS"
			if(RtlCompareMemory(&virtAddr[k],"$INT13SFGRUB4DOS",(SIZE_T)0x10) == 0x10)
			{
				// GRUB4DOS identify string "$INT13SFGRUB4DOS" found
		
				// copy all GRUB4DOS drive map slots to our driver context area slot structure
				// k - 0xE3 is the start offset of our drive map table, this negative memory range is included in our memory map
				RtlCopyMemory(&DriverExtension->slot[0],&virtAddr[k - 0xE3],sizeof(GRUB4DOS_DRIVE_MAP_SLOT) * MAXIMUM_GRUB4DOS_DRIVE_MAP_SLOTS);

				// unmap real mode RAM address for a size of 4096 bytes
				MmUnmapIoSpace(virtAddr,mapSize);

				return STATUS_SUCCESS;
			}
		}

		// unmap real mode RAM address for a size of 4096 bytes
		MmUnmapIoSpace(virtAddr,mapSize);		
	}

	// GRUB4DOS identify string "$INT13SFGRUB4DOS" not found, this does not indicate an error, because GRUB4DOS is simply not installed
	return STATUS_SUCCESS;
}

Edited by a1ive, 01 November 2020 - 11:32 AM.

[wimb]

@alive

Thanks for giving explanation.

 

The funny thing is that I can use UEFI Grub4dos booting to load Mini10x64.vhd into memory and that I have access to directory of loaded VHD.

 

After booting with UEFI Grub4dos I use manually Grub4dos commands, root is (hd4,0)

map --mem (hd4,0)/Mini10x64.vhd (hd)

The VHD is loaded into memory and it gets new hd number in my case (hd5)

I have access to files in partition (hd5,0)  e.g. (hd5,0)/EFI/Microsoft/Boot/bootmgfw.efi

I can try various ways of booting e.g. trying to use the build-in Microsoft VHD driver vhdmp.sys  Or SVBus driver, but all fail ....

 

Failing boot attempts are:

chainloader (hd5,0)/EFI/Microsoft/Boot/bootmgfw.efi

chainloader (hd5,0)/EFI/Boot/Bootx64.efi

chainloader (hd5,0)/Windows/System32/winload.efi

chainloader (hd5,0)/bootmgr

I have the feeling to be close to success since all files are accessible in (hd5,0)

 

 

[alacran]

I think if you can set both BCDs pointing to future (hd5,0) which will be the new location, and then try again. starting with:

 

chainloader (hd5,0)/bootmgr, could work.

 

Sorry this was stupid, i need to sleep a few hours.

 

alacran

[wimb]

I think if you can set both BCDs pointing to future (hd5,0) which will be the new location, and then try again. starting with:

 

chainloader (hd5,0)/bootmgr, could work.

 

 

I used BOOTICE and tried as you suggested, but unfortunately it does not work ....

[Atari800XL]

Sorry this was stupid, i need to sleep a few hours.

 

alacran

Well, if we're allowed to say stupid things, please allow me:

- It would be great if I could use my Grub4Dos "GFX-BOOT.GFX" graphical menu's, which I still use on all my systems. These were created with the old "GFX Customizer" by "SBond". These always looked quite professional, I keep them pretty simple with some system info at the bottom, manufacturer at the top, logo's top left and top right. And of course a 3-partition boot menu, great for "fail-safe" PC use...

[ReTokener]

hi Atari800XL

which Grub4Dos version do you use?

can you provide some pictures please?

 

regards   T.

[alacran]

@ a1ve

 

Thanks very much for all your efforts to find a solution to Ramboot a VHD on UEFI environment, I'm aware of all you have done as I have being reading all post on http://bbs.wuyou.net...read&tid=422652, I hope you can find a way to write a pointer as yaya sugested on his last post.

 

If you don't mind I'm going to quote here the posts related to that subject, to let the other members of the forum know you are working very hard looking for a solution to this.

 

Spoiler

 

Some interesting post starting here: http://bbs.wuyou.net/forum.php?

mod=redirect&goto=findpost&ptid=422652&pid=4167699


Posted on Yesterday 22:06 | Just look at the author
This post was last edited by wintoflash at 2020-11-1 22:18


Some friends on the forum and some netizens on reboot.pro want to start the VHD

of RamOS.
However, current Windows drivers, such as SVBus, need to search for

"$INT13SFGRUB4DOS" in int13h to obtain the virtual disk information created by

GRUB4DOS.
There is no such thing under UEFI, so we can only find another way to transfer

virtual disk information. I hope GRUB4DOS and GRUB2 can use the same method to

record virtual disk information. I think it is more appropriate to use UEFI

environment variables. Do you have any thoughts on Yaya? For example, the

variable name is "GRUBvdisk" and the structure is as follows:

     struct grub_vdisk_data
     {
         char magic[8]; // "GNU GRUB"
         uint64_t vdisk_addr; // The address of vhd loaded into memory
         uint64_t vdisk_size;
         char vdisk_path[];
     }


liuzhaoyzz
To
150#
Posted 11 hours ago | Only this author

     wintoflash Posted on 2020-11-1 22:06
     Some friends on the forum and some netizens on reboot.pro want to start

the VHD of RamOS.
     But the current Windows drivers, such as SVB...


         If map --mem xxx.vhd or map xxx.vdf can be realized under UEFI and

started, then UEFI-RAMOS is very interesting and promising! Now the grub2-UEFI

modified by wintoflash can achieve map --mem xxx.vhd to the memory, but windows

does not recognize this disk, so it cannot be started. The first step is taken.


2011yaya2007777
To
158#
  The original poster | Posted 9 hours ago | Only this author

     If you can implement map --mem xxx.vhd or map xxx.vdf under UEFI and start

it, then UEFI-RAMOS is very interesting


The bios version can achieve the above functions. After testing it, the uefi

version can also be implemented.
vdf static: map xxx.vdf (hd)
vdf dynamic: map --mem xxx.vhd (hd)
Vdf difference: It seems that the bios version does not support it.


liuzhaoyzz
To
162#
Posted 6 hours ago | Only this author
This post was last edited by liuzhaoyzz at 2020-11-2 13:35

     2011yaya2007777 published on 2020-11-2 11:04
     The bios version can achieve the above functions. After testing it, the

uefi version can also be implemented.
     vdf static: map xxx.vdf (hd)
     vdf move ...


         Under UEFI, map xxx.vdf (hd0) is indeed achievable. The main problem

is that after the implementation, Windows cannot continue to boot from this

(hd0). Windows does not recognize this disk and cannot continue to boot. It is

stuck in BCD and an error occurs. The code is forgotten, and the reason is

unknown.


wintoflash
To
167#
Posted half an hour ago | Only this author

     liuzhaoyzz Posted on 2020-11-2 13:32
     Under UEFI, map xxx.vdf (hd0) is indeed achievable. The main problem is

that after the implementation, windows cannot download from this (hd0)...


Tried it, it is feasible to pass the memory disk address through UEFI

environment variables.
As shown in the picture, I wrote a small program to get the memory disk address

created by grub2 under windows. Check the memory directly, you can see the

memory disk data.
The problem is, I don't know how to write windows drivers.


2011yaya2007777
To
169#
  The original poster| Posted 8 minutes ago From Mobile | Only this author
You can write the "$INT13SFGRUB4DOS" character string and the mapping table at

an address in the memory. I don't know the memory search range of those

programs, and whether there are keywords to judge.


wintoflash
To
170#
Posted 20 minutes ago | Only this author

     2011yaya2007777 published on 2020-11-2 19:59
     You can write the "$INT13SFGRUB4DOS" character string and the mapping

table at an address in the memory. I don’t know the memory search range of

those programs, is there any...


Firadisk and svbus do not search memory, but directly read from the interrupt

vector table.

     intVector = ((INTERRUPT_VECTOR*)(VOID*)(virtAddr))[0x13];


2011yaya2007777
To
171#
  The original poster | Posted 3 minutes ago From Mobile | Only this author
It may not be allowed to write, the key is that there is no int13 interface in

the uefi environment. Write a pointer at 0x4c? I know that a computer has

occupied 0-0x8000.
 

 

@ All

 

Well, as we all can see a1ve (wintoflash) is working very hard looking for a solution to Ramboot a VHD on UEFI environment, so we are not alone with this subject.

 

alacran

[Atari800XL]

hi Atari800XL

which Grub4Dos version do you use?

can you provide some pictures please?

 

regards   T.

I use the "normal" current versions, the GFX files are not version-specific.

Do you know about the "GFX Customizer" I was talking about? I believe it doesn't even run on the latest Windows versions, but that's OK, I still have an (offline) XP system around for my old scanner anyway... I think that tool (by "SBond") is just a self-extracting exe with several tools "inside", maybe it will run on newer Windows versions if some of those "hidden" tools are updated.

But all of this is not that important if Grub4Dos UEFI is not planning to support these files, anyway.

Please let me know if you've heard of this tool, I will try to send some pictures later...

Thanks for your reply.

 

EDIT: There are some examples on Youtube, just search for "GFX Boot Customizer".

[Vortex]

Hello,

 

I tried the following but It didn't work for me. Probably, I am doing something wrong. Could someone point me in the correct direction?

 

a) In my Windows 10 64-bit UEFI installation, I assigned the letter S to system partition with diskpart.

b ) Accessing the folder S:\EFI\Boot, I renamed bootx64.efi to bootx64b.efi

c) Copied  the file bootx64.efi supplied with grub4dos-0.4.6a_for_UEFI-2020-10-29 to the folder S:\EFI\Boot

d) Created the following menu.lst file in the same folder :

color blue/green yellow/red white/magenta white/magenta
timeout 30
 
title Windows 10
 
chainloader /bootx64b.efi
 
title Win10XPE
 
map --mem (hd0,2)/Win10XPE/Win10XPE.ISO (hd32)
 
chainloader (hd32)
 
title Command line
 
commandline

After rebooting, the computer bypassed bootx64.efi ( the grub4dos loader ) and booted directly to Windows 10. No grub4dos menu.

[wimb]

http://reboot.pro/to...-uefi/?p=216911

 

Friendly reminder, the menu should be in utf-8 format, and the default location is
/menu.lst
/boot/grub/menu.lst
/grub/menu.lst

timeout 10
default 0

title Windows 10
chainloader /EFI/Boot/bootx64b.efi
 
title Win10XPE
map (hd0,2)/Win10XPE/Win10XPE.ISO (hd32)
chainloader (hd32)

title /images/Win10XPE_x64.ISO
map /images/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

title ^Ctrl+d commandline
commandline

title [F3] reboot
reboot

title halt
halt

This menu.lst in root of drive S: will work

 

your menu.lst has wrong location.

[Vortex]

Hi wimb,

 

Many thanks for your help. I moved menu.lst to the root partition but yet the computer boots directly to Windows 10. I guess copying bootx64.efi  ( grub4dos )  to S:\EFI\Boot is not correct. What's the procedure to install the  bootx64.efi file, the grub4dos loader?

[wimb]

Try to use my menu.lst, yours is not ok ....

 

There is no install of UEFI Grub4dos needed. Simply copy of file BOOTx64.EFI is OK

[Atari800XL]

This sounds very good! I haven't changed my test laptop (back) to GPT yet (it supports both), but I understand that booting from HD is already supported?

But not selection of different partitions yet, is that correct?

[Vortex]

Hi wimb,

 

Many thanks again, your help is greatly appreciated. Unfortunately, no matted what I do, the computer manages to bypass grub4dos and load the operating system. I even renamed all the files to see the effects :

 

S:\EFI\Boot>dir
 Volume in drive S is ESP
 Volume Serial Number is EE4C-A631


 Directory of S:\EFI\Boot


28.10.2020  21:48    <DIR>          .
28.10.2020  21:48    <DIR>          ..
29.10.2020  05:16           385.024 ---BOOTx64.EFI
07.12.2019  11:08         1.557.816 ---bootx64b.efi
               2 File(s)      1.942.840 bytes

The Dell Latitude 5500 system does not "seem" to check the files in the directory S:\EFI\Boot. Since the file BOOTx64.EFI is renamed to ---BOOTx64.EFI, the computer is not supposed to boot the OS but mysteriously, the computer find a way to boot the system. Very strange case.

 "

 

---bootx64b.efi is the original Windows 10 BOOTx64.EFI file.

[alacran]

@ Vortex

 

You need to have this lines before the first title of your menu.lst, if not time is = 0, and it goes directly to the first entry wich is booting from the HD.

 

timeout 10  >>> maybe increase the time to 30 may help
default 0  >>> or set as default the WinPE entry

 

Also are you sure you disabled Fast Boot, and totally switch off the equipment, and then boot?

 

alacran

[wimb]

The Dell Latitude 5500 system does not "seem" to check the files in the directory S:\EFI\Boot. Since the file BOOTx64.EFI is renamed to ---BOOTx64.EFI, the computer is not supposed to boot the OS but mysteriously, the computer find a way to boot the system. Very strange case.

 "

 

---bootx64b.efi is the original Windows 10 BOOTx64.EFI file.

 

It is not so mysteriously, since computer can use \EFI\Microsoft\Boot\bootmgfw.efi which file is exactly equal to the normal efi bootfile \EFI\Boot\bootx64.efi

 

I have used booting from USB with UEFI Grub4dos and not tried yet booting from internal EFI drive

[Atari800XL]

not tried yet booting from internal EFI drive

Aah, thanks for (indirectly) answering my question as well.

Looking forward to new developments! I will change my test laptop to GPT in the coming days...