Description of problem: It appears that in F15 anaconda looks for %includes before %pre is run. cobbler uses a setup where a file is generate in /tmp during %pre and %included in the main anaconda section. Something like: install ... %include /tmp/pre_install_network_config %pre echo network --proto=dhcp > /tmp/pre_install_network_config. Now anaconda complains that /tmp/pre_install_network_config does not exist. Or perhaps it is just not finding it? Version-Release number of selected component (if applicable): anaconda 15.19
The problem lies in loader/kickstart.c: Py_INCREF(Py_True); PyDict_SetItemString(kwargs, "followIncludes", Py_True); Py_INCREF(Py_True); PyDict_SetItemString(kwargs, "errorsAreFatal", Py_True); Py_INCREF(Py_True); PyDict_SetItemString(kwargs, "missingIncludeIsFatal", Py_True); I can easily fix this by setting missingIncludeIsFatal=False. However, then we have the behavior that %includes are followed in loader very early on, then %pre scripts are run, and then all %includes are followed again, including the ones that were missing early on. I'm not sure if that behavior makes any sense or is just confusing. I could always not follow %includes in loader, but that reverts the entire point of this pykickstart integration. I want to be able to specify repo, reboot, etc. in a %include.
Spoke with clumens on this issue. I don't believe we have Alpha release criteria that would be impacted by this issue, but it is related to a recent anaconda improvement, and I think fits nicely into the definition of NICE-TO-HAVE (http://fedoraproject.org/wiki/QA:SOP_nth_bug_process). I'm proposing for F15Alpha-accepted (NICE-TO-HAVE), I think this would be safe to take for F15Alpha if a fix is available in time.
This will be fixed in the next build of anaconda for F15 alpha, which I believe will be 15.20.1. This is not testable via an updates image.
Discussed during the 2011-02-18 F15Alpha blocker review meeting #agreed 676940 - RejectedNTH, CommonBugs, will resolve post-alpha This issue will affect Cobbler automated installs
remove f15alpha-accepted block, then.
I think I may have run into this in Fedora 15 Alpha. If I want to try a Fedora 15 prerelease with the fix, will I have to wait for the beta? Thanks.
(In reply to comment #6) > I think I may have run into this in Fedora 15 Alpha. If I want to try a Fedora > 15 prerelease with the fix, will I have to wait for the beta? Thanks. Until F-15 nightly is updated with a newer anaconda, I built a boot.iso for use with testing a newer installer and posted details test test.org http://lists.fedoraproject.org/pipermail/test/2011-March/098066.html
I extracted vmlinuz and initrd.img from the boot.iso you described, and the problem seems to be fixed.
(In reply to comment #8) > I extracted vmlinuz and initrd.img from the boot.iso you described, and the > problem seems to be fixed. Thank you very much for testing :)