Jump to content











Photo
- - - - -

UEFI Boot from grub4dos

clover uefi grub4dos

  • Please log in to reply
19 replies to this topic

#1 steve6375

steve6375

    Platinum Member

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

Posted 16 May 2014 - 05:15 PM

I have found a way to boot from grub4dos to Clover (and then UEFI boot).

 

No utilities are required (other than a recent version 2013/2014 of grub4dos).

 

Here is a menu.lst - it assumes you have a FAT32 grub4dos USB drive which has grub4dos MBR bootcode installed.

iftitle [cat --locate="FAT32" --length=10 --skip=0x50 ()+1 > nul] Run Clover UEFI Boot Menu\n Run this if you wish to use Clover to UEFI boot
set CL=0
## boot7 is default boot file
cat --locate="BOOT7" --length=10 --skip=0x58 ()+1 > nul && set /a CL=%CL%+1 > nul
if "%CL%"=="1" echo Information: Clover is already installed to the PBR
## configfile /menu.lst
echo ffffffffff > (md)0x350+1
dd if=(hd0,0)+1 of=(md)0x350+1 > nul
dd if=()/clover/boot1f32alt7 of=(md)0x350+1 skip=87 seek=87 bs=1 > nul
dd if=()/clover/boot1f32alt7 of=(md)0x350+1 count=3 bs=1 > nul
#cat --hex (md)0x350+1 && pause
if not "%CL%"=="1" cat --locate="SYSLINUX" --length=10 --skip=0x2 ()+1 > nul && pause PROBLEM: SYSLINUX PBR DETECTED - Cannot install Clover to PBR... && configfile /menu.lst
if not "%CL%"=="1" dd if=(md)0x350+1 of=(hd0,0)+1 > nul && pause --wait=2 PBR updated with Clover boot code
chainloader /clover/boot0md || chainloader /clover/boot0ss || chainloader /clover/boot0af
# User can press 2 for 3 for 32-bit UEFI, 6 for 64-bit UEFI or 1 for Chameleon - within 2 seconds
# boot0md gives a boot0 message and is slower - boot0ss is silent with no message

Full details in my blog post here.

The code still needs tidying up, but I thought I would post to get comments. Using this you can UEFI boot directly from grub4dos.

I created the boot1f32alt7 file myself - it is not a standard Clover file (the standard boot1f32alt file loads the file \boot which we cannot have if the Windows \BOOT folder is in the same partition).

The dd code could probably be simplified to directly patch the PBR, but I wanted to be able to check it first before I allowed it to patch the PBR!

 

[Edit] improved code - use    dd if=()/clover/boot1f32alt7 of=(md)0x350+1 skip=90 seek=90 bs=1 > nul

to allow syslinux to be re-installed - see end of this thread for details[/Edit]

Attached Files


Edited by steve6375, 10 December 2017 - 09:48 AM.

  • ktp and alacran like this

#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 May 2014 - 05:28 PM

I think qemu can do EFI/UEFI and x64 fine. :unsure:

 

JFYI:

http://straightedgel.../howto/efi.html

http://sourceforge.n....php?title=OVMF

 

:duff:

Wonko



#3 steve6375

steve6375

    Platinum Member

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

Posted 16 May 2014 - 05:36 PM

There is a 64-bit version of QEMU, but the one in RMPrepUSB is 32-bit.

The 64-bit version of QEMU will not boot Windows x64. I tried a recent version and it still crashes...



#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 May 2014 - 06:31 PM

A 32bit Qemu, running under a 32 bit OS can emulate a x64 system, whether such a VM will be able to boot a Windows x64 through a UEFI bios, is another thing.
It has worked for years with "normal" BIOS:
http://reboot.pro/to...tualization-vt/

Maybe the issue is the CPU emulation that you chose (or failed to choose or that is available in the specific Qemu build that you are using) see also this (only seemingly unrelated):
http://reboot.pro/to...inpe-ram-usage/
http://reboot.pro/to...usage/?p=184116
and a few posts below by erwan.l

AND, please review the previously given links about OVMF.

:duff:
Wonko

#5 steve6375

steve6375

    Platinum Member

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

Posted 22 May 2014 - 08:06 AM

By copying the PBR to a file, we can remove the restriction of not installing Clover if the PBR already contains syslinux boot code

 

e.g.

create a file of length 1024 bytes (or more) - any contents will do. Name = \PBR.BIN.

place this code at the top of your menu.lst file to make a copy of the PBR

# backup PBR if not Clover PBR
cat --locate="BOOT7" --length=10 --skip=0x58 ()+1 > nul || dd if=()+2 of=()/PBR.BIN > nul

To boot to syslinux, use

chainloader /PBR.BIN


#6 nando4

nando4

    Frequent Member

  • Advanced user
  • 112 posts
  •  
    Australia

Posted 24 June 2014 - 03:34 PM

Steve, this is something I've wanted for a long time. Thank you for posting. I too confirm that booting a FAT32-install of Clover created via  BootDiskUtility.exe  does then allow booting a UEFI Win8.1 installation.

 

