syslinux and isolinux in salix 14.0alpha1

[Adys]

I'd like to suggest a couple of changes to Salix14.0alpha1 in relation to syslinux/isolinux.

Suggestion #1:
______________

Since the ISO images are isohybrid and are using ISOLINUX 4.05, the cfg file can be changed to from "/[boot/]isolinux/isolinux.cfg" to "/[boot/]syslinux/syslinux.cfg" without any negative effects.

Changing the directory and the configuration file to "syslinux" should help booting UFD when built with the dd command (isohybrid).

The only caveat is that all current references to "isolinux/isolinux.cfg" in any other file (or script) should be changed.

Note: "syslinux" is a generic term for Syslinux 4.05 (in fact, since some versions before 4.05 too), and booting the ISO image or the physical optical media with ISOLINUX (isolinux.bin) should work exactly the same when the configuration file is "/[boot/][syslinux/]syslinux.cfg".


Suggestion #2:
______________

It could be useful to include a C32 Syslinux module that is capable of comparing the checksums and the actual files. This is useful after burning the CD, and such Syslinux module already exists (I have used it myself in customized Syslinux-bootable CDs). This method is safer and simpler than actually booting Linux just to be able to run some md5sum (or md5deep) command on the files (as many other distros do). If there is interest, I can provide details about this C32 Syslinux module and how to work with it.

[Adys]

BTW, I downloaded Salix14.0alpha1 x32. It is not ready for isohybrid (in opposition to what the main announcement says) and it was edited by isomaster before its release (so the mkisofs command is not shown either).

[gapan]

BTW, I downloaded Salix14.0alpha1 x32. It is not ready for isohybrid (in opposition to what the main announcement says) and it was edited by isomaster before its release (so the mkisofs command is not shown either).

Yes, I did a last minute edit on the 32-bit iso with isomaster and then I forgot to run isohybrid. Not a big deal for an alpha.

[gapan]

Changing the directory and the configuration file to "syslinux" should help booting UFD when built with the dd command (isohybrid).

What is UFD?

It could be useful to include a C32 Syslinux module that is capable of comparing the checksums and the actual files. This is useful after burning the CD, and such Syslinux module already exists (I have used it myself in customized Syslinux-bootable CDs). This method is safer and simpler than actually booting Linux just to be able to run some md5sum (or md5deep) command on the files (as many other distros do). If there is interest, I can provide details about this C32 Syslinux module and how to work with it.

I have no idea what you're talking about or what a C32 syslinux module is.

[Andyun]

UFD - USB Flash Drive.

[gapan]

OK. How would changing the name from isolinux to syslinux help with booting?

[Adys]

@gapan,

The first suggestion is for using the ISO image / CD content directly in a USB drive, usually by means of isohybrid. Simply put: change "isolinux" paths to "syslinux". The "syslinux" paths will boot both (CD with isolinux.bin, and USB drive with ldlinux.sys), while "isolinux" paths will boot only CDs.

In my second suggestion, I am referring to an-already-existant COM32 Syslinux module and testing that a CD is correctly burnt on optical media.
When a user downloads the ISO image, the md5 should be checked against it. But after burning the optical media, the md5 posted in the download pages is no longer helpful to evaluate whether the CD was burnt correctly. Some distros have a boot option that starts a minimalistic system and automatically runs a checksum on all the files burnt, against a specific file containing the md5 checksums that are supposed to be correct. When the comparison finishes, the user knows whether the files have been burnt correctly or not. There is no doubt, no "try burning the CD again".
But that method already depends on a relatively big part of the files to be correctly burnt. There is an alternative so to accomplish the same goal, and it depends on a small amount of small sized files. The alternative uses Syslinux (isolinux, syslinux, or whichever variant of the Syslinux family), one md5 text file and one COM32 syslinux module (a file named md5sum.c32)

Hopefully I explained the general concept better now, and if there is interest on this, I will provide more info. If there is no interest, then my second suggestion finishes here (there would be no point for me to expand the explanation into details if there is no interest in the concept / goal).

[gapan]

The first suggestion is for using the ISO image / CD content directly in a USB drive, usually by means of isohybrid. Simply put: change "isolinux" paths to "syslinux". The "syslinux" paths will boot both (CD with isolinux.bin, and USB drive with ldlinux.sys), while "isolinux" paths will boot only CDs.

I still don't understand how that will change anything. It already works with USB drives as it is. The ISOs are isohybrid and can be put on a USB drive with dd. I think I already explained above that the 32-bit iso is not currently hybrid, but that was a mistake.

