Bug 154489
| Summary: | %post kickstart section doesn't execute commands as expected | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Anchor Systems Managed Hosting <managed> |
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
| Status: | CLOSED NOTABUG | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-04-18 14:44:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Are you running with %post or %post --nochroot? Are there any error messages on tty3 after the %post has run? 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. 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 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?
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. |
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.