Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
With newer anaconda versions (eg. Fedora 11), one needs to manually copy the /images directory aside with the ISO. In previous versions (up to RHEL5.3), it was sufficient to have kernel and initrd served via PXE, and providing "method=nfs:host:/path_to_iso".
Version-Release number of selected component (if applicable):
Since Fedora 10
Additional info:
We have an automated process in place that extracts kernel and initrd from ISOs on NFS and provides it to a PXE/TFTP server, which enables us to deploy new releases to test really quickly and comfortably: We simply register new OS installation media in a web application (see URL) which shouldn't get write access on the file server (to make the "images" directory available).
This is not a bug - it is intentional behavior. The loader no longer looks inside ISO images for the install.img. The reason for this is that we want to not tie an install.img to an exact media set. This is one step in that direction.
Note that you don't actually have to put it in the images/ directory on your server. You can put it anywhere you want and specify the location via stage2=. This is going to be most useful in combination with a web or ftp server.
(reopening bug...)
You may be right that it's not a bug, but at least in my opinion it's a regression. It did worked all the time before and now it doesn't. And it makes creating compatible setups for various RH distributions more complex.
As a trivial solution to this issue, wouldn't it be possible that you change the loader to look inside the iso image IFF you don't find the install.img beside the iso image (and stage2 isn't set)? That way you could keep backwards compatibility and still continue with the direction you want the installer to go...?
That's not really all that trivial. The amount of code required to do that searching, mounting, checking, unmounting, etc. was not exactly minor. And leaving that in doesn't really move us along since as long as the old way is preserved, people are going to continue to rely upon and use something that we do not want to promote. It's also going to involve a higher maintainance cost given that there'll be yet another path for finding the install.img. There's already entirely too many of those to thoroughly test as it is.