In my second suggestion, I am referring to an-already-existant COM32 Syslinux module and testing that a CD is correctly burnt on optical media.
When a user downloads the ISO image, the md5 should be checked against it. But after burning the optical media, the md5 posted in the download pages is no longer helpful to evaluate whether the CD was burnt correctly. Some distros have a boot option that starts a minimalistic system and automatically runs a checksum on all the files burnt, against a specific file containing the md5 checksums that are supposed to be correct. When the comparison finishes, the user knows whether the files have been burnt correctly or not. There is no doubt, no "try burning the CD again".
But that method already depends on a relatively big part of the files to be correctly burnt. There is an alternative so to accomplish the same goal, and it depends on a small amount of small sized files. The alternative uses Syslinux (isolinux, syslinux, or whichever variant of the Syslinux family), one md5 text file and one COM32 syslinux module (a file named md5sum.c32)

But you can already check all packages after you burned the CD. Exit the installation as soon as it starts and run:

Code: Select all

md5sum -c CHECKSUMS.md5

or mount the CD, and run the same command inside the mountpoint.

[Adys]

I still don't understand how that will change anything. It already works with USB drives as it is. The ISOs are isohybrid and can be put on a USB drive with dd. I think I already explained above that the 32-bit iso is not currently hybrid, but that was a mistake.

I'm not referring to the specific mistake of the 32-bit image. I am suggesting it for all future releases. I was trying to be concise, instead of getting into the whole specifics about Syslinux, but...

When you boot the CD, isolinux.bin (ISOLINUX loader) v4.05 will search for (squared brackets mean "optional"):
/[boot/][isolinux/]isolinux.cfg
or as a second possibility
/[boot/][syslinux/]syslinux.cfg

That second possibility was not available in older versions (3.x) of ISOLINUX. It was not a generic term; just the path for ldlinux.sys cfg file. If the "isolinux" path and cfg file are present and isolinux.bin is the loader, then it has precedence over the generic "syslinux" term.

When you boot a USB drive, ldlinux.sys (SYSLINUX and EXTLINUX loader) v4.05 will search for (squared brackets mean "optional"):
/[boot/][syslinux/]syslinux.cfg

If the USB drive is currently (14.0alpha1) correctly booting with "/[boot/][isolinux/]isolinux.cfg" anyway, this is not part of the official documented SYSLINUX/EXTLINUX loader, ldlinux.sys. It is probably accepted / used for the isohybrid MBR (I haven't verified it), but not for other methods of putting the CD content into a USB image.

AFAIK, the isohybrid MBR should also accept the generic term, "syslinux", just as isolinux.bin does (again, for the current 4.05 version of Syslinux loaders).

So the "syslinux" path and cfg file is covering more alternatives than the "isolinux" path alone, giving better chances for a user to succeed in putting Salix in a USB drive. Do you want even greater chances? Put both paths and cfg files (but I don't think it is really necessary for the current goal with the current versions of Syslinux).

In older versions (3.x), you would be forced to simultaneously use both path options, "/[boot/][isolinux/]isolinux.cfg" and "/[boot/][syslinux/]syslinux.cfg", so to cover all possibilities and alternatives. But now it is not necessary, and in case there is any intended difference you would want to achieve when booting with different media (which is not the case for Salix AFAIK), there are also new alternatives anyway.

Since you want to give the best chances of putting Salix from a CD or from the ISO image into a different media (USB drive), then I am suggesting to use "syslinux" instead of "isolinux". That is, unless there is any reason not to use the generic term in Salix standard ISO images (which I think there isn't, but I can always be wrong).

But you can already check all packages after you burned the CD. Exit the installation as soon as it starts and run:

Code: Select all

md5sum -c CHECKSUMS.md5

or mount the CD, and run the same command inside the mountpoint.

As I said, for that possibility to work, a relatively big part of the optical media already must be correct (for example, you are already able to boot it). By using the md5sum.c32 module, only a few files must comply that pre-condition and the usage for the final user is very simple (yes, even simpler than what you already described).

[gapan]

So the "syslinux" path and cfg file is covering more alternatives than the "isolinux" path alone, giving better chances for a user to succeed in putting Salix in a USB drive. Do you want even greater chances?

It's not a matter of chance. It either works or it doesn't. And it already works as it is.

As I said, for that possibility to work, a relatively big part of the optical media already must be correct (for example, you are already able to boot it). By using the md5sum.c32 module, only a few files must comply that pre-condition and the usage for the final user is very simple (yes, even simpler than what you already described).

No, you don't need to be able to boot the CD. As I said, you only need to mount it from your running system. And if you can't even boot it, what's the sense in checking individual files?