[ Dropping CC to Lou as we've wandered, but re-adding Thomas for the
GPT question. ]
On Wed, Jan 13, 2021 at 08:16:39PM +, Pete Batard wrote:
>On 2021.01.13 18:49, Steve McIntyre wrote:
>> I've never seen a UAS device here yet, let alone tested with one. :-)
>
>They've existed for quite a few years.
>
>I think currently have about 4 of those in my arsenal, with the first one
>purchased more than 6 or 7 years ago.
ACK.
>> 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: 0025
>> > [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.
>
>Yeah, that Mushkin device is definitely something I've had for more than 5
>years, and that I don't expect to be sold any longer. And most regular flash
>drives would not be UAS.
Yes, that's what I've found.
>> 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. :-(
>
>OK. One thing you may want to check first, if you have any lying around, are
>USB <-> SATA or USB <-> NVMe adapters, because these frequently turn to be
>UAS.
>
>For instance, the following USB <-> SATA "enclosure", that I purchased more
>than 5 years ago, is UAS:
>https://archive.plugable.com/products/usb3-sata-uasp1/ (it even says so in
>the link).
>
>I don't think they are sold brand new any more, but you might be able to find
>one of those off e-bay.
>
>Or, for something more recent and perhaps more convenient to get, the
>following USB <-> NVMe enclosure is also UAS (at least for the "NVME -
>10Gbps" version, which is what I have):
>
>https://www.aliexpress.com/item/1005001742426847.html
Right. I've found and ordered a Startech USB3S2SAT3CB which looks
useful. I've got a couple of small spare SSDs that I can use that
with. I was hoping to find a source for reasonably-priced USB-UAS
flash drives but the only one I can see off-hand is the "Corsair
Voyager GTX", e.g. at
https://www.scan.co.uk/products/128gb-corsair-flash-voyager-gtx-usb-31-gen-1-type-a-pendrive-black-460mb-s-read-460mb-s-write-33k-40
>Obviously, these last two devices require an additional NVMe or SATA disk to
>be usable. But I'd say USB <-> NVMe adapters are likely to become more and
>more widespread especially as can solve the problems of using something a bit
>more reliable and faster (as well as much better with random I/O) than
>regular flash drives, even more so on platforms that have USB 3.x but no
>NVMe.
>
>Plus I can certainly see people wanting to use the "extract all the Debian
>installation files into an ESP" procedure on regular x86 UEFI PCs, using a
>USB SSD (especially now that USB speeds are starting to catch up with NVMe),
>in which case there's a good chance their installation media will be UAS...
Right. Now I know it's a problem, I can have a look.
>> 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. :-(
>
>Three words: cheapest platform possible.
>
>That's what the Pi Foundation are pursuing, and thus, by transitive property,
>Broadcom, since that's who the Foundation chose as their supplier. As a
>result you're being met with tons of limitations or quirks (such as a
>poor/buggy PCIe DMA implementation of the SoC, limited mask ROM space that's
>likely to result in major trade-offs, and, recently in order to save another
>few more cents on the platform, the complete removal of the xHCI controller
>EEPROM that existed in the initial Pi 4 models, which means that, if you
>happen to reset xHCI, you must now take care of loading its firmware data
>back in RAM).
>
>My understanding is that SoC mask ROM is designed to look only at the first
>