Now my grub4dos installation is slightly different to yours. I have a FreeDOS boot image that gets copied to a USB stick using RMPrepUSB. I then boot into a USB FreeDOS environment from which I'd like to chainload out to a UEFI Win8.x partition via Clover.

 

Problem is that applying your code above sees the PBR being overwritten by the following code, preventing any subsequent boot into my FreeDOS USB stick.

if not "%CL%"=="1" dd if=(md)0x350+1 of=(hd0,0)+1 > nul && pause --wait=2 PBR updated with Clover boot code

Can you suggest any workaround? Seems that you are using syslinux.



#7 steve6375

steve6375

    Platinum Member

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

Posted 24 June 2014 - 06:21 PM

What I do is copy the PBR to a file (e.g. PBR.BIN) first and then chainload /PBR.BIN when I want to boot from the code that was originally in the PBR.

 

e.g. at top of menu.lst

# backup PBR if not already Clover PBR
cat --locate="BOOT7" --length=10 --skip=0x58 ()+1 > nul || dd if=()+2 of=()/PBR.BIN > nul

Now you have the original PBR saved and can boot from it whenever you like

title Boot freedos
chainloader /PBR.BIN

If using NTFS (which I guess you aren't as your using FreeDos), make sure the PBR.BIN file is approx 1K or larger



#8 nando4

nando4

    Frequent Member

  • Advanced user
  • 112 posts
  •  
    Australia

Posted 25 June 2014 - 01:26 AM

Steve, I changed my MBR to use wee instead, 'find --set-root /kernel.sys; /kernel.sys', allowing me to change the PBR. Got around that problem OK.

 

Only one remaining unsolved problem. What are the exact steps that you are using to add Clover to your USB stick? 

 

BootDIskUtility creates a Clover USB stick that boots fine. I copied those files directly over to my FreeDOS USB stick. I then added a /clover directory with the boot* files extracted from the Clover.ISO as your menu.lst requires. 

 

Problem is while it all looks OK and there's no complaints from grub4dos with your menu.lst, selecting the "Boot UEFI" option freezes the system.



#9 steve6375

steve6375

    Platinum Member

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

Posted 25 June 2014 - 07:35 AM

Did you press 7 just as Clover is booting?

 

If you read my posts you will see I used a special boot file boot1f32alt7 - did you use that?

 

I can't comment on why it doesn't work without seeing your menu.lst and what files you have on the stick.

 

Why not download the MPI Tool Pack from my Easy2Boot site and you will have the exact files and menu.lst that I use.

 

Also read my blog as given in post #1



#10 staruser

staruser
  • Members
  • 1 posts
  •  
    China

Posted 17 May 2015 - 12:16 PM

hi:

sorry for my bad english.

When the USB disk is divided into two partitions, can not boot from usb.

it will Direct boot HDD clover

please  help me!

thank you!

 



#11 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 10 December 2017 - 08:18 AM

@steve6375
 
Just to mention a problem I encountered.
 
Following your grub4dos code, I succeeded in chainloading Clover from both grub4dos and Grub2
("chainloader /boot/clover/boot0ss").
 
But since then, I can no longer update my syslinux boot sector:
 
The command:
s:\boot\Syslinux\bios\win64\syslinux64.exe --force --directory /boot/syslinux/bios/ s: s:\boot\syslinux\bios\syslinux.bin
gave error message:
missing FAT32 signature
 
After long hours of investigation, I found from \syslinux\libinstaller\fs.c (from line 114):
  /*
   * FAT32...
   *
   * Moving the FileSysType and BootSignature was a lovely stroke
   * of M$ idiocy...
   */
  if (get_8(&sectbuf->bs32.BootSignature) != 0x29 ||
      memcmp(&sectbuf->bs32.FileSysType, "FAT32   ", 8))
      return "missing FAT32 signature";
    } else {
  return "impossibly large number of clusters on an FAT volume";
    }
 
Now the complaint from Syslinux is clear, the Clover patched boot sector does not have pattern expected by Syslinux code.
 
From original FAT32 boot sector at 0x52 offset:
"FAT32   " ("   "=3 spaces 0x20)
 
From patched Clover boot sector at 0x52 offset:
"FAT32...BOOT7 "  ("..."=3 binary zeroes 0x00)
 
 
So the patched code probably should not override the 3 spaces with binary zeroes in order to get syslinux to work.
 


#12 steve6375

steve6375

    Platinum Member

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

Posted 10 December 2017 - 09:46 AM

Changing

dd if=()/clover/boot1f32alt7 of=(md)0x350+1 skip=87 seek=87 bs=1 > nul

to

dd if=()/clover/boot1f32alt7 of=(md)0x350+1 skip=90 seek=90 bs=1 > nul

should solve the problem


Edited by steve6375, 10 December 2017 - 10:06 AM.


#13 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 10 December 2017 - 10:05 AM

@steve6375

 

Thank you Steve. 

Of course the old instruction was "dd if=()/clover/boot1f32alt7 of=(md)0x350+1 skip=87 seek=87 bs=1 > nul".



