[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

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:

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).



Reply to: