Bug 154489 - %post kickstart section doesn't execute commands as expected
%post kickstart section doesn't execute commands as expected
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-12 02:45 EDT by Anchor Systems Managed Hosting
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-18 10:44:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anchor Systems Managed Hosting 2005-04-12 02:45:30 EDT
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:
Always

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 ]
then
        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
EOF
        mount /home
        mount /opt
        mount /var/lib/mysql
        mount /var/lib/pgsql
fi

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:

1.
(
# 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 11:28:23 EDT
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 18:45:38 EDT
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
section.

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 17:15:00 EDT
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
...
EOF
sh -x /root/myscript 2>&1 |tee /root/out

should do it
Comment 4 Anchor Systems Managed Hosting 2005-04-17 21:05:26 EDT
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:

%post
# 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)
    quit
  EOF
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)
    quit
  EOF
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)
    quit
  EOF
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)
    quit
  EOF
else
  echo "If this was a RAID install, GRUB may not be installed properly."
fi

-----------

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 10:44:18 EDT
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.