Use U disk to install the system cannot automatically locate the available repo problem

[yifengyou]

Using tools such as rufus 、ventoy 、UltraISO to make boot disk will stuck in the Installation Source stage, the verification fails, unable to proceed to the next step

This pr sets the default repo path. The ISO already has a mount point for the yum repository when starting the installation, so this path can be reused during the repository search phase.

Please take a look, thank you~

[VladimirSlavik]

/test

[VladimirSlavik]

/kickstart-test --testtype smoke

[VladimirSlavik]

The tests ended in errors, but it isn't clear that these mean anything:

• The 1 failed kickstart test out of 3 is the initial setup one, which does not run the changed code, I think.
• Unit tests timed out for some reason.

[poncovka]

I am afraid that this will break other use cases. Since a766101, we try to use inst.stage2 to find a valid installation source. From what I remember, rufus doesn't create a source that we consider to be valid. @jkonecny12, what do you think?

[jstodola]

If inst.stage2= is used, it can mean the user do not want the installation repository to be set at all.
I'm afraid that by this change would break other use cases, so I'm against this change, especially for RHEL-8.
Since rufus modifies the structure of the installation media, it should do it in a way that correspond to the performed changes. For example by using inst.repo= instead of inst.stage2=

[bitcoffeeiux]

If I want to make a usb flash drive to boot, how do I make it without using Rufus or some other tool?

[jkonecny12]

Hi, I understand that you want to enable the tool you are used to. The point is that this is not the correct way to do it as mentioned above. It could break other scenarios and even break your other installations.

The point here is that Rufus tool creates ISO images which are not really well written, for some for me unknown reason they are not using ISO9660 formatting, which is standard for DVD/CD images and mainly the official ISO image has this format included. I know this is not DVD but the images still should have this inheritance because they should be read only etc...

If I may have a suggestion, please look on the Rufus tool and try to file a ticket on them to create the image with the correct formatting as it is on the image. Or you tell them to just add inst.repo parameter, even thought, I don't think this is a correct way for the fix.

[jkonecny12]

If I want to make a usb flash drive to boot, how do I make it without using Rufus or some other tool?

Ideally you should use the recommended way: https://docs.fedoraproject.org/en-US/fedora/rawhide/install-guide/install/Preparing_for_Installation/#_fedora_media_writer

[jstodola]

If I want to make a usb flash drive to boot, how do I make it without using Rufus or some other tool?

FAQ for Rufus mentions "DD mode", so this method might produce a usable media even with Rufus.

[pbatard]

(Disclaimer: I am the main developer of Rufus)

Hi, I understand that you want to enable the tool you are used to.

Or not. The "ISO mode" of Rufus is really the standard way of creating bootable UEFI media which consists of:

• Formatting a USB drive to FAT32
• Extracting the whole content from the source ISO onto the FAT32 partition
• (Potentially, if the installer is based on label lookup to find the source media) renaming the FAT partition to a label the installer will recognize.

No separate utilities needed. Just leveraging the whole point of UEFI which is to work with bootloaders that sit at the file system level, so that one can do away with the need to use a sector by sector copy.

Debian, Ubuntu, Arch and other popular distros (along with their maintainers) appear to understand that this kind of method is useful for people who don't want to have to rely on dd-like utilities when working with an ISOHybrid.

And it also needs to be pointed out that ISOHybrids written in DD mode can be very confusing to Windows users, as they may only see the ESP and consider that the media was not written properly and not even attempt to boot it.

So, it's not really a matter of people wanting to "enable the tool (they) are used to", and I really wish Red Hat would look around at how other distros are making sure that a sometimes desirable alternative to create bootable media for UEFI boot, and that was working pre Red Hat 8.2 has been broken.

The point here is that Rufus tool creates ISO images which are not really well written

For one thing, Rufus does not "create ISO images". And second, in ISO mode, Rufus does perform what I explained above, which is to extract the content as is. This can actually be validated when using Rufus with distros like Ubuntu that perform a MD5 check of the content when booting the media, which validates that the files being used are the same as on the ISO.

So the "not really well written" is disputable.

Again, the only issue here is that Red Hat is no longer compliant with a mode of creating media that does not rely external utilities (or even dd), which further disputes the idea that the problem comes with a utility that may not write the media properly.

for some for me unknown reason they are not using ISO9660 formatting

The reason is well know. UEFI works at the file system level and ensures that, at the very least, FAT32 will be supported as a file system when looking up for a UEFI boot loader.

Therefore, utilities like Rufus (or standard media creation for UEFI boot) relies on having the content on FAT32 rather than ISO9660, which also has the advantage of convenience, since FAT32 does not need to be mastered to add new content and is better designed for boot media such as USB Flash Drives.

I know this is not DVD but the images still should have this inheritance because they should be read only etc...

