On 2021.01.16 23:00, Steve McIntyre wrote:
On Thu, Jan 14, 2021 at 03:19:09PM +0000, Steve McIntyre wrote:
On Wed, Jan 13, 2021 at 08:16:39PM +0000, 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. :-)
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
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
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.
OK, and I've sussed it.
I splurged on that Voyager drive too, and
tested with it. The problem we have is deep down in the way that Linux
/ udev describe UAS-attached drives. In d-i we look for CD/DVD media
and then USB drives, and for the latter we look for "ID_BUS=usb" from
"udevadm info". On UAS media instead we get "ID_BUS=ata" so they don't
That makes a lot of sense.
Thanks for investing resources to figure this one out. I'm pretty sure
this will make a lot of people who want to install Debian (on Pi or on
other platforms), and that would otherwise have run into this issue,
This isn't a recent change, it's been like that way forever.
Yeah. I'm pretty sure I switched to testing with a UAS drive right at
the time someone reported they had an issue (that was also linked to
them using UAS media) which logically led me to think that there existed
a regression. But once we zeroed in on UAS being the culprit, I had a
feeling that it might be something that had existed for some time.
I've just added extra fallback code in d-i now to check for "usb" in
the "ID_PATH" string too, and I've just run an installation now using
that build. All looks good here. The changes will be in the next daily
build early tomorrow.
Since we're talking scanning limitation with regards to what d-i will
pick as install media, is there any chance you could looking into also
scanning SD/MMC media (most of which do not reside behind an USB
controller though some do)?
We have a very similar ESP/netint-based installation guide for the Pi 3
, this time using SD, because it makes a more sense to use SD on Pi 3
for varied reasons, and we have to require users to enter the "cdrom"
target manually with:
-t vfat -o rw /dev/mmcblk0p1
If SD removable media could be scanned in the same manner as USB media,
it would probably also improve the situation for people trying to
install Debian using SD, and just not Pi 3 users.
I also suspect that we are bound to find folks trying to use the
ESP/netinst installation method using M.2 NVMe drives, especially if
they don't happen to have a free USB drive lying around. In that case
maybe /dev/nvme### media should also be considered in the lookup for
All in all, it is likely that having d-i to only scan for USB and
optical devices might become limiting in the long run, especially if we
have means to identify, with relative certainty, whether a
media/partition was created for the goal of Debian installation.
But of course, you guys might have some constraints, that I am not aware
of, that also make you not want to overexpand the range of devices that
should qualify as installation media...
Hilariously, it's not just d-i that doesn't deal with the UAS edge
cases here. My test PC here would only recognise UAS media in BIOS
mode (i.e. CSM enabled), not in UEFI mode.
Interesting. Sadly, UEFI firmware bugs and limitations are far from
In my initial debugging
here I ended up having to use two USB sticks - an older one to boot
off and then remove, then the Voyager one to test detection code
with. Firmware update needed! :-)
Once again, great job! I really can't thank you enough for spending time
fixing this. :)