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/sdb1Which 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