On Tue, Jan 12, 2021 at 12:53:21PM +0000, Pete Batard wrote: >On 2021.01.12 11:56, Steve McIntyre wrote: >> On Sun, Jan 10, 2021 at 08:19:15PM +0000, Pete Batard wrote:
... >> > Which brings me nicely to the point that the current Debian Bullseye test >> > images have broken said mode of operation (UEFI install from ISO content >> > extracted on FAT32) early in December, which is causing problems for people >> > trying to install Debian on Pi 4 for instance ([1] but my testing shows >> > that >> > this applies to more than arm64. And yes, I've been meaning to file a bug >> > for >> > this, but I haven't had a chance to do that yet). >> >> Argh. Thanks for raising this now, at least. I certainly haven't >> consciously made any changes to debian-cd that would cause this, so >> I'm a little surprised to hear about it. I'll take a look in the d-i >> code... > >Further testing (which I also mentioned in this thread) seems to indicate >that this only seems to apply for UAS media, so it's possible that it wasn't >a recent change, but that install media detection has not been compatible >with UAS devices for some time, which we only started to pick it up on >account that some of us have been testing Pi 4 Debian installation with UAS. Ahhh. That sounds like a very relevant thing, yes! I've never seen a UAS device here yet, let alone tested with one. :-) So it's not quite such a surprise that there might be problems there. >I'm still planning to look more closely into this when I get a chance, and >create a new bug (unless someone beats me to it), but if you have a UAS >device lying around, you should be able to replicate the issue with the >current Bullseye installation ISOs, including amd64 ones, as I confirmed that >the problem was (still) present in the latest netinst testing amd64 ISOs. > >FYI, the USB subsystem should tell you if a device is UAS with something like >this (from dmesg): > >[549114.637578] usb 8-1: new SuperSpeed Gen 1 USB device number 19 using >xhci-hcd >[549114.658815] usb 8-1: New USB device found, idVendor=174c, idProduct=55aa, >bcdDevice= 1.00 >[549114.658837] usb 8-1: New USB device strings: Mfr=2, Product=3, >SerialNumber=1 >[549114.658852] usb 8-1: Product: Ventura Ultra >[549114.658867] usb 8-1: Manufacturer: Mushkin >[549114.658881] usb 8-1: SerialNumber: 000000000025 >[549114.666050] scsi host0: uas >[549114.668168] scsi 0:0:0:0: Direct-Access Mushkin Ventura Ultra 0 >PQ: 0 ANSI: 6 ACK. I'm just looking for one to buy right now so I can test with it. I can't see anybody selling the Mushkin drive you show here, which is not helpful. Silly question - do you have any suggestions for a make/model to look for at all please? Google searches are basucally useless here for finding that level of detail on USB flash drives. :-( ... >> Hmmm. What exactly is the problem with the Pi 4, out of curiosity? > >The problem with the Pi 4 (as with all Pi's) is that it needs to load a set >of binary files, from SD or USB media, before it can boot anything, and we >also need to load the UEFI firmware from SD or USB. > >Now the nice thing, that was introduced a few months ago on the Pi 4 is that >you can load all these files from an ESP, with the caveat that the ESP has to >be at the beginning of your media (which means for instance that even if >adding files onto it wasn't an issue, the partition layout used by the >current ISOHybrid when copied in DD mode would still make that media >unbootable on a Pi 4). Sigh, OK. Firmware that doesn't deal flexibly with partitioning, i.e. by reading/parsing the partition table properly. I thought we'd be past that by now. :-( Is the firmware assuming a specific offset for the beginning of the ESP? Or will it deal with GPT, or is this brokenly expecting just a DOS partition table? >This logically leads to the idea that, if you are okay with sacrificing a bit >of space for the ESP, you can place all of these Raspberry Pi specific boot >files on it, along with the Debian installation content extracted from a >netinst or mini ISO (we advise netinst as it makes it faster to get to a >minimal serviceable install than mini for people with slow connection, and >because we don't see the extra space needed as that big of an issue) and once >you have that, you can boot and go through a full default installation of >Debian and end up with a fully working system. ACK, OK. Given the platform limitation you've just described, that makes sense. >And what makes it even better is that you don't even need to provision two >medias for this (install media + target), as the same media can transparently >act as both the installer and target. > >Considering that the Pi has no "internal" disk or flash to install a distro >to, and that one must use either an SD card or USB drive, it does make a lot >of sense in my opinion not to require users to juggle with multiple media, >especially as, and this is one of the main pain points we are trying to avoid >through this method, using two media would force users to go through the >shell during the install process to ensure that they copy all the Pi boot >files and UEFI firmware from the install media to the target before they >reboot, as, again, a Pi will not boot any media where these extra files >aren't present. > >But by reusing the ESP, where these files have already been copied, no extra >step is necessary. > >Furthermore, if you simply go with the defaults during Debian installation, >the disk partitioner will recognize the ESP as reusable and set it as the ESP >to use for the new system, and therefore when GRUB installs for the final >system, it simply replaces the one that was used for booting the installer, >which ensures that, once the user reboot, they get into their newly installed >system. Right. <more useful stuff elided - thanks!> -- Steve McIntyre, Cambridge, UK. st...@einval.com Who needs computer imagery when you've got Brian Blessed?