Unbuntu and other distros do not see it that way, and (I think) use a much smarter way of ensuring that the media contains the expected content than simply enforcing read-only (which does not help with detecting corruption) by checking md5's.

If I may have a suggestion, please look on the Rufus tool and try to file a ticket on them to create the image with the correct formatting as it is on the image.

That's what we already do, but quite frankly, considering the above, and the fact that the UEFI method of creating boot media was working fine up to RH 8.2, I have use my ping pong paddle and express the strong idea that, contrary to what is being asserted here, the issue, really, is with Red Hat, and not external utilities.

If it wants to help users (and avoid derivatives from experiencing these issues, per pbatard/rufus#1777) Red Hat should really ensure that its users have the option to create installation media for UEFI in the way I described above (and which again does not need to rely on using external utilities), like other major distros do. Requiring utilities to enforce dd writing, or seeing ISOHybrid as equating dd write is not always the way to go, especially if you care about non Linux users wanting to install your OS for the first time...

[jkonecny12]

Hello @pbatard ,

We would like to thank you for providing more information on this issue and the specific details on why Rufus is creating installation sticks in this format.

We would like to provide some more insights on the problem. The installation boots correctly, however, we implemented a new way of installation source handling including detection of the default source which is the root cause.

Please note that the specific issue shouldn’t happen and definitely it is not something that occurs intentionally. Our current Fedora, CentOS and RHEL installation images do not officially support this way of booting and our recent changes related to the installation sources missed this case.

As it was previously mentioned in our posts, the easy workaround here is to use inst.repo= instead of inst.stage2= to tell Anaconda where it should look for the installation sources.

At the same time, we would like to thank you for your important feedback and assure you that this helped us understand the issue better. We have already worked with the team on identifying possible solutions and as this is a challenge to maintain backward compatibility (which is priority especially for RHEL), we will be currently finalizing our approach on the best solution.

[pbatard]

Hi @jkonecny12,

Thanks for the feedback.

I fully understand that this wasn't intentional, especially as versions of Red Hat prior to 8.2 (and derivatives based on these versions) were working as expected when creating media using Rufus or with the standalone method I described above.

And I will also admit that I probably should have tried to liaise with Red Hat on that issue earlier (especially now that I realise that the Red Hat installer has a public issue tracker), but was slightly put off by the behaviour of some CentOS folks, who, when I tried to explain that there were 2 components to the problem, one with Red Hat and one with Rufus, were adamant that the blame lied squarely with Rufus and refused to hear anything further.

As it was previously mentioned in our posts, the easy workaround here is to use inst.repo= instead of inst.stage2= to tell Anaconda where it should look for the installation sources.

Yes. And that's a workaround I am looking to apply in Rufus, instead of the current one where I use the following regexp (against the ISO label) to enforce DD mode in order to sidestep the issue:

        "^CentOS-8-[3-9].*",	// CentOS 8.3 or later
	"^CentOS-9-.*",		// CentOS 9.x
	"^OL-.*-BaseOS-.*",	// Oracle Linux
	"^RHEL-8.[2-9].*",	// Red Hat 8.2 or later
	"^RHEL-9.*",		// Red Hat 9.x

Detecting the use of inst.stage2= in the boot params, and changing it to inst.repo=, should indeed provide a better way than having to maintain the list above, so I am planning to do that in the next release of Rufus.

But, since you mention that you are looking into it, I'll be happy if the Red Hat installer also updates its process to ensure that file extraction can be used as a method to create bootable media, as was the case before.

For the record, I'll mention that, AFAIK and because of the requirement to either use of ISO labels that have to be compatible with FAT32 so that they don't have to force users to manually edit their the kernel boot parameters when performing a UEFI file copy install, Debian has moved away from relying on labels to identify the source installation media. Instead, their installer now seeks a specific file (.disk/info) on all relevant devices, to attempt to locate the installation source (For more on this, see the cdrom-detect\debian\cdrom-detect.postint script in cdrom-detect).

Ideally, I also think distros should try to move away from relying on media labels to identify the source installer, as it can help with a smoother installation for UEFI file copy mode. But then again, I do have a solution to automatically sort FAT32 label conversion in Rufus, so this is not a major dealbreaker.

[jkonecny12]

Sounds like an interesting solution. I will definitely take a look. Thanks for pointing us on that.
I must admit, I don't have too much knowledge of others distros installers. Definitely something I should improve... :)

[marcosfrm]

As it was previously mentioned in our posts, the easy workaround here is to use inst.repo= instead of inst.stage2= to tell Anaconda where it should look for the installation sources.

This workaround does not work with RHEL/CentOS 7 -- see pbatard/rufus#1777 (comment). Is it RHEL 8.2+ and Fedora 34+ only?

[jkonecny12]

This workaround shouldn't be required for RHEL/CentOS 7. Changes what caused this issue were introduced in RHEL 8 and later. The comment is correct :(.