Re: isorecorder
Hi Thomas,
On 2021.01.11 07:53, Thomas Schmitt wrote:
Hi,
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
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1886148
and with old HPs which are well known to boot only if some MBR partition
bears the boot flag
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1899308
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.
Regards,
/Pete
[1] https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1895131
Reply to: