|Summary:||%include checked before %pre runs, or not found|
|Product:||[Fedora] Fedora||Reporter:||Orion Poplawski <orion>|
|Component:||anaconda||Assignee:||Chris Lumens <clumens>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||amcnabb, awilliam, cristian.ciupitu, jlaska, jonathan, vanmeeuwen+fedora|
|Fixed In Version:||anaconda-15.21||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-03-20 20:59:20 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Orion Poplawski 2011-02-11 23:01:48 UTC
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
Comment 1 Chris Lumens 2011-02-14 14:40:28 UTC
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.
Comment 2 James Laska 2011-02-14 19:13:32 UTC
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.
Comment 3 Chris Lumens 2011-02-14 20:12:54 UTC
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.
Comment 4 James Laska 2011-02-18 19:00:55 UTC
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
Comment 5 Adam Williamson 2011-02-25 18:34:14 UTC
remove f15alpha-accepted block, then.
Comment 6 Andrew McNabb 2011-03-22 19:19:42 UTC
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.
Comment 7 James Laska 2011-03-22 20:36:34 UTC
(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 email@example.com http://lists.fedoraproject.org/pipermail/test/2011-March/098066.html
Comment 8 Andrew McNabb 2011-03-22 21:02:39 UTC
I extracted vmlinuz and initrd.img from the boot.iso you described, and the problem seems to be fixed.