[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: isorecorder

Hi Thomas,

On 2021.01.11 07:53, Thomas Schmitt wrote:

the advantages of putting an unmodified ISO image plainly onto a USB are:
- The boot and installation process is as near to DVD as possible.
- If anything goes wrong during that process, it is clear that debian-cd
   is in charge of diagnosing and hopefully managing the effort to provide
   a correction.

Nevertheless, the goals of Pete are valid too:
- A USB stick with large FAT partition is what many users expect.
- The (unspecified by UEFI) way of copying EFI boot equipment and data
   payload into a FAT filesystem seems to be indeed the way how experienced
   users of MS-Windows prepare a bootable USB stick.
- Copying from filesystem to filesystem is at least one order of magnitude
   less prone to fatal mishaps than is copying onto a device.

Both approaches are combinable:

Yes, as we've discussed elsewhere, that is pretty much my point. Though I'll let you speak for the finer aspects of ISOHybrid, I don't see any major technical issue with ensuring that an ISO media works at both the ISO and FAT file system level.

For instance I will point out to the ArchLinux ISOs ensuring that they use a label like "ARCH_202010" which can be applied for both FAT (11 chars max, uppercase) and ISO, and makes installation media lookup by label also work when extracting content onto FAT32.

And whereas symlinks are fine (when pointing to something like a doc directory, or some other non critical part), one needs to be mindful that they will of course not translate to FAT, and therefore should not be used for mandatory installation matters.

Finally, of course, installation scripts and bootloaders should include the necessary components to deal with both ISO9660 and FAT at the file system level.

- Have all EFI equipment as directory tree in the ISO filesystem. I.e.
   not only as image file or as appended partition.
- Make sure that the installation works without name conflicts from a
   filesystem with sloppy naming rules. I.e. from FAT.

And to promote my own song:

Debian ISOs should strive for a specs compliant partition table with as
few borderline hacks as possible.

It would be fully compliant if bearing a MBR partition table with disjoint
ISO and EFI partitions. But during the Ubuntu ISO reform there were
problems with new Lenovos which booted only with GPT
and with old HPs which are well known to boot only if some MBR partition
bears the boot flag

The Lenovo case is probably not fully explored, because it seems that
the same machines boot from our current abominable MBR-with-invalid-GPT
layout. The HP case needed a small hack by adding an MBR partition of
type 0x00 and size 1 which bears the boot flag.
I am not aware of failure reports with the Ubuntu 20.10 ISOs which could
be blamed on their partition layout.

From my testing, Ubuntu 20.10 ISOs work fine when extracted to FAT32, especially as they are not relying on locating the installation media by label.

Per [1] (to which you participated and where we also discussed some of these matters) the prerelease version happened to break file extraction support, but the Ubuntu maintainers were fairly proactive in ensuring that this mode of creating media got fixed and was fully working for the release. Which is why I am expecting Debian maintainers to also recognize that ISO file extraction is legitimate method of creating installation media, that they want to (continue to) support.



[1] https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1895131

Reply to: