scdbackup
Content Type
Profiles
Forums
Events
Posts posted by scdbackup
-
-
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
0 -
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
0 -
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
0
Boot WinPE EFI form GRUB2 CD/DVD
in Other Operating Systems
Posted
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