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):
Steps to Reproduce:
1.Use multiple %post sections in ks.cfg file, some with --chroot.
2.Perform kickstart install
%post --nochroot scripts all fail because they do not run under the
install environment, instead they are chroot'ed to /mnt/sysimage
execution of %post --nochroot from within the install environment
see attached config and logs.
Created attachment 111088 [details]
kickstart files and logs from install time
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.
Created attachment 111304 [details]
problem reproduced under RHEL 4 AS
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.
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
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
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.
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.
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
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.
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?
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?
Closing as NEXTRELEASE. If you're curious as to how this is shaping up, check