Re: isorecorder
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. steve@einval.com
Who needs computer imagery when you've got Brian Blessed?
Reply to: