Re: isorecorder
On Sun, Jan 17, 2021 at 12:26:18AM +0000, Pete Batard wrote:
>On 2021.01.16 23:00, Steve McIntyre wrote:
>
>> 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
>> show up.
>
>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, very happy.
>
>> 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.
ACK. If you see any oddities like this in future, please let us
know. I'm happy to look into obvious failures like this, but I'm not
psychic! :-)
>> 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 [1],
>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.
ACK, that makes sense too. I'm surprised not to have heard complaints
about this already, I'll be honest. I'll take a look. My Thinkpad just
exposes SD as /dev/sdX (via USB), but I've got a Macchiatobin with
native SD on-board too to test with, showing up as mmcblk0.
>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 installation media?
>
>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...
So far, the design goal has been to limit searching to only look at
removable media types. That's a decision from way before my
involvement in the project. I can change it, but I'm a little bit
worried about unexpected assumptions that it might break
>> 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 uncommon.
Tell me about it :-)
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Reply to: