Jump to content

Boot WinPE EFI form GRUB2 CD/DVD


Recommended Posts

 

First image contains two file systems - APM and GPT. They are used to register the two ELTorito images (FAT12 and HFS +) as native partitions. This allows to view and run files from ELTorito images from GRUB2. The image contains a standard ISO9660 partition, but does not include the UDF partition.

 
With this ISO, VirtualBox, VMWare Player and native machine runs GRUB2-EFI as excepted. I can load Linux and Mac OS (requires some improvements, but there are clear). Unfortunately it does not load Windows. I tried to chainload bootx64.efi from the original M$ ELTorito image (cdboot.bin), using cdboot.efi file from the M$ ISO UDF filesystem, and from bootmgfw.efi extracted from boot.wim. I also tried to use iPXE wimmbot, which gives the same effect.

 

I already lost you. :( (on the theory before the practice)

I can understand (though I know nothing of it ) the APM (for the "old MACs"), but what is the *need* or *use* of the GPT?

 

jaclaz

Link to comment
Share on other sites


GPT partition scheme is required by the newer Mac's and PC :)

 

PC is not able to address the file on the partition HFS+ or FAT12 partition located in APM schema. Two partition schemes are also a disadvantage. In EFI Shell, on the machine that supports both schemes, each ELTorito partition is doubled. Eg. In VMWare Player fs0 and fs3 is the same HFS +, and fs1 and fs2 are the same FAT12 partition.

Edited by kyvaith
Link to comment
Share on other sites

 

GPT partition scheme is required by the newer Mac's and PC :)

 

This is where I am failing to follow you. :unsure:

Do you mean that a "modern Mac" or a "modern PC" does not boot a CD/DVD device "normally" as El-Torito no-emulation mode (+if needed "alt-boot" volumes in "plain" CDFS, i.e. without isohybridizing anything?

 

The threads you initially referenced here and on reboot.pro were about such particular kind of CD's, that were not isohybridized, if I recall correctly. 

 

jaclaz

Link to comment
Share on other sites

It is a bit of a twist.
- In theory, all the PC, can run in the EFI mode, with ELTorito FAT12 image.
- Some PC can run from /ISO9660/EFI/BOOT/BOOT***.EFI
- Older Macs do not detect ELTorito FAT12, and GPT from CD / DVD, and they need a HFS + partition in the APM partition scheme.
- Medium-old Macs (yes, sorry), do not detect ELTorito FAT12, and APM from CD/DVD, and they need a HFS + partition on GPT scheme.
- New Macs can run both the ELTorito FAT12, and GPT from CD / DVD, but does not display duplicate items in the boot menu, with hybrid iso (yay!).
 
APM is needed for native boot on older Macs, GPT is needed for native boot on few years old Macs, and for addressing boot files in GRUB2-EFI. ELTorito FAT12 is needed to start on most PCs, but I found out, that it's not used! It just need to be there, and if it's detected, PC jumps directly to /ISO9660/EFI/BOOT/BOOT***.EFI.
 

 

From the very beginning, my ISO is a hybrid, but maybe I did not mention it before, because this is not the problem. I made a bunch of test images without hybridization. Windows behaves identically.
Edited by kyvaith
Link to comment
Share on other sites

Hi,

i am the devolper of xorriso. Apologies for it being

complicated with booting. It's due to the topic

http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

because of the constraints of a mkisofs compatible

options emulation, and because i had to learn on the

topic while implementing. (I also read UDF specs

and can recommend them for those who find man xorrisofs

too easy to read.)

Some technical clarifications:

The shown xorriso -as mkisofs run does not use a pure GRUB2

boot environment but a mix of SYSLINUX and GRUB2, as laid

out by http://mjg59.dreamwidth.org/11285.html .

Pure GRUB2 would normally be produced by script grub-mkrescue

which is quite fixely committed to use xorriso.

There are three boot image files mentioned:

- x86 binary program eltorito.bin (for BIOS)

- FAT filesystem image efiboot.img

- (probably HFS+) fileystem image macboot.img

The various partition tables MBR, GPT, APM are pointers

for use on hard-disk-like devices. E.g. USB stick.

With CD, DVD, or BD, the firmware is supposed to follow

the El Torito pointers to one of the three boot images.

It has to be stated that the mix of MBR and GPT

partitions is not compliant to UEFI specs, which

demand either MBR pointing to the FAT image, or GPT

pointing to it, but not both. The presence of APM

is possible only by disguising useless x86 machine

code as APM block 0.

I am not sure whether kyvaith needs to use xorriso.

After all, mjg used genisoimage to produce the

Fedora LiveCD image. He augmented isohybrid.c out of

the SYSLINUX package by --uefi and --mac for this

purpose.

So my proposals to kyvaith:

Follow http://www.syslinux.org/wiki/index.php/Isohybrid#UEFI

and let genisoimage resp. original mkisofs produce UDF.

Mention the Mac image by another -e, use isohybrid.c with

--uefi and --mac. Get a recent SYSLINUX. Old isohybrid.c

is quite buggy.

If for any reason this is not viable, then create an ISO/UDF

hybrid by any mkisofs clone without giving special boot

options. Then use xorriso to add another ISO session to the

image and to set up the boot pointers.

We could discuss this further at bug-xorriso@gnu.org

Have a nice day :)

Thomas

Link to comment
Share on other sites

Hi,

i am the devolper of xorriso. Apologies for it being

complicated with booting. It's due to the topic

http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

because of the constraints of a mkisofs compatible

options emulation, and because i had to learn on the

topic while implementing. (I also read UDF specs

and can recommend them for those who find man xorrisofs

too easy to read.)

 

Great to have you here  :thumbup

 

Just for the record, for those that think that UDF specs are too easy :w00t:, I would suggest the UEFI ones (all the 2200+ pages of it) :ph34r:

 

jaclaz

Link to comment
Share on other sites

Hi,

jaclaz wrote:

> I would suggest the UEFI ones (all the 2200+ pages of it)

Tripredacus wrote:

> I think I have read about 10 pages of the UEFI 2.3.1 spec.

For me only the 13 pages of chapter 5 "GUID Partition Table"

and the half page of 12.3.2.1 "ISO-9660 and El Torito",

please. I'm on diet.

I have to stress that i have nearly no knowledge about

boot loaders and sub-zero knowledge about booting of

MS-Windows. The boot data generated by xorriso mainly

address the stage before the first bootloader takes

over, plus some heuristic patching of BIOS related boot

code according to prescriptions of SYSLINUX and GRUB2.

But if the problem of kyvaith is really about that

kind of UDF, which is in reach of mkisofs, then the

rest of the goal should be achievable.

BTW: I would be interested to see the UDF/ISO which

succeeds with booting MS-Windows. (First my browser was

too old for the storage site. Now the links are removed.)

Maybe i can propose a different theory why it succeeds ...

or maybe i can propose a xorriso run to beef it up

to the mjg layout.

BBTW: Is there a way to get notified by mail about new

posts in this thread ?

Have a nice day :)

Thomas

Link to comment
Share on other sites

#scdbackup - You can click the "follow topic" at the very top of the page on the right. I am very happy that you joined this thread. You may be right that basically I do not need to do a hybrid ISO, so lets forget about whole hybridizing thing. I did some tests. All tests on VirtualBox. On VMWare and native, still the only way for me to boo Windows is jump grom grub2-efi to EFI Shell, and then to bootmgfw.efi.

 
 
OSCDIMG on Windows:
 
OK, but boot directly to Windows
%USERPROFILE%\Desktop\oscdimg.exe -lKyvaithService -m -o -u2 -udfver102 -bootdata:2#p0,e,b.\boot\etfsboot.com#pEF,e,b.\efi\microsoft\boot\efisys_noprompt.bin .\ %USERPROFILE%\LUN0.iso

OK, but boot directly to Windows

%USERPROFILE%\Desktop\oscdimg.exe -lKyvaithService -m -o -u2 -udfver102 -bootdata:2#p0,e,b.\boot\grub\i386-pc\eltorito.bin#pEF,e,b.\efi\microsoft\boot\efisys_noprompt.bin .\ %USERPROFILE%\LUN0.iso

BROKEN, error while loading Windows from GRUB2

%USERPROFILE%\Desktop\oscdimg.exe -lKyvaithService -m -o -u2 -udfver102 -bootdata:2#p0,e,b.\boot\grub\i386-pc\eltorito.bin#pEF,e,b.\boot\efiboot.img .\ %USERPROFILE%\LUN0.iso

OK, Windows boot from GRUB2 menu (bootmgfw.efi)

%USERPROFILE%\Desktop\oscdimg.exe -lKyvaithService -j1 -u1 -e -m -h .\ %USERPROFILE%\LUN0.iso

BROKEN, error while loading Windows from GRUB2

%USERPROFILE%\Desktop\oscdimg.exe -lKyvaithService -j1 -e -m -h .\ %USERPROFILE%\LUN0.iso

BROKEN, error while loading Windows from GRUB2

%USERPROFILE%\Desktop\oscdimg.exe -lKyvaithService -j1 -u1 -e -m -h -bootdata:2#p0,e,b.\boot\grub\i386-pc\eltorito.bin#pEF,e,b.\boot\efiboot.img .\ %USERPROFILE%\LUN0.iso

BROKEN, error while loading Windows from GRUB2

%USERPROFILE%\Desktop\oscdimg.exe -lKyvaithService -j1 -u1 -e -m -h -bootdata:2#p0,e,b.\boot\etfsboot.com#pEF,e,b.\boot\efiboot.img .\ %USERPROFILE%\LUN0.iso
 
MKISOFS on Linux:
 
OK, Windows boot from GRUB2 menu (bootmgfw.efi)
mkisofs -iso-level 4 -U -udf -V "KyvaithService" -o ../LUN0.iso ./

OK, Windows boot from GRUB2 menu (bootmgfw.efi)

mkisofs -iso-level 4 -U -V "KyvaithService" -o ../LUN0.iso ./

BROKEN

mkisofs -iso-level 4 -U -V "KyvaithService" -b boot/grub/i386-pc/eltorito.bin -no-emul-boot -boot-load-size 4 -boot-info-table -o ../LUN0.iso .

OK, Windows boot from GRUB2 menu (bootmgfw.efi), but don't boot from legacy

mkisofs -iso-level 4 -U -V "KyvaithService" -b boot/grub/i386-pc/eltorito.bin -no-emul-boot -boot-load-size 4 -boot-info-table -no-boot -o ../LUN0.iso .
 
Conclusions:
  1. In fact, Windows does not require the UDF file system to boot from EFI, although using the  oscdimg without UDF switch, Windows wont start (??)
  2. Windows will not start if inside the FAT12 ELTorito, is another bootx64.efi than a copy of cdboot_noprompt.efi
  3. Windows starts up with grub2, if inside the ISO there is no any ELTorito images.
 
I have no idea what's going on. ISO9660 grub2 driver may maps EFI path in wrong? But it also does not make sense.
Edited by kyvaith
Link to comment
Share on other sites

@kyvaith

With all due respect :) your post is confusing.

Please edit/reformat your post, adding to EACH of the methods you tried a number like (example):

Test #1:

Command issued:

%USERPROFILE%\Desktop\oscdimg.exe -lKyvaithService -m -o -u2 -udfver102 -bootdata:2#p0,e,b.\boot\etfsboot.com#pEF,e,b.\efi\microsoft\boot\efisys_noprompt.bin .\ %USERPROFILE%\LUN0.iso

 

Other needed info: [1] As an example etfsboot.com is ....., efysis_noprompt.bin is, the contents of the root are ..... 

Result (BIOS platform): [2]  OK, but boot directly to Windows

Result (UEFI platform): [2]  OK, but boot directly to Windows

 

So that maybe we can reference each of your nice tests properly. :unsure:

 

 

And the actual tests that you should have made with mkisofs are the ones along the lines of what cdob suggested, usually there are reasons for what he suggests :yes:.

 

jaclaz

 

 

 

[1] some of the command lines you posted or their result make NO SENSE unless it is detailed what the involved files are

[2] here also  you might be more explicit, and together with the info provided in [1] this  

"OK, Windows boot from GRUB2 menu (bootmgfw.efi), but don't boot from legacy" might become understandable (as is I cannot understand it :blushing:)

Edited by jaclaz
Link to comment
Share on other sites

Hi,

i assume

-bootdata:2#p0,e,b.\boot\etfsboot.com#pEF,e,b.\boot\efiboot.img

is some shortcut for the options -p, -e, -b as listed in the

technet.microsoft.com manual of oscdimg.

If so, then i can quite follow the conclusions 1 and 3.

(Number 2 is out of my scope.)

kyvaith wrote:

> Conclusions:

> 1. In fact, Windows does not require the UDF file system to boot from EFI

Then we probably do not need mkisofs/genisoimage.

(But you did not explicitely show a try of mkisofs -udf -b.)

> 3. Windows starts up with grub2, if inside the ISO there is no

> any El Torito images.

http://www.uefi.org/sites/default/files/resources/2_4_Errata_B.pdf

12.3.2 "Partition Discovery" describes precedence of GPT over

El Torito over "legacy" MBR. The examples produce neither GPT

nor MBR.

So maybe El Torito captures the device description and the

Microsoft boot loader compensates for this.

Or maybe El Torito brings the boot process to the GRUB2

in the ISO, which then fails for its own reasons.

