Bug 676940

Summary: %include checked before %pre runs, or not found
Product: [Fedora] Fedora Reporter: Orion Poplawski <orion>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: amcnabb, awilliam, cristian.ciupitu, jlaska, jonathan, vanmeeuwen+fedora
Target Milestone: ---Keywords: CommonBugs
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: RejectedNTH https://fedoraproject.org/wiki/Common_F15_bugs#cobbler_pre
Fixed In Version: anaconda-15.21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-20 20:59:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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 test@lists.fedoraproject.org 

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.

Comment 9 James Laska 2011-03-23 13:21:11 UTC
(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 :)