Bug 639999 - Generated kickstart file lacks %end tags
Summary: Generated kickstart file lacks %end tags
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: WebUI
Version: 1.2
Hardware: All
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Justin Sherrill
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
: 645493 (view as bug list)
Depends On:
Blocks: space12
TreeView+ depends on / blocked
 
Reported: 2010-10-04 14:13 UTC by Sandro Mathys
Modified: 2010-11-23 13:26 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-11-23 13:26:15 UTC
Embargoed:


Attachments (Terms of Use)

Description Sandro Mathys 2010-10-04 14:13:33 UTC
Description of problem:
If you have a kickstart profile the file that is automatically generated from it is missing %end tags for each section (e.g. %packages, %pre, %post).

%end has long been optional but the current Fedora 14 Beta enforces usage of %end, i.e. if those tags are missing the anaconda will exit.

Therefore %end should be added ASAP, possibly including backports to older spacewalk releases that are still supported (if any).

More information on %end:
http://fedoraproject.org/wiki/Anaconda/Kickstart
...note that this wiki page still states that %end is optional, i.e. it's not up to date for F14 yet.


Version-Release number of selected component (if applicable):
According to jsherrill this has never been addressed, so it's applies to any spacewalk version including development until now.

How reproducible:
Always.

Steps to Reproduce (I):
1. Create a kickstart profile
2. Display the kickstart file
3. Note lack of %end

Steps to Reproduce (II):
1. Create a kickstart profile with a F14 (beta) distribution tree (you can use empty channels to save time)
2. Kickstart F14
3. Get an error message as soon as the kickstart file is parsed
  
Actual results:
%end is completely missing / F14 can't be kickstarted

Expected results:
F14 can be kickstarted as usual

Additional info:
It is unclear with which version of anaconda %end was first supported. Simply adding %end might be a problem for RHEL/CentOS 3/4 but I did not find any information on this matter. Maybe anaconda simply ignores %unknownTags...?

Comment 1 Justin Sherrill 2010-10-04 15:02:58 UTC
So plan is:

Test RHEL 3/4/5 with %end tags.  

a)  If it works, add it to everything
b) if it doesn't work we'll have to wrap them in if (!isRHEL5orGreater()) Yuck!

Comment 2 Sandro Mathys 2010-10-13 13:43:43 UTC
I quickly tested this with a minimal kickstart file and centos 3.9/4.8/5.5 in KVM and that's my results:

CentOS 3.9/4.8 will try to execute %end in %pre/%post (which results in a warning that no job control is active). One would see this in the log but not in the install screen. But with %end in %packages you get one of those dialog boxes telling you package %end could not be found.

CentOS 5.5 shows the same behaviour in %pre/%post but gets an traceback in %packages, i.e. %end in %packages seems to trigger a bug :)

Since CentOS 5 (based on Fedora Core 6) didn't support %end but Fedora supported it for several years already I started to wonder when it has actually been introduced. So I started to bug the folks in #anaconda about when %end was actually introduced. A real quick look at some source code was all they needed for the answer:
<clumens> introduced:  Date:   Fri Aug 24 15:41:44 2007 +0000
<clumens> required:  Date:   Thu Jun 10 13:35:05 2010 -0400
<clumens> that's F8 and F14, respectively

I really hope there's a way to implement that in spacewalk or we have a major problem :)

Comment 3 Sandro Mathys 2010-10-21 16:28:43 UTC
FYI: just confirmed with dlehman from #anaconda that RHEL6 will support but not require %end - NOT using %end is considered 'deprecated', though

So I think %end should always be added for any Fedora (I think <=7 can be safely ignored as <=11 is EOL and even 12 is going EOL in 2-3 months) and RHEL >=6, i.e. %end should always be added unless it's RHEL <=5

Comment 4 Jan Pazdziora (Red Hat) 2010-11-19 16:02:56 UTC
Mass-moving to space13.

Comment 5 Jan Pazdziora (Red Hat) 2010-11-20 17:05:55 UTC
Justin, I can see commit 3eeed6a9c7d247605bf010f81511675e091823fa (and 1699189bd61e8b9fa2b67d4d5de827ebd091f8db) which has this bugzilla number in commit message and which seems to address this issue. That would also make this fixed in Spacewalk 1.2. Does this sound correct?

Comment 6 Jan Pazdziora (Red Hat) 2010-11-20 17:07:27 UTC
*** Bug 645493 has been marked as a duplicate of this bug. ***

Comment 7 Justin Sherrill 2010-11-23 13:26:15 UTC
Hey Jan,

Yes, this bugzilla should be fixed by that commit.  I'm not sure why i didn't update the bugzilla though.  Sorry about that.

-Justin


Note You need to log in before you can comment on or make changes to this bug.