Bug 148770 - anaconda executes all KS %post sections in chroot
Summary: anaconda executes all KS %post sections in chroot
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda   
(Show other bugs)
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Chris Lumens
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-15 15:02 UTC by Chris Evich
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-28 18:54:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
kickstart files and logs from install time (11.38 KB, application/octet-stream)
2005-02-15 15:03 UTC, Chris Evich
no flags Details
problem reproduced under RHEL 4 AS (28.54 KB, application/x-bzip-compressed-tar)
2005-02-22 17:24 UTC, Chris Evich
no flags Details

Description Chris Evich 2005-02-15 15:02:23 UTC
Description of problem:
I'm using a boot.iso with a very small embedded ks.cfg file.  Mostly
it just points to my NFS server and %includes the remainder of its
self from /mnt/source files.  It works perfectly for everything,
except I found a problem with the %post sections. (I've not tried with
an all-inclusive ks.cfg file so I don't know if that is a factor.)  

Basically I'm trying to run 3 %post's.  The first and third use
"--nochroot" and the second does not.  However, the --nochroot %post
sections kept failing on me.  So I added some debugging statements to
them (print out their environment, ls /mnt, etc.).  Based on the log
file I captured it looks like they are all executing INSIDE a chroot.
 It doesn't seem to matter if the "--nochroot" flag is specified or not.

I am attaching slightly edited kickstart files and the logs from them.
 I've simply changed hostnames and ip addresses to x's in them.  The
real interesting bit is in the post_nochroot.log file.  Just after it
prints the output from "set" and "export" it does a "ls -la /mnt". 
This clearly shows an empty directory where it should be showing the
install environment's /mnt directory.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1.Use multiple %post sections in ks.cfg file, some with --chroot.
2.Perform kickstart install
Actual results:
%post --nochroot scripts all fail because they do not run under the
install environment, instead they are chroot'ed to /mnt/sysimage

Expected results:
execution of %post --nochroot from within the install environment

Additional info:
see attached config and logs.

Comment 1 Chris Evich 2005-02-15 15:03:28 UTC
Created attachment 111088 [details]
kickstart files and logs from install time

Comment 3 Chris Lumens 2005-02-21 19:18:44 UTC
Are you able to reproduce this on Rawhide or RHEL4?  My tests of an
all-inclusive kickstart config file indicates that each %post script is
executing in the environment it should be.

Comment 4 Chris Evich 2005-02-22 17:24:07 UTC
Created attachment 111304 [details]
problem reproduced under RHEL 4 AS

Comment 5 Chris Evich 2005-02-22 17:25:47 UTC
Reproduced this on IBM x345 using RHEL4 AS GOLD, Boxed set ISO's.  Attached are
all scripts and logs.   Look specifically at
/mnt/sysimage/mnt/sysimage/tmp/post_*chroot.log near the end.  There is where it
clearly shows the chroot'd /tmp and /mnt filesystems.

Comment 6 Chris Lumens 2005-02-23 20:49:36 UTC
I think I can now reproduce this.  Would it be possible for you to turn your
kickstart setup into the ks.cfg file that includes the kickstart file, and the
kickstart file that has the contents of your post scripts inside it?  That is,
please test a setup to where the contents of post_chroot and post_nochroot are
inside of kickstart instead of their own files and let me know what the results are.

I believe that including the %post scripts is the only case where we're seeing
chroot problems.

Comment 7 Chris Evich 2005-05-10 13:29:11 UTC
Unfortunately the box I was testing this on is being used now and I can't
kickstart it again.  I wouldn't be surprised if including the post scripts in
the main ks file would work.  However, the big advantage to having them outside
and %included in is that I can test/modify them on the fly.  The scripts I
included with this issue have substantial pieces cut out, the real ones are
quite large.

Comment 8 Chris Lumens 2005-09-23 15:42:14 UTC
Due to the way the kickstart parser works in anaconda for RHEL4, I don't believe
it's possible to easily fix this.  I have rewritten the ks parser for Rawhide
and will test this specific setup to see if it works, or if I can make it work.

Comment 9 Chris Evich 2005-09-23 16:41:48 UTC
Cool!  If we can get this working properly, it opens up some cool post-install
install setup magic.  E.G. One install tree, multiple configurations, and
multiple setup scripts which can be both common and specific to a system or group.

Comment 10 Patrick C. F. Ernzer 2005-09-23 17:05:26 UTC
And really really nice would be parsing /proc/cmdline for something along the
lines of "postinclude=banana,orange,lemon postignore=apple,lime" so that one
could influence which post section files get pulled in and which ones get
ignored directly in the bootloader

But I guess I'm dreaming of a perfect world

Comment 11 Chris Lumens 2005-09-30 21:48:35 UTC
Well, I've managed to make this work in Rawhide.  Getting this to happen in a
RHEL4 update may be asking a lot, but feel free to add it to the proposed list
if you think it is suitable.

Comment 12 Chris Lumens 2005-10-20 15:02:27 UTC
Chris - could you test this against Rawhide at some point in the future and
verify that it works for you?  I'm pretty sure this is too large to make it into
an update release (I have a couple other kickstart bugs in this same state) so
if you can do without it in RHEL4 but we can target FC5/RHEL5, can we mark this
one as closed?

Comment 13 Chris Evich 2005-10-20 15:45:55 UTC
Yea, it's probably safe to forget about a fix for now.  I personally don't see
many requests for this fix flying around.  Maybe instead of closing it could be
"converted" into a feature request?

Comment 14 Chris Lumens 2005-10-28 18:54:19 UTC
Closing as NEXTRELEASE.  If you're curious as to how this is shaping up, check
out Rawhide.

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