scdbackup

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

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

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

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