On 2021.01.11 01:38, Lou Poppler wrote:
This is radically different from what I suggested above.
You mentioned cp, which I interpreted as copying extracted ISO files
onto FAT, since this is the mode I explicitly mentioned in my initial reply.
Here is my experiment:
lwp@william:~/Downloads$ wget
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
lwp@william:~/Downloads$ umount /dev/sdb1
lwp@william:~/Downloads$ sudo bash
root@william:/home/lwp/Downloads# cp debian-testing-amd64-netinst.iso /dev/sdb
root@william:/home/lwp/Downloads# sync
At this point I moved the USB stick to a Toshiba amd64 laptop,
and booted with no problems into the installer.
Notice especially that I did *not* copy the installer .iso onto a partition of
the USB stick,
I copied the image to the bare USB i.e. /dev/sdb _NOT_ /dev/sdb1
Which means that you are limiting ISOHybrid use to DD/byte-copy mode
only, which is precisely what I am trying to warn against relying solely on.
A *proper* ISOHybrid media should be able to be extracted to a FAT32
formatted partition and boot in UEFI mode.
If you don't see why supporting this mode is necessary (Again, DD
imaging doesn't work for everything, or isn't even desirable for
everything), then you are missing the points I made earlier. Especially,
some installations (e.g. Raspberry Pi) require the user to be able to
copy additional files as well as set the size and type of the partition,
or even the whole partition scheme, to something else than what the
creators of the media have hardcoded.
From talking with some of their maintainers, other distros (Arch,
Unbuntu) seem to understand that limiting the purpose of an ISOHybrid to
dd imaging only, as you appear to imply above, can be problematic, and
they are taking steps to ensure that they also support ISO file
extraction, and will continue to do so.
Moreover, the media detection scripts of Debian certainly have provision
for this mode of operation (For instance I have submitted bugfixes for
this, such as [1], that would be pointless for any other mode of operation).
So please be very mindful that, by assuming that DD imaging will be good
enough for everybody, you *are* breaking a mode of operations that some
Debian users actually rely on.
As I tried to explain previously, DD imaging of an ISOHybrid is not the
one-size-fits-all that some people seem to believe it is. Considering
that ISOHybrid is mostly a hack to make two completely separate file
systems appear to coexist as one, it does come with constraints and
limitations, and therefore, just like other distros appear to agree on,
I (and other users) do expect Debian to do what's necessary to ensure
that the mode of operation that consists of *extracting* the full
content of an ISO onto a FAT32 media, and booting it on an UEFI system,
does result in a media that can be used for Linux installation.
I would also invite folks here to be weary of having a Linux-centric
only view of how people "should" create their installation media,
because the whole point of an installer image is to make sure that the
installation experience is comprehensive enough that it doesn't alienate
users, including ones not using Linux to create their installation
media. And I'm afraid that, currently, despite what a lot of Linux folks
appear to believe, forcing everyone into using byte copy to apply an
ISOHybrid image very much does so.
As such, if Debian decides that FAT32 file copy mode for UEFI is too
much of a hassle, even as it mostly works fine (or at least it used to)
and is needed to ensure that folks can install vanilla Debian on
Raspberry Pi's (again, byte copy of the ISO will not work), then I'll
have little choice but tell Pi users to switch to a distro that does
understand that putting all of one's eggs into the DD-imaging basket of
ISOHybrid is not a good way to satisfy its userbase.
Here is what that USB stick looks like now:
Then let me highlight the various problematic elements:
root@william:/home/lwp/Downloads# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.29.2).
Some people may want to create an installation media that doubles as the
target media, because it can make the installation process A LOT easier
on some UEFI platforms. And they might want to use GPT instead of MBR
then => problematic
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sdb: 14.3 GiB, 15376318464 bytes, 30031872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5c546723
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 745471 745472 364M 0 Empty
Unmodifiable and unmountable partition => problematic
/dev/sdb2 3944 9863 5920 2.9M ef EFI (FAT-12/16/32)
Some mode of operations require the Debian installation files to reside
on the ESP, again to ensure a smooth installation experience => problematic
Windows users will see their media reduced to 2.9 MB and consider that
it has been improperly created => problematic
Now, if anyone wants to dispute that dd imaging only of ISOHybrid is
problematic, or maintain that it is the better option always, then I
will strongly invite you to read [2] and [3], which are the procedure
for *vanilla* Debian installation on Raspberry Pi 4 and Pi 3. Feel free
to then explain how ditching the extraction of ISO files to an ESP, and
trying to use DD imaging mode, will make for a user experience that even
even comes close to the one described in these guides.
Or maybe Debian has little interest in ensuring that users of what has
to be one of the most popular platforms out there, can actually install
Debian on through a standard Debian installation ISO.
Regards,
/Pete
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967918
[2] https://www.raspberrypi.org/forums/viewtopic.php?f=50&t=282839
[3]
https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html
