Feature #12439
Unify the syslinux directory & config file name between ISO and installed USB stick
0%
Description
In the ISO we ship an isolinux directory that contains an isolinux.cfg file. And then the USB installers (ours and various 3rd party ones used e.g. on Windows) have to rename isolinux → syslinux, isolinux.cfg → syslinux.cfg, and to adjust the config files accordingly.
I’m told that isolinux.bin would read that file just as well if it was called syslinux.cfg, and we can give the (currently) isolinux directory whatever name we want, as long as we tell xorriso where it is.
So it seems that we could ship a syslinux directory in the ISO, with a syslinux.cfg file in it. Then it’s probably a matter of ensuring we pass the correct -b option to XORRISO_OPTIONS so live-build’s lb_binary_iso does the right thing.
This would allow all USB installers to drop quite a bit of code, and would bring us one step closer to having “intermediary” Tails sticks look more similar to those installed with Tails Installer. I also expect it would help ensure that 3rd party USB installers do the right thing, and they would simply have nothing to do except running our embedded syslinux to have ldlinux.sys installed.
Subtasks
Related issues
|
Related to Tails - |
Resolved | ||
|
Has duplicate Tails - |
Duplicate | 2014-10-16 |
History
#1 Updated by intrigeri 2017-04-12 07:53:09
- Subject changed from Unify the syslinux directory name between ISO and installed USB stick to Unify the syslinux directory & config file name between ISO and installed USB stick
#2 Updated by intrigeri 2017-06-29 18:46:51
- Description updated
#3 Updated by intrigeri 2017-06-29 18:48:16
- has duplicate
Bug #8144: Ship syslinux.cfg instead of isolinux.cfg in the ISO added
#4 Updated by intrigeri 2018-02-06 18:17:18
- related to
Feature #15292: Distribute a USB image added
#5 Updated by intrigeri 2018-08-18 14:15:44
- related to deleted (
Feature #15292: Distribute a USB image
#6 Updated by intrigeri 2018-08-18 14:16:17
- Parent task set to
Feature #15292
I believe we have to do something like this for Feature #15292 unless we go directly to GRUB (Feature #15806).
#7 Updated by intrigeri 2018-08-18 14:16:58
- Assignee deleted (
intrigeri) - Priority changed from Low to Normal
#8 Updated by segfault 2018-08-22 09:44:32
The current prototype for Feature #15292 uses syslinux to install the SYSLINUX bootloader on the USB image, which renames the files.
#9 Updated by intrigeri 2018-08-22 10:20:50
> The current prototype for Feature #15292 uses syslinux to install the SYSLINUX bootloader on the USB image, which renames the files.
I don’t understand, sorry! Perhaps if you show me the code I’ll understand :)
#10 Updated by segfault 2018-08-22 11:09:25
segfault wrote:
> The current prototype for Feature #15292 uses syslinux to install the SYSLINUX bootloader on the USB image, which renames the files.
I was wrong, it is not syslinux that renames the files, we do it ourselves. This is the code that renames the files, and this is the code that runs syslinux.
#11 Updated by intrigeri 2018-08-22 11:31:29
> I was wrong, it is not syslinux that renames the files, we do it ourselves.
OK, so this confirms my “I believe we have to do something like this for Feature #15292 unless we go directly to GRUB (Feature #15806)”: if we don’t do what this ticket is about, we end up with a second instance of a workaround for a problem that does not exist (anymore), which is more useless code we have to maintain, which is the kind of technical debt I don’t want us to increase. Now, frankly I’d much prefer seeing us spend time on switching to GRUB2 than on cleaning this up.
#12 Updated by intrigeri 2018-08-22 11:35:58
- related to
Feature #15806: Use GRUB for USB boot on EFI 64-bit added
#13 Updated by intrigeri 2018-08-25 10:34:47
- Status changed from Confirmed to Rejected
Let’s not bother: we want to do Secure Boot soon so we can live with this code duplication for some time.