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

Re: [Fwd: Re: isorecorder]

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.



[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

Reply to: