On 2021.01.11 03:42, Lou Poppler wrote:
On Mon, 2021-01-11 at 02:21 +0000, Pete Batard wrote:
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.
The media we are discussing, debian-testing-amd64-netinst.iso, as copied
to my USB stick and booted in BIOS mode on the Toshiba laptop, also boots
just fine on this dell amd64 box in UEFI mode.
I will stipulate that there may be other architectures or devices which do not
work the same as amd64 desktops/laptops.
Please bear in mind that my testing was for amd64 too.
While I mentioned Raspberry Pi, the UAS breakage I am seeing is not Pi
specific and amd64 is broken too.
However, in all the varieties of
testing I have done on amd64 desktops/laptops, the direct byte-for-byte copying
of the installation image onto the base of a USB stick works properly in both
BIOS booting and UEFI booting. Perhaps more complicated schemes are needed
for other situations, I agree that is possible. I am only trying to explain
why I always suggest to amd64 users, on the general #debian IRC channel, that
they should directly copy the downloaded image to their USB stick with dd or cp
(as you saw in my example previous) or with rufus's DD mode. In this standard
situation, any other method of writing the USB stick causes hard to debug
problems.
I'm not disputing that having to support both of sector by sector copy
and file copy for bootable media creation creates more issues that just
supporting one of those. Almost every distro I know of has to take some
extra steps to support both.
However, I will also point out the reality that working at the file
level is usually more convenient for users than working at the sector
level, especially on non Linux platform.
The UEFI committee actually recognized this, and decided to move the
bootloading handling process at the file system level rather than at the
sector level, which *is* a great move for users trying to create UEFI
boot media (because they should then just be able to use file copy to
end up with something that boots).
However, my impression is that, through what appears to be over reliance
on ISOHybrid, some Linux maintainers appear to want to move in a
complete opposite direction, and insist that boot/installation media
should *only* be created through sector copy on account that it makes
their life more convenient, even if it ends up inconveniencing a non
insignificant section of their (potential) user base.
As an aside, that's not to say that other OSes are not also going in the
opposite direction that was introduced with UEFI, as I could point out
to Microsoft who decided to remove the convenience of being able to
access UEFI bootloaders at the file level, by preventing Windows from
being able to access ESPs altogether...
Thus, as Thomas points out, I am just trying to make sure that there
exists some balance here between "Thou shalt only use sector copy when
creating USB media from an ISOHybrid" and "Let's have Linux maintainers
support whatever crazy scheme people come up with from being able to
work with UEFI at the file system level".
I hope this position makes sense, and that we can work together to find
a common ground that will actually benefit most users (including, but
not being limited only to Raspberry Pi ones), especially as my
understanding is that Debian maintainers have strived to support FAT32
file copy install for UEFI, and that the few corner cases we find here
and there where it appears to fail shouldn't be that difficult to fix
once properly looked into (and I am planning to help with that effort).
Regards,
/Pete
