Jump to content

scdbackup

Member
  • Posts

    4
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Germany

Posts posted by scdbackup

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

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

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

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

×
×
  • Create New...