El 23/01/16 a las 09:21, Thomas Schmitt escribió:
There is a fourth dimension to be expressed: Bootloader. Then there is the dimension of ISO filesystem objects. A user wish would contain at least ISO-Object, Bootloader, Medium, Firmware, Architecture E.g. Appended Partition, with GRUB2 content, for CDROM and HDD, via EFI, on i386 ISO Data File, with SYSLINUX content, for HDD, via BIOS, on i386 and amd64 I am not sure whether this list of more or less combinable dimensions is complete yet. Further one will want to express whether the gaps between partitions should be filled, which kinds of partition tables shall emerge, ... These properties are global to the ISO, not specific to a single boot image. Some are combinable, some are mutally exclusive. (Maybe it is time to break out an UML editor.)
I propose you to send these concerns to live-wrapper project which has just begun and it's advertised as highly modular by Iain. It would be quite nice if all these concerns were properly addressed by Iain's tool.
I am not saying that they are not welcomed to live-build but, right now, I think we should focus on making UEFI to boot and not re-thinking all the bootloader handling.
grub-mkrescue layout is rarely used for distro ISOs. I blame this on the existing SYSLINUX based production software for distro ISOs. In principle, a pure GRUB2 or a pure SYSLINUX equipment appears to be the more reasonable choice.
I once asked in a Debconf why the people were so stubborn to use syslinux instead of using grub2 (which seems technically superior to me). It would seem that the same people that maintain syslinux happen to maintain the kernel boot stack (or whatever it is called, I mean what happens just after the bootloader handling the execution to the kernel). So, that means, it's far easier to them to debug why the kernel is refusing to boot.
I am personally in a favour of GRUB2-only Live CDs so that it's much easier to have native Super Grub2 Disk in them :) .
Maybe we can just name them as: "Main bootloader" and "Alternate bootloader".The model does not imply any ranking. "First", "Second", "Third" could be justified, because there are lists in El Torito and partition tables where the boot entries have to line up in sequence. For my taste, "Main" or "Primary" too much implies a rank.
So... what about using: FIRST_BOOTLOADER and SECOND_BOOTLOADER instead of my current: PRIMARY_BOOTLOADER and SECONDARY_BOOTLOADER ?I could even add a third bootloader if needed. And, well, I have some ideas on how to add some special functions to binary_bootloader files so that we have some sort of Object-Oriented / Hook programming when defining what goes into the mkisofs options.
If you check current: binary_iso file it just relies on existing binary_bootloaders without having an agnostic bootloader approach.
Here it's what I'm talking about:
https://github.com/adrian15/live-build/blob/5eba3dff5a16a34c3c1eb5d54e3767339654e2d0/scripts/build/binary_iso#L111-L145
case "${LB_PRIMARY_BOOTLOADER}" in
grub)
(...)
grub-pc)
(...)
esac
We could just invent the:
grub-pc-xorriso-options()
or
syslinux-xorriso-options()
functions which would be defined in:
binary_grub-pc
or
binary_syslinux
files
and handle all of these with only 3 or 4 lines of code.
E.g. binary_iso would add '-eltorito-alt-boot' just before a second
bootloader so that the bootloader only needs to take care of their own
boot options.
Is there anyone opposed to such a big change on live-build handling of bootloaders?
adrian15 --Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/