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. st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
