Jump to content











Photo
- - - - -

GRUB4DOS for UEFI


  • Please log in to reply
421 replies to this topic

#1 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 31 October 2020 - 12:39 PM

*
POPULAR

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

GRUB4EFI / GRUB4DOS download link:
https://github.com/c...ub4dos/releases
http://grub4dos.chenall.net/
Bug Report:
https://github.com/c...grub4dos/issues
Other discussions:
https://github.com/c...dos/discussions

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


  • wimb, Tokener, alacran and 2 others like this

#2 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 01 November 2020 - 07:04 AM

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



#3 wimb

wimb

    Platinum Member

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

Posted 01 November 2020 - 07:06 AM

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



#4 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 01 November 2020 - 07:38 AM

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



#5 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 01 November 2020 - 07:42 AM

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

#6 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 01 November 2020 - 08:14 AM

@ 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



#7 wimb

wimb

    Platinum Member

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

Posted 01 November 2020 - 08:37 AM

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



#8 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 01 November 2020 - 09:04 AM

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 >>> Deprecated
/boot/grub/menu.lst >>> Deprecated
/grub/menu.lst >>> Deprecated
/EFI/grub/menu.lst

 

EDITED by alacran: To comply with new updated info.

 

alacran


Edited by alacran, 16 July 2021 - 05:53 PM.

  • wimb likes this

#9 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 01 November 2020 - 11:26 AM

 

 

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.


#10 wimb

wimb

    Platinum Member

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

Posted 01 November 2020 - 01:24 PM

@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)

 

UEFI_G4D2_IMG_20201101_151645.jpg

 


  • alacran and Atari800XL like this

#11 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 01 November 2020 - 02:53 PM

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



#12 wimb

wimb

    Platinum Member

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

Posted 01 November 2020 - 03:16 PM

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



#13 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 01 November 2020 - 03:46 PM

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



#14 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 02 November 2020 - 03:19 AM

hi Atari800XL

which Grub4Dos version do you use?

can you provide some pictures please?

 

regards   T.



#15 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 November 2020 - 01:37 PM

@ 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

 

@ 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



#16 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 02 November 2020 - 02:07 PM

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



#17 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 299 posts

Posted 02 November 2020 - 06:05 PM

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.



#18 wimb

wimb

    Platinum Member

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

Posted 02 November 2020 - 06:23 PM

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.


  • Atari800XL likes this

#19 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 299 posts

Posted 02 November 2020 - 06:35 PM

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?



#20 wimb

wimb

    Platinum Member

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

Posted 02 November 2020 - 06:48 PM

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 likes this

#21 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 02 November 2020 - 07:01 PM

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?



#22 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 299 posts

Posted 02 November 2020 - 07:12 PM

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.



#23 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 November 2020 - 07:29 PM

@ 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



#24 wimb

wimb

    Platinum Member

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

Posted 02 November 2020 - 07:36 PM

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



#25 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 02 November 2020 - 07:46 PM

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






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users