(See below, fallback GRUB2 theory.)

> OK, Windows boot from GRUB2 menu (bootmgfw.efi), but don't boot from legacy

> mkisofs ... -b ... -no-boot ...

The -no-boot option is supposed to mark in the El Torito

boot catalog the entry of the -b image file as not being

usable. This might have the same effect to the firmware

as if the entry was not there.

Whatever, the main question is how does the firmware find

the first GRUB2 file (bootx64.efi, i assume) inside the FAT

image file /boot/efiboot.img of the ISO filesystem ?

The two first successful mkisofs runs give no clue by El Torito

or partition tables.

Do you perhaps fall back to the GRUB2 on some other device ?

Have a nice day :)

Thomas

Link to comment
Share on other sites

Not to add any confusion to the subject already... but the terms "Windows" is being used interchangeably with "WinPE" which is in the title. My question is what kind of difference is there when booting a WinPE or a real Windows in UEFI mode? Typically, Windows needs extra partitions and special GUIDs to boot properly, but WinPE does not, when booting from any sort of media.

 

Of course, I may be wrong and maybe a regular Windows can boot in UEFI mode from a single partition, but in my testing this hasn't been the case.

Link to comment
Share on other sites

@Trip

To clarify, this topic is about booting from a CD/DVD like device (actually physically rendered by the particular feature of some USB sticks that offer two devices or LUN's, the first one or LUN0 emulating a CD/DVD - Read Only - device) *everything* :w00t:  (and the kitchen sink ;)) on *any* machine, but limited to:

 

Live Mac OS, Linux, WinPE and install each of these systems to disk, both in EFI or MBR, on any modern PC and Macintosh

 

This is NOT about booting and running a "full" Windows from a CD/DVD like device, the interchange till now has been between WinPE and Windows (Install/Setup) which is a WinPE to all effects, no hard disk like device or partition on it is involved or harmed in the making of this (yet), if not the APM partition seemingly needed for a given range of macs, but still a partition residing on the CD/DVD like device.

 

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

This, I think is out of my reach. It seems to me that there are two problems (these are just my guesses):

 
1. Lack of ISO9660 driver, in the VMWare Player EFI implementation and native machines.
2. Incorrect ISO9660 driver addressing VirtualBox's EFI.
3. It has nothing in common with GRUB2. Thesame situation is with Reffit, Reffind, Clover, ELILO etc.
 
Ad. 1. In the VMWare Player, ISO9660 partition is reported as block device, not a file system. By this, EFI applications (if they do not have their own driver) can not read information from ISO9660 part of DVD.
 
VMWare:
vmware.png
 
 
Ad. 2. If inside ISO image, there is a FAT ELTorito image, EFI thought that the whole DVD consists only of this ELTorito image. By this, even if EFI has ISO9660 driver, Windows can not find a ISO9660 partition. If, EL Torito image is not there, driver addresses the ISO9660 file system and Windows runs.
 
VirtualBox:
virtualbox.png
 
I tried to manually load the drivers ISO9660 in VMWare Player, but despite a successful load, the EFI Shell can not detect the ISO9660 file system (probably because the address is already occupied by the image ELTorito).
 
A few highlights:
- Writing Windows, I mean Windows Preinstalation Enviroment.
- Speaking Universal, I mean running on any x86_64 platform. 
- I'm not a develope. I'm trying to prepare this thumb just for fun, hoping someone will like this project.
- My English is very poor, so not everyone can understand me, I'm sorry.
 
In summary, the topic requires further analysis, but I do not know what I might do next. :(
Edited by kyvaith
Link to comment
Share on other sites

Hi,

kyvaith wrote:

> 1. Lack of ISO9660 driver, in the VMWare Player EFI implementation

> and native machines.

But EFI should not need to peek into ISO 9660.

The El Torito catalog should point it to the FAT filesystem,

where the program bootx64.efi should have or find enough

brain to start up the GRUB2 system. So bootx64.efi needs

an ISO 9660 driver, not EFI. Since it works for Linuxes,

i assume that this driver is ok.

> 3. It has nothing in common with GRUB2. Thesame situation is with

> Reffit, Reffind, Clover, ELILO etc.

So MS-Windows expects some preparations or messages,

which \efi\microsoft\boot\efisys_noprompt.bin does

provide, but the others do not.

> In summary, the topic requires further analysis, but I do not

> know what I might do next.

Seems you need a way to run the programs in efisys_noprompt.bin

between GRUB2 and MS-Windows, or you need to find out

what is the magic in those programs.

Have a nice day :)

Thomas

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...