#14 ambralivio

ambralivio

    Frequent Member

  • Advanced user
  • 195 posts
  •  
    Italy

Posted 10 December 2017 - 10:05 AM

Changing

dd if=()/clover/boot1f32alt7 of=(md)0x350+1 skip=90 seek=90 bs=1 > nul

to

dd if=()/clover/boot1f32alt7 of=(md)0x350+1 skip=90 seek=90 bs=1 > nul

should solve the problem

 

@ Steve

I can't find where's the difference!



#15 steve6375

steve6375

    Platinum Member

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

Posted 10 December 2017 - 10:06 AM

sorry! Forgot to edit the old line!



#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 10 December 2017 - 11:08 AM

It would be interesting, as a side-side note, to check if Peter Anvin has been more royalist than the King.

 

I.e. once the alt bootsector for Clover has been written with skip 87, does the MS bootsect.exe still work?

And does it replace the 3 binary 00's with the three spaces?

 

:duff:

Wonko



#17 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 10 December 2017 - 12:42 PM

@Wonko the Sane
 
To answer your interesting questions, I made 4 experimentations updating my FAT32 boot sector that has 3 binary zeroes
filled starting at offset 87, using either bootsect command or bootice program.
 
1- bootsect /nt52 s: (ntdlr boot code)
2- bootsect /nt60 s: (bootmgr boot code)
3- bootice v1.3.3 install PBR ntldr option (=nt52)
4- bootice v1.3.3 install PBR bootmgr option (=nt60)
 
 
Results:
All commands or program work (boot code written). The 3 existing binary zeroes at offset 87 are untouched.
I guess that if there was 3 spaces instead they would be untouched too.
 


#18 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 December 2017 - 10:50 AM

Yep, good :), I expected something like that. :smiling9:

 

Definitely the correct end of the BPB (i.e. the skip/seek value) is 90 and not 87, still what actually uses the "FAT32   " System ID remains to be determined. 

 

Maybe the philosophy of the good MS guys (and Pauly's) is more or less "leave alone the BPB, let me adjust the code only", while the one of Syslinux is "let me see if the BPB is valid, and if it isn't, let me stop modifying the sector, maybe it is the wrong thing to do".

 

Or - possibly - the "FAT32   " check is not the "correct" check to do, and/or it is possibly not relevant (after all the original "wrong" bootsector by Steve6375 for Clover actually worked)...

 

Unrelated, but not much, I once tested for the "minimal" needed to actually mount/boot FAT12/16 and I found similar "queer" behaviours with jump bytes:

http://www.msfn.org/...&comment=987482

 

And still on FAT12/16, the good MS guys manage - as often happens - to contradict themselves:

https://support.micr...fat-boot-sector

 

after having stated that the field "System ID" is 8 characters in length, they go on with:

 

System ID: This field is either "FAT12" or "FAT16," depending on the format of the disk.

 

:duff:

Wonko



#19 ktp

ktp

    Silver Member

  • Advanced user
  • 773 posts

Posted 11 December 2017 - 12:11 PM

@Wonko the Sane
 
Note that Pauly's bootice has the default checked option of keeping the BPB untouched when restoring PBR.
Other information: with FAT32 boot sector with 3 binary zeroes at offset 87,
only MiniTool Partition Wizard displays that the file system is "Other" (instead of FAT32). Other partition managers
like Aomei partition wizard, Partition Guru, Macrorit Partition Expert displays FAT32 as file system.
 
So it appears that MiniTool Partition Wizard does check for 8-byte "FAT32   " string in BPB.
 


#20 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 December 2017 - 02:13 PM

Yep, the whole point is that - since there is no actual, correct, complete documentation on these filesystems - everyne (of course in good faith) has interpreted the scarce info available (or the results of experiments) in their own way.

 

For FAT32 the most we have is the known fatgen103.doc (which has been available in a zillion of versions) here is latest, I believe:

http://download.micr...c/fatgen103.doc

 

which contains a number of contradictions and "vague" or "unclear" points, namely:

 

One of the strings “FAT12   ”, “FAT16   ”, or “FAT     ”.  NOTE: Many people think that the string in this field has something to do with the determination of what type of FAT—FAT12, FAT16, or FAT32—that the volume has. This is not true. You will note from its name that this field is not actually part of the BPB. This string is informational only and is not used by Microsoft file system drivers to determine FAT typ,e because it is frequently not set correctly or is not present. See the FAT Type Determination section of this document. This string should be set based on the FAT type though, because some non-Microsoft FAT file system drivers do look at it.

and later for FAT32:

 

Always set to the string FAT32   ”.  Please see the note for this field in the FAT12/FAT16 section earlier. This field has nothing to do with FAT type determination.

with a largely patronizing attitude BTW, more or less accusing other people of not having read the documentation that they DID NOT provide ;) ...

 

 

NOTE: As is noted numerous times earlier, the world is full of FAT code that is wrong. There is a lot of FAT type code that is off by 1 or 2 or 8 or 10 or 16.

 

:duff:

Wonko







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

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users