Actually, as you may have questions with some elements you'll see in the log, and especially: Detected Syslinux version: 6.03/20150819 (from '/EFI/BOOT/isolinux.bin') So I should point out that EFI/grub is actually used by the tails people to chain load EFI/Syslinux (hence the ldlinux.e64, ldlinux.c32 as well as isolinux.bin one also sees in /efi/boot/). As a result, in the previously attached log, the Syslinux version is retrieved from /efi/boot/isolinux.bin rather than /isolinux/isolinux.bin... which probably serves my point about some of the fragility of this process, in case different 'isolinux.bin' versions are being used, though this is a path processing issue that has little to do with versioning. Regards, /Pete
> Actually, as you may have questions with some elements you'll see in the > log, and especially: > > Detected Syslinux version: 6.03/20150819 (from '/EFI/BOOT/isolinux.bin') > > So I should point out that EFI/grub is actually used by the tails people > to chain load EFI/Syslinux (hence the ldlinux.e64, ldlinux.c32 as well > as isolinux.bin one also sees in /efi/boot/). > > As a result, in the previously attached log, the Syslinux version is > retrieved from /efi/boot/isolinux.bin rather than > /isolinux/isolinux.bin... which probably serves my point about some of > the fragility of this process, in case different 'isolinux.bin' versions > are being used, though this is a path processing issue that has little > to do with versioning. > > Regards, > > /PeteThis is going to sound "off-topic" in the Syslinux Mailing List; it is not. I am using the ISO image from TAILS as an excuse to "tease" TAILS' devs and other users of Syslinux. If intrigeri (TAILS developer) "bites". then users reading this mailing list might learn one thing or two about Syslinux (6.04-pre1+). 1_ EFI/BOOT/isolinux.bin is probably a mistake (or misunderstanding) originated in the ISO building scripts for TAILS, as this file is worthless for EFI. From the list of files, probably this is not the only file from Syslinux that could be deleted in this ISO image. 2_ The whole EFI\BOOT\grub directory could potentially be deleted. IIRC, the initial intention of having both, syslinux.efi and grub.efi in TAILS was to _automatically_ load the adequate efi binary for each EFI architecture (x86 / ia32), overcoming a (prior) limitation in Syslinux. Syslinux 6.04-pre1 already includes a solution for this situation. We'll see whether intrigeri bites ;). However, I do not see "ldlinux.e32" in the list provided by Pete, so perhaps TAILS' devs. have decided to just use grub.efi (and no chainloading)? 3_ When building the ISO image, the script(s) should rather move everything from the "isolinux" directory to a "syslinux" directory. The same goes to the cfg file name, as isolinux.bin can use "syslinux.cfg" just fine. Then the ISO building script should use this "syslinux/" path for the location of isolinux.bin. This is, of course, for BIOS, as "isolinux" has nothing to do with UEFI. For possible reference, GpartedLive and ClonezillaLive are already using this naming convention. All the above steps would simplify the directory tree, would simplify the steps for writing a bootable USB drive using the content of the ISO image, would reduce the need to maintain grub.efi too (in addition to syslinux.efi), and would reduce the size of the resulting ISO image. Having said that, I have not tested Syslinux 6.04-pre1 yet (nor recent TAILS ISO images), so the actual result of the above suggestions might not be a success. Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
Hi, Pete Batard via Syslinux:> So I should point out that EFI/grub is actually used by the tails people to chain > load EFI/Syslinux (hence the ldlinux.e64, ldlinux.c32 as well as isolinux.bin one > also sees in /efi/boot/).Wait, no, there's some misunderstanding going on here. There are three cases for Tails, let me show you what's used in each case: * BIOS: isolinux/, business as usual * 64-bit UEFI: EFI/BOOT/bootx64.efi, which is syslinux * 32-bit UEFI: EFI/BOOT/bootia32.efi, which is GRUB that loads the syslinux config with the syslinux_configfile directive; we do that due to the fact that the we can put only one set of *.c32 modules and syslinux configuration, for one single architecture, in EFI/BOOT; I'll look into commit 7d9c9ec ("Add architecture-specific config name to search") later as this might allow us to drop GRUB, which would make the whole thing a bit more straightforward Regards, -- intrigeri
Hi, Ady:> I am using the ISO image from TAILS as an excuse to "tease" TAILS' devs > and other users of Syslinux. If intrigeri (TAILS developer) "bites". > then users reading this mailing list might learn one thing or two about > Syslinux (6.04-pre1+).:)> 1_ EFI/BOOT/isolinux.bin is probably a mistake (or misunderstanding) > originated in the ISO building scripts for TAILS, as this file is > worthless for EFI. From the list of files, probably this is not the > only file from Syslinux that could be deleted in this ISO image.Right. We simply copy all files from the isolinux installation directory to EFI/BOOT. It does copy some useless stuff but it's simpler and easier to maintain that building+maintaining the list of what exactly we need to copy. YMMV :)> 2_ The whole EFI\BOOT\grub directory could potentially be deleted. > IIRC, the initial intention of having both, syslinux.efi and grub.efi > in TAILS was to _automatically_ load the adequate efi binary for each > EFI architecture (x86 / ia32), overcoming a (prior) limitation in > Syslinux. Syslinux 6.04-pre1 already includes a solution for this > situation. We'll see whether intrigeri bites ;).Assuming you're referring to commit 7d9c9ec ("core/fs/lib/loadconfig.c: Add architecture-specific config name to search"): right, I do intend to look into it, and indeed this will most likely allow us to drop GRUB for ia32 EFI. Thanks! But quite frankly I'd rather wait for 6.04 to be actually released. Now tracked on Tails' side: https://labs.riseup.net/code/issues/12440> However, I do not see "ldlinux.e32" in the list provided by Pete, so > perhaps TAILS' devs. have decided to just use grub.efi (and no > chainloading)?Exactly. I didn't manage to chainload 32-bit syslinux EFI from GRUB, and I didn't bother since GRUB's syslinux_configfile works fine for us.> 3_ When building the ISO image, the script(s) should rather move > everything from the "isolinux" directory to a "syslinux" directory. The > same goes to the cfg file name, as isolinux.bin can use "syslinux.cfg" > just fine. Then the ISO building script should use this "syslinux/" > path for the location of isolinux.bin. This is, of course, for BIOS, as > "isolinux" has nothing to do with UEFI. For possible reference, > GpartedLive and ClonezillaLive are already using this naming > convention.That's interesting, I didn't know that isolinux.bin could read a syslinux.cfg file :) This would simplify the USB installers' job: IIRC they currently have to rename isolinux ? syslinux, isolinux.cfg ? syslinux.cfg, and to do adjust the config files accordingly. I've filed a ticket in our task/bug tracker so it stays on my radar: https://labs.riseup.net/code/issues/12439> All the above steps would simplify the directory tree, would simplify > the steps for writing a bootable USB drive using the content of the ISO > image, would reduce the need to maintain grub.efi too (in addition to > syslinux.efi), and would reduce the size of the resulting ISO image.Absolutely. Thanks a lot for these helpful suggestions :) Regards, -- intrigeri
On 2017.04.12 08:35, intrigeri via Syslinux wrote:> Wait, no, there's some misunderstanding going on here.Okay, I stand corrected. Knowing that tails was Debian based, I was assuming that you also followed the Debian boot model, which uses GRUB for UEFI. Considering that this is the Syslinux mailing list, it might be a tactless question to ask, but is there any reason why you chose to deviate from the Debian boot process, and not use GRUB alone for UEFI Especially considering that you then have an issue with the .c32 modules, I am curious as to what you you considered to be a serious enough limitation from GRUB, to only use it as an intermediate for Syslinux boot. Regards, /Pete