-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rocky Linux 8.4 does not work in ISO mode #1777
Comments
No surprise there. This is a consequence of a regression from Red Hat in Anaconda, that ultimately forced us to add exceptions to enforce DD mode for distros that are based on RH 8.2 or later. I tried to raise the issue in the CentOS forums, since they were affected, but they aggressively dismissed it as "This is not a Red Hat issue, this is a Rufus issue", without realizing that this needed to be reported upstream to avoid more Red Hat derivatives to be affected... as we are seeing now. To be honest, at this stage, I am starting to get REALLY fed up of all the distros who equate ISOHybrid with DD only, and appear to have no clue that, there are plenty of people out there who don't want to use a third party application like Rufus, Etcher or even dd to create bootable media for booting a UEFI system when (provided that there doesn't exist a file large than 4 GB on the ISO, which I'm not aware any prominent Linux distro to have) they should just be able to create a FAT32 partition and extract all the content there for it too boot. This, in essence, is ISO mode. And even if it may seem counter intuitive, there are clear advantages to using ISO mode for Windows users, as highlighted here. Debian understand this. Unfortunately, Red Hat and its derivative, as well as some other distros like Manjaro, appear to have taken the approach that they should minimize the amount of work required from their maintainers, so they see ISO mode (which should really be called "UEFI standard file copy boot") as something that they should not have to bother with, and will push back very strongly at the idea that anything but DD copy should be used for media creation even if, again, the end result is that users who wish to install their distros will be, at the very least, inconvenienced (due to having less methods they can use to create boot media) and at worst, as I could point to many, many reddit threads where that happens, under the impression that the media they created in DD mode must be faulty when they can only see a small ESP out of it in Windows, and therefore, not attempt to boot the distro at all! Now, if you can give me the ISO label scheme that you plan to use for your images, I can try to add another regexp to set it as Or, as you should do to prevent yet another instance of a RH derivative needing to figure out why the media creation mode recommended by Rufus does not work, you should liaise with Red Hat and try to make them understand that:
|
Heck, right at the time I was writing this post, there was another reddit user posting about their confusion of only seeing an ESP from a Manjaro ISOHybrid that was written in DD mode. So, yeah, this is a real issue, regardless of whether Red Hat and its derivatives want to consider it as something they need to address. |
From I replaced Docs: https://github.com/rhinstaller/anaconda/blob/master/docs/boot-options.rst#installation-source |
Thanks for the update. As you will see from my post in rhinstaller/anaconda#3529, I still see the issue as something that Red Hat should look into, if they do care about their users especially as it's a bit worrying that one of the most popular Linux distros out there seems to not be aware of one common means of creating a Linux installation media for UEFI systems... There has got to be a better way than force people to edit their config files when creating media at the file system level... |
The newly released Rufus 3.16 BETA, which can be downloaded here has the |
Rocky 8.4 is ok! But the change broke CentOS 7: ("ISO file" does not work) If I switch back to CentOS 7 log:
|
I kind of feared that this would be the case, and that's the precise reason why the fix would be better if it came from Red Hat, because now I have to figure out distros that don't work with At this stage, I'm not sure I'm going to bother for this release, as I have more pressing matters to deal with, and I can always refer RH derivative users to older Rufus versions. Realistically, because it is effectively a regression, making sure that |
I tested a bunch of ISOs and my conclusion is that we can simplify things applying As far as I know, these are the relevant clones:
Something like:
Once RHEL 8.x branch gets a fix, we can narrow down the regex replacing Then there is Fedora... its last working version is 32. Fedora 33, 34 and 35 (beta) require the workaround. The problem is its ISO label scheme:
(did not check other spins/architectures...) So maybe ignore Fedora altogether? |
Well, for Fedora this will do the job:
|
Thanks. I'm plenty busy with the Windows 11 related updates, but I'll see if I can squeeze something for the release. Can't promise anything though. |
|
Thanks a lot! This will keep CentOS 7 working. |
* Since CentOS Stream does not use the 'CentOS-8.*' labelling scheme. * This is a follow up to #1777. * Also fix Windows Kit location for signing scripts.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Rocky is a new RHEL 8 clone after the CentOS Stream drama (aka premature CentOS 8 EOL).
We are using it to replace CentOS 8 in our machines, but unfortunately Rocky also drinks the ISOHybrid kool-aid:
If I select "ISO file" it still says "Error setting up base repository".
It would be nice add it to the ISOHybrid kool-aid drinkers list (and probably AlmaLinux too). Anaconda should not be this dumb...
The text was updated successfully, but these errors were encountered: