Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154489 - %post kickstart section doesn't execute commands as expected
Summary: %post kickstart section doesn't execute commands as expected
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-12 06:45 UTC by Anchor Systems Managed Hosting
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-18 14:44:18 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Anchor Systems Managed Hosting 2005-04-12 06:45:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20041013 Firefox/0.9.3 (Ubuntu)

Description of problem:
We are having some funny behaviour in the %post section of our kickstart file. We have some commands that set up bind mounts in the fstab and on the disk that are not running, and even attempts to introduce debugging commands have failed.

The exact same behaviour occurs under Fedora Core 3.

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

How reproducible:

Steps to Reproduce:
1. Create a directory /data on the installation file system (i.e. /mnt/sysimage/data) - in our case it is a separate partition and mount point.
2. Include the following commands in the %post kickstart section:
# Setup bind mounts.
if [ -d /data ]
        test -d /var/lib/mysql || mkdir -p /var/lib/mysql
        test -d /var/lib/pgsql || mkdir -p /var/lib/pgsql
        mkdir /data/home /data/opt /data/var.lib.mysql /data/var.lib.pgsql
        cat >> /etc/fstab <<EOF
/data/home          /home          none defaults,bind 0 0
/data/opt           /opt           none defaults,bind 0 0
/data/var.lib.mysql /var/lib/mysql none defaults,bind 0 0
/data/var.lib.pgsql /var/lib/pgsql none defaults,bind 0 0
        mount /home
        mount /opt
        mount /var/lib/mysql
        mount /var/lib/pgsql

3. Run the installer.

Actual Results:  None of the commands in the if statement in the above code are run, even though the /data directory in the chroot environment exists.

Expected Results:  The above lines should have been appended to the /etc/fstab file in the chroot environment, and the mount points specified mounted.

Additional info:

We have also introduced various 'debugging' commands into our %post section to figure out what was happening. The only one of them that produced any output was an echo command in the else section of the if statement. For example:

# the above code was entered here
) 2>&1 | tee /root/post.log

2. mount
3. ls -la /
4. ls -la /data

The above four examples produced no output. I realise this is a very strange bug report but it has been very hard to nail down exactly what is causing this behaviour.

Comment 1 Jeremy Katz 2005-04-12 15:28:23 UTC
Are you running with %post or %post --nochroot?  Are there any error messages on
tty3 after the %post has run?

Comment 2 Anchor Systems Managed Hosting 2005-04-12 22:45:38 UTC
We are running with %post. We have confirmed that it is running in a chroot
environment by replacing the contents of /etc/sysconfig/network (to set the
hostname of the machine). Also we are putting a log file in /root of the %post

There are no error messages on tty3. It simply says it is starting the %post
section, then that all %post scripts have been run.

Comment 3 Jeremy Katz 2005-04-14 21:15:00 UTC
That means that the shell didn't exit abnormally.  Can you try basically getting
the file into the chroot and then exec'ing it with sh -x outputting to a file?

Something like
cat << EOF > /root/myscript
sh -x /root/myscript 2>&1 |tee /root/out

should do it

Comment 4 Anchor Systems Managed Hosting 2005-04-18 01:05:26 UTC
That by itself actually worked. So I must assume there is a problem with the
contents of my %post section before I run the bind mounting stuff. However I
can't see any problems with it and it is pretty simple.

In order to get around a bug in GRUB that won't install to the MBR on RAID
installs, we set a kernel parameter and read from it in the %post section, then
install GRUB based on that parameter:

# Fix up Grub installation which is broken in EL4 and FC3
PART=`cat /proc/cmdline | tr ' ' '\n' | grep '^part=' | cut -d= -f2`

if [ "$PART" = "ide-hda-hdb-srv" ]; then
  grub --batch << EOF
    device (hd0) /dev/hda
    root (hd0,0)
    setup (hd0)
    device (hd1) /dev/hdb
    root (hd1,0)
    setup (hd1)
elif [ "$PART" = "ide-hda-hdc-srv" ]; then
  grub --batch << EOF
    device (hd0) /dev/hda
    root (hd0,0)
    setup (hd0)
    device (hd1) /dev/hdc
    root (hd1,0)
    setup (hd1)
elif [ "$PART" = "ide-hda-srv" ]; then
  echo "Single drive GRUB installs are fine."
elif [ "$PART" = "ide-freedom" ]; then
  echo "Single drive GRUB installs are fine."
elif [ "$PART" = "ide-ws" ]; then
  echo "Single drive GRUB installs are fine."
elif [ "$PART" = "scsi-raid1" ]; then
  grub --batch << EOF
    device (hd0) /dev/sda
    root (hd0,0)
    setup (hd0)
    device (hd1) /dev/sdb
    root (hd1,0)
    setup (hd1)
elif [ "$PART" = "scsi-raid5" ]; then
  grub --batch << EOF
    device (hd0) /dev/sda
    root (hd0,0)
    setup (hd0)
    device (hd1) /dev/sdb
    root (hd1,0)
    setup (hd1)
    device (hd2) /dev/sdc
    root (hd2,0)
    setup (hd2)
  echo "If this was a RAID install, GRUB may not be installed properly."


Right after this I have the bind mounting section and so far it hasn't worked
when these two sections have been both in the %post script. Any ideas?

Comment 5 Jeremy Katz 2005-04-18 14:44:18 UTC
You can try the same method as above.  There's nothing that looks obviously
wrong.  But if that's working, then the problem is an error somewhere in your
ks.cfg.  And debugging that is outside the context of what bugzilla is to be
used for.

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