Re: isorecorder
Hello All,
I am the main developer of Rufus and since I am now being involved in
this discussion, let me reply to a few points:
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).
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).
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.
If you actively expect that everybody should use DD-mode only when
creating a bootable media from an ISOHybrid, you *WILL* diminish the
user experience.
I understand that manual selection of this mode has been removed in
favor of automatic detection of dd candidates:
https://github.com/pbatard/rufus/issues/1148#issuecomment-395562137
I'm afraid Thomas has been interpreting the item to which this pertains
wrong.
Rufus used to have a separate entries in one of it's UI dropdown for the
type of image the user wanted to select. One of these entries was for
"ISO Image", which would trigger a default filter of "*.iso" when
selecting an image, and another entry was for "DD image", which would
set a default filter of "*.img, *.disk, *.vhd, ...".
But considering that, behind the scenes Rufus was ultimately performing
its own detection of the properties of an image, and that there was no
real difference between these 2 options if you applied a filter of
"*.*", it of course made sense to consolidate the 2 dropdown elements
into a single "Disk or ISO Image".
However, this threw of people who were used to seeing a separate option
for "DD image" and led them to think that this option had been removed
altogether.
So I'm afraid that Thomas' interpretation is incorrect. Automatic
detection was always being enacted, and the only thing the DD or ISO
"mode" did was apply a different filter for the file selection dialog.
I don't use Rufus myself but it is my answer to users of MS-Windows when
they ask what to do with an ISO that is bootable from USB-stick.
As Lou pointed out from a previous e-mail I sent (and as the plea above
should make clear) I see the matter very differently, on account of the
feedback I receive from Windows users, as well as what I am seeing on
social media, with Windows users really being thrown off by not being
able to "see" the full content that has been copied to their USB.
For instance, I can literally point to reddit post after reddit post
where a Windows user is utterly confused after they created a media in
DD mode, by the fact that Windows only mounts the ESP and that there
only seems to be a couple files there. Most of these users end up
believing that their media was improperly created and do not try to boot
it at all.
This is why I made the decision to promote ISO/File copy over DD copy in
Rufus for ISO Hybrid.
I will however point out that, when doing so, Rufus produces the
following *explicit* warning (which appears every single time a user
creates media from an ISOHybrid):
-----------------------------------------------------------------------
ISOHybrid image detected
The image you have selected is an 'ISOHybrid' image. This means it can
be written either in ISO (file copy) mode or DD (disk image) mode.
Rufus recommends using ISO mode, so that you always have full access to
the drive after writing it.
However, if you encounter issues during boot, you can try writing this
image again in DD mode.
Please select the mode that you want to use to write this image:
o Write in ISO mode (Recommended)"
o Write in DD mode
-----------------------------------------------------------------------
In other words, Rufus prominently advises users to try recreating the
media in DD mode if they think they encountered an issue in DD mode.
As such, I can't see myself agreeing with proponents of "If you use
Rufus, only use DD" as we are literally doing everything we can to help
users, and I will maintain that most of the responsibility of ensuring
that ISO mode works is with the distro maintainers, since, once again,
all Rufus does (apart from changing the label in config files, *IF*
necessary) is perform a 1:1 copy of all the ISO content onto a FAT32 media.
Moreover, since this mode of operation is very convenient, on account
that it really doesn't even require the user to use a third party
application (including Rufus, but also including a dd imager) and is
cross platform, I can't help be feel dismayed at seeing the apparent
trend that some distro maintainers appear to have of disregarding simple
ISO extraction on FAT32 media for UEFI boot, on account that "users
should just use DD anyway".
From where I stand, doing so only leads to a worse overall experience
for users trying to install your distro.
So I hope we can all agree that there is a place for both DD and
ISO/file copy mode, and that the promotion of one should not relegate
the other to a feature that is no longer being properly tested and left
to wither (as we can see with the >1 month breakage of UEFI-FAT32
installation from Bullseye testing netinstall ISOs).
Regards,
/Pete
Reply to: