Re: isorecorder
Hey Pete,
HNY etc. Thanks for joining the discussion! :-)
On Sun, Jan 10, 2021 at 08:19:15PM +0000, Pete Batard wrote:
>On 2021.01.10 18:56, Lou Poppler wrote:
>> On Sun, 2021-01-10 at 18:13 +0100, Thomas Schmitt wrote:
>> > Hi,
>> >
>> > Lou Poppler wrote:
>> > > If you want to recommend rufus, please do so ONLY with a prominent,
>> > > un-ignoreable warning explaining that the user MUST select rufus'
>> > > "DD mode" at the prompt immediately before writing the media.
>
>For people who seem to be under the impression that "(Rufus) will replace
>parts of the debian image with its own recipe of loaders and configurations",
>I have to vehemently dispute that it is doing any such thing.
>
>The goal of Rufus is to create a bootable USB with content that is as close
>as possible to the ISO content *AND* is bootable as USB media, period.
>
>As such, when booting in UEFI mode, the *only* element that Rufus may modify
>are the labels used in the GRUB/Syslinux config files (kernel option) for
>source media lookup, to accommodate FAT32 limitations on that matter (since
>FAT limits labels to 11 uppercase characters, and ISO volumes can and usually
>do use labels with much longer names).
Thanks for clarifying that.
>Apart from this, everything else is a binary identical copy of the ISO
>content, which you can easily validate if needed.
>
>Then, for BIOS mode, we of course need to install GRUB or Syslinux
>bootloaders, which can't come from the ISO but which we produce from vanilla
>official releases, and rely on the distro not to have deviated too much in
>terms of patches from vanilla GRUB/Syslinux. However, if such deviation
>occurs, you usually get an early boot error that is easy to diagnose, and we
>also have provision, through the bootloader download facility of Rufus, to
>produce GRUB/Syslinux bootloaders that include specific fixes, such as the
>ones required for BootHole, since GRUB has yet to produce a mainline release
>that includes those.
>
>So I have to be adamant that if the media doesn't boot, especially in UEFI
>mode, then it's not a matter of Rufus introducing "its own recipe of loaders
>and configuration" but rather a problem of distro maintainers not having
>properly tested UEFI/FAT32 boot mode by extracting the ISO content onto a
>FAT32 partition, and trying to boot said media. And I am pretty positive that
>you will find that the users who reported issues after creating their media
>through Rufus, will report the exact same issues if creating the media
>themselves without using a third party utility.
>
>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...
>So le me reiterate this plea:
>
>PLEASE, PLEASE, PLEASE, do not treat ISOHybrid as an excuse to ignore non DD
>mode of installation, because, when you look at it objectively, you should
>find that DD is *NOT* a panacea (for instance, DD mode is completely useless
>for installation of vanilla Bullseye on a Pi 4, whereas FAT32 extraction,
>*when* not broken, gives you the same experience as if you were installing
>Debian on a UEFI x86 PC) and users do and will rely on a non DD mode of
>creating their install media.
Hmmm. What exactly is the problem with the Pi 4, out of curiosity?
...
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
Reply to: