Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel.cd > #6557

Re: [Fwd: Re: isorecorder]

Show all headers | View raw

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

Back to linux.debian.devel.cd | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[Fwd: Re: isorecorder] Lou Poppler <LouPoppler@cableone.net> - 2021-01-11 02:40 +0100
  Re: [Fwd: Re: isorecorder] Pete Batard <pete@akeo.ie> - 2021-01-11 03:30 +0100
    Re: [Fwd: Re: isorecorder] Lou Poppler <LouPoppler@cableone.net> - 2021-01-11 04:50 +0100
      Re: isorecorder "Thomas Schmitt" <scdbackup@gmx.net> - 2021-01-11 09:00 +0100
        Re: isorecorder Pete Batard <pete@akeo.ie> - 2021-01-11 13:00 +0100
          Re: isorecorder "Thomas Schmitt" <scdbackup@gmx.net> - 2021-01-11 14:20 +0100
      Re: [Fwd: Re: isorecorder] Pete Batard <pete@akeo.ie> - 2021-01-11 13:00 +0100

csiph-web