Description of problem: Currently there's no easy way to do an 'nfsiso' install in Beaker. The workaround is to create a custom kickstart without an installation source specified, and then specify the necessary options in Beaker-> Provision-> Kernel Options: repo=nfsiso:my.nfs.server:/RHEL/6.3/Server/x86_64/iso/ stage2=nfs:my.nfs.server:/RHEL/6.3/Server/x86_64/os/images/install.img ks=http://some.other.server/rhel6.3_x86-64.cfg When those options are used, the install completes, using the iso image as the install source. Additional information: It's possible that the custom kickstart is not needed, since some kernel options passed at boot time override options in the kickstart file. However, it's unclear if 'repo=' is one of those options that take precedence.
I tested another installation, placing the nfsiso line *in* the kickstart file instead of specifying it on the command-line. This wasn't successful. Anaconda gave an error, since it was looking for /RHEL/6.3/Server/x86_64/iso/images/install.img, instead of using the stage2 image that was passed on the command-line. Boot Options: stage2=nfs:my.nfs.server:/RHEL/6.3/Server/x86_64/os/images/install.img ks=http://some.other.server/rhel6.3_x86-64.cfg Kickstart file: nfs --server my.nfs.server --dir /RHEL/6.3/Server/x86_64/iso/ According to the docs, the stage2= parameter usually has precedence. If that were the case this time, the install would've completed successfully. Unfortunately, this seems to be one of the exceptions to the usual behavior. http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-parmfiles-Miscellaneous_parameters.html
The repo= parameter isn't needed, Beaker always passes the installation tree location inside the kickstart with the url or nfs command instead. Beaker is actually almost all the way there with supporting NFS ISO installs, there are just a few bits missing: * For RHEL5 (and I think RHEL4 and RHEL3) it is enough to put this in the kickstart: nfs --server hostname --dir /path/to/dir/containing/iso/ and Anaconda will find the .iso and mount it and grab all its images from there. You can get this working currently in Beaker, by adding a URL to the distro tree with nfs+iso:// as the scheme, and then pass 'method=nfs+iso' in ksmeta for your job. All we're missing here is that beaker-import does not add those nfs+iso:// URLs, so you have to set that manually in the Lab Controllers tab on the Distro Tree page. * RHEL6 Anaconda no longer supports grabbing the images out of the mounted ISO automatically (bug 584472). It expects to find images/install.img in the same directory beside the ISO. Unfortunately that's not how our trees are usually laid out. If we could get rel-eng to add a symlink images -> ../os/images inside each iso directory, that would solve this problem. Then Anaconda could automatically fetch the install.img and it would work the same as RHEL5 and earlier. Otherwise Beaker will need to supply the stage2= parameter with the install.img location. We would have to expand beaker-import to record this extra image location (on top of the pxeboot images we currently track). I tried passing stage2= manually but I get the same behaviour as Stephanie noted in comment 2: Anaconda insists that I didn't pass stage2= (and then fails) even though it's there in the kernel args. Not sure if this is an Anaconda bug or what. * RHEL7 (at least as of RHEL-7.0-20120711.2) Anaconda has added back the necessary smarts to grab everything it needs from the mounted ISO, so as per RHEL5 there is nothing else Beaker needs to do once it knows the nfs+iso:// URL. * I haven't tried Fedora 16 or 17 yet. We don't mirror Fedora ISOs in BNE so I have to fetch them from outside which will take some time. I'm expecting Anaconda (at least in F17) behaves the same as RHEL7, in which case nothing special is needed.
Do you think this feature will be present in the next Beaker release then? I can open a ticket with rel-eng and get those symlinks in place.
(In reply to comment #3) > Do you think this feature will be present in the next Beaker release then? I > can open a ticket with rel-eng and get those symlinks in place. Bugzilla already opened with rel-eng, see Depends above. I'm hopeful that I can get the import script updated to import nfs+iso for the next release.
It looks like we're still waiting on 846799.
Pushing this to future_maint until our blocker is not a blocker
The proposed change to RHEL6 trees was rejected. This needs to be re-estimated based on passing the stage2 parameter to support RHEL6.
(In reply to Dan Callaghan from comment #2) > All we're missing here is that beaker-import does not add those nfs+iso:// > URLs, so you have to set that manually in the Lab Controllers tab on the > Distro Tree page. I have cloned bug 1013413 for this.
For the RHEL6 stage2= problem, we will need to add a new field or image type in distro trees and make beaker-import record the stage2 location there, and then the provisioning code can pull it out of there and add it to kernel options.
It is possible to work around this by passing a stage2= kernel option in the recipe explicitly, as in: <recipe kernel_options="stage2=...">
Closing the issue due to no longer being relevant. If this still affects your workflow, feel free to reopen.