Hello Thomas, Thomas Schmitt via Syslinux said on Sun, Oct 25, 2015 at 04:35:57PM +0100:>I assume you can boot Fedora Live CD on the same (virtual) hardware.Not sure for Fedora, but the system is installed with either RHEL6, RHEL7 or Ubuntu 14.04 depending on the Lab I'm making on it without issue.>Just to make sure that the firmware works so far.Globally they do ;-)> xorriso version : 1.4.1 > Version timestamp : 2015.10.25.123601Yep.> $xorriso -as mkisofs ...your.genisoimage.arguments... >Let's see whether my emulation knows all your options.# ./mkisouefi 30000+0 records in 30000+0 records out 30720000 bytes (31 MB) copied, 0.0786484 s, 391 MB/s mkfs.fat 3.0.20 (12 Jun 2013) GNU xorriso 1.4.1 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:testuefi.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 33.0g free xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules xorriso : FAILURE : -as mkisofs: Unrecognized option '-efi-boot' xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE So the efi-boot option is not known.>In any case i would be interested to see what xorriso reports >about the boot equipment of your already existing ISO > > $xorriso -indev ...path.to.ISO... \ > -report_el_torito plain \ > -report_system_area plain \ > -print '' \ > -print '===== Proposed bootability options with -as mkisofs :' \ > -print '' \ > -report_el_torito as_mkisofs \ > -print ''>From an iso made with the local mksiofs:# xorriso -indev /tmp/uefi.8274/testuefi.iso -report_el_torito plain -report_system_area plain -print '' -print '===== Proposed bootability options with -as mkisofs :' -print '' -report_el_torito as_mkisofs -print '' GNU xorriso 1.4.1 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Loading ISO image tree from LBA 0 xorriso : UPDATE : 6 nodes read in 1 seconds xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded Drive current: -indev '/tmp/uefi.8274/testuefi.iso' Media current: stdio file, overwriteable Media status : is written , is appendable Boot record : El Torito Media summary: 1 session, 26722 data blocks, 52.2m data, 32.9g free Volume id : 'Mindi_Image' El Torito catalog : 34 1 El Torito cat path : /boot.cat El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 15035 El Torito boot img : 2 UEFI y none 0x0000 0x00 60000 35 El Torito img path : 1 /isolinux.bin El Torito img opts : 1 boot-info-table isohybrid-suitable El Torito img path : 2 /1.img xorriso : NOTE : No System Area was loaded ===== Proposed bootability options with -as mkisofs : -V 'Mindi_Image' --modification-date='2015102801315800' -c '/boot.cat' -b '/isolinux.bin' -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e '/1.img' -no-emul-boot -boot-load-size 60000>In case it does not like your options, have a look at the proposed >ones. (Be mistrusting. It's advise from an automat.)So back to the xorriso command replacing -efi-boot with -e: # ./mkisouefi 30000+0 records in 30000+0 records out 30720000 bytes (31 MB) copied, 0.0783567 s, 392 MB/s mkfs.fat 3.0.20 (12 Jun 2013) GNU xorriso 1.4.1 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:testuefi.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 32.8g free xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules Added to ISO image: directory '/'='/tmp/uefi.8294' xorriso : UPDATE : 5 files added in 1 seconds xorriso : UPDATE : 5 files added in 1 seconds ISO image produced: 26721 sectors Written to medium : 26721 sectors at LBA 0 Writing to 'stdio:testuefi.iso' completed successfully. /tmp/uefi.8294 total 106532 drwxr-xr-x. 3 root root 4096 Oct 28 01:36 . drwxrwxrwt. 19 root root 4096 Oct 28 01:36 .. -rw-r--r--. 1 root root 30720000 Oct 28 01:36 1.img -rw-r--r--. 1 root root 18557142 Oct 28 01:36 initramfs-3.10.0-229.el7.x86_64.img -rw-r--r--. 1 root root 40960 Oct 28 01:36 isolinux.bin drwxr-xr-x. 2 root root 4096 Oct 28 01:36 mnt -rw-r--r--. 1 root root 54724608 Oct 28 01:36 testuefi.iso -rwxr-xr-x. 1 root root 5026624 Oct 28 01:36 vmlinuz-3.10.0-229.el7.x86_64 So works fine this time :-) But booting from the generated ISO doesn't change anything. Still the red screen, no syslinux menu or text displayed. Is there a way to increase the debug level of syslinux.efi in order to check what it tries to do and diagnose more precisely what happens ? Thanks again for your help Thomas, bruno. -- Open Source Profession, Linux Community Lead WW http://opensource.hp.com HP EMEA EG Open Source Technology Strategist http://hpintelco.net FLOSS projects: http://mondorescue.org http://project-builder.org Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
Bruno Cornec via Syslinux said on Wed, Oct 28, 2015 at 01:45:22AM +0100:>Is there a way to increase the debug level of syslinux.efi in order to >check what it tries to do and diagnose more precisely what happens ?Ok, I tried to modify mk/devel.mk to put: GCCWARN += -Wno-clobbered -DCORE_DEBUG=1 -DDEBUG_MALLOC -DDEBUG_THREAD And removing the -DDYNAMIC_DEBUG but now syslinux doesn't want to build: ranlib liblpxelinux.a ld -m elf_i386 -Bsymbolic -pie -E --hash-style=gnu -T /root/syslinux/core/i386/syslinux.ld -M -o ldlinux.elf ldlinux.o \ --start-group libcom32.a --whole-archive /root/syslinux/bios/com32/lib/libcom32core.a libldlinux.a --end-group \ > ldlinux.map libcom32.a(font.o): In function `SEG': /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' libcom32.a(bios.o): In function `SEG': /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' make[3]: *** [ldlinux.elf] Error 1 make[3]: Leaving directory `/root/syslinux/bios/core It seems that the kaboom.c file is not compiled with the lib to define the function, but I'm absolutely unclear on what to do to fix this :-( Bruno. -- Open Source Profession, Linux Community Lead WW http://opensource.hp.com HP EMEA EG Open Source Technology Strategist http://hpintelco.net FLOSS projects: http://mondorescue.org http://project-builder.org Musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
Hi, obviously the SYSLINUX problem with EFI-in-ISO is not bound to the size of the FAT filesystem or the way it is advertised in El Torito. ------------------------------------------------------------------ More or less off topic for this thread:> xorriso : FAILURE : -as mkisofs: Unrecognized option '-efi-boot'Ah yes. A near miss. xorrisofs has an option --efi-boot with two dashes. Introduced for grub-mkrescue with automatic -eltorito-alt-boot -no-emul-boot . And it has -e, requested by a Fedora user. I see that Fedora's -e is an alternative for Fedora's -efi-boot, so your changed script should work with Fedora's genisoimage, too: http://linuxmanpages.net/manpages/fedora16/man1/genisoimage.1.html I mention Fedora, because El Torito EFI images are not supported by Debian's genisoimage.> > xorriso -indev ....iso -report_el_torito as_mkisofs \Saved you a lot of searching in the man page. :)) In the native command set of xorriso 1.4.1 it has a new companion -boot_image any replay which after ISO image manipulations re-applies the boot options as told by the native command reporter -report_el_torito cmd with really ugly output, i confess. The job of mkisofs emulation was not the original goal of xorriso. It rather was founded as a backup tool for creating and updating ISO filesystems on optical media. Users forced me to learn the other stuff. The scattered semantics of command -boot_image reflect this history.> > -report_el_torito plain \> Drive current: -indev '/tmp/uefi.8274/testuefi.iso' > ... > El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA > El Torito boot img : 1 BIOS y none 0x0000 0x00 4 15035 > El Torito boot img : 2 UEFI y none 0x0000 0x00 60000 35This ISO (i assume from Fedora's genisoimage under the name "mkisofs") has an EFI boot image smaller than 32 MB. All its El Torito parameters are appropriate for EFI. (Note that LBA (Logical Block Address) is told in 2048 byte blocks whereas Ldsiz (Load Size) is in blocks of 512 bytes. Not very consistent, but that's how El Torito expresses position and size.)> > -report_system_area plain \ > xorriso : NOTE : No System Area was loadedNo isohybrid, no MBR partitions, no GPT. I.e. no boot from USB stick. Most bootable Linux ISOs have equipment which xorriso could reproduce. In any position among the -as mkisofs arguments: -isohybrid-mbr $path_to_isohdpfx.bin_or_to_isohybrid_ISO_image \ and after option -e: -isohybrid-gpt-basdat There is also a HFS+ image in Fedora Live which gets advertised by GPT and Apple Partition Map. But your ISO has no such file. Fedora Live CD is obviously the reason why SYSLINUX program isohybrid learned EFI and APM. See http://mjg59.dreamwidth.org/11285.html and older articles from that series by Matthew Garrett. But it does not use SYSLINUX for EFI. Have a nice day :) Thomas
On Tue, Oct 27, 2015 at 10:15 PM, Bruno Cornec via Syslinux <syslinux at zytor.com> wrote:> Bruno Cornec via Syslinux said on Wed, Oct 28, 2015 at 01:45:22AM +0100: >> >> Is there a way to increase the debug level of syslinux.efi in order to >> check what it tries to do and diagnose more precisely what happens ? > > > Ok, I tried to modify mk/devel.mk to put: > GCCWARN += -Wno-clobbered -DCORE_DEBUG=1 -DDEBUG_MALLOC -DDEBUG_THREAD > And removing the -DDYNAMIC_DEBUG but now syslinux doesn't want to build:MALLOC and THREAD are two debugs you probably don't want. If you can capture the serial port and the firmware would allow it, "-DDEBUG_PORT=0x3f8" would direct output to the first serial port. "-DDEBUG_STDIO" may be useful but by the looks of it, not until after ldlinux.* is loaded as printf()'s code isn't in the core but ldlinux.*.> ranlib liblpxelinux.a > ld -m elf_i386 -Bsymbolic -pie -E --hash-style=gnu -T > /root/syslinux/core/i386/syslinux.ld -M -o ldlinux.elf ldlinux.o \ > --start-group libcom32.a --whole-archive > /root/syslinux/bios/com32/lib/libcom32core.a libldlinux.a --end-group \ > > ldlinux.map > libcom32.a(font.o): In function `SEG': > /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' > /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' > libcom32.a(bios.o): In function `SEG': > /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' > /root/syslinux/com32/include/com32.h:144: undefined reference to `__bad_SEG' > make[3]: *** [ldlinux.elf] Error 1 > make[3]: Leaving directory `/root/syslinux/bios/core > > It seems that the kaboom.c file is not compiled with the lib to define > the function, but I'm absolutely unclear on what to do to fix this :-(kaboom.c is in the core, not ldlinux.*. I can't say I've ever seen this before. -- -Gene