Red Hat Bugzilla – Bug 214677
On RHEL5 install using hard drive, filesystem with isos not unmounted before %post in ks.cfg executes
Last modified: 2009-06-19 05:50:58 EDT
Description of problem:
During install of RHEL5 x86_64 from disk, the ext2 filesystem where the isos
are copied to is not unmounted before the %post section of ks.cfg is executed.
Version-Release number of selected component (if applicable):
Perform RHEL5 install from disk, where RHEL5 isos are copied to an ext2
filesystem on a disk. In this case, the isos are copied to /dev/sda2.
Steps to Reproduce:
1. Start RHEL5 x86_64 install process, install from hard drive. In my case,
the isos are on /dev/sda2.
2. Continue through install process and stop right before you start installing
3. Change to one of the virtual consoles (Alt-F2) and on the command shell,
type "df -k" to verify that /tmp/sda2 is mounted read-only.
4. Open the kickstart file (/tmp/ks.cfg) that is created and add code in the %
post section to pause the installation process. A nice infinite loop will do:
while [ -e /tmp/pause]; do
5. Switch back to the main console and start the rpm installation process. Go
back to the other virtual console and create /tmp/pause:
$ touch /mnt/sysimage/tmp/pause
6. Wait for the rpm install to finish and let it go into %post. Once there,
type "df -k".
Filesystem on /tmp/sda2 is not unmounted before %post section of ks.cfg
Filesystem on /tmp/sda2 should not be mounted when %post section of ks.cfg
The anaconda process that performs the install is:
/usr/bin/python /usr/bin/anaconda -m hd://sda2.ext2// --graphical --selinux --
kickstart /tmp/ks.cfg --lang en_US --keymap us
I did not test x86, but I'm assuming the problem is there too.
The reason why this is a problem for us is because we reclaim the partition
where the isos are located. In order to do that, the partition must not be
mounted. We can work around this issue by adding some umount commands to our
kickstart file, but in RHEL4 we do not run into this problem.
Another Dell group has reported same problem, they have a workaround, which
has still not worked for me. This is a sev 1 for us because this potentially
breaks the RHEL 5 re-install process for customers. RHEL 4 does not have this
behavior, no workaround is needed there.
The workaround code for the other group is:
# makes /tmp/sda2 rw (originally mounted ro)
mount -w -o remount /tmp/isodir/
# commit to disk
# lazy unmount. Unmount when filesystem is not busy anymore.
umount -l /tmp/isodir/
# commit again
Our LVM commands (pvcreate, vgextend, lvcreate) in %post to add /dev/sda2 to
the LVM pool fail.
Root cause of problem: /tmp/sda2 should not be mounted when %post section in
ks.cfg executes. This is the case in RHEL4, but for some reason in RHEL5 it's
Committed a fix to the rhel5 branch. This will be in the next build of anaconda.
beta2-candidate of RHEL5 made available to RH has anaconda-220.127.116.11-1. Do we
know if the fix went into this version of anaconda ?
Chris- What version of Anaconda can we expect to see the fix in ?
Beta2-Candidate handed to us a couple of days ago is still broken.
It will be in 18.104.22.168-1.
Ah, that would explain why beta2-candidate is failing. It has version
11.1.2-16.1. Would 22.214.171.124-1 be in the official Beta2 build ?
Setting Beta blocker and ACK flage for 5.0.
Setting Beta blocker and ACK flags for 5.0.
Fix verified using RHEL 5 Release Candidate Snapshot 3 (kernel-2.6.18-
1.2839.el5) x86. Have not verified x86_64 because of bug #218123, but fix
should be arch agnostic.
Changing status to VERIFIED based on comment #10 from Jose. RH- Please close.
This change affects installations from CDROM media. Now it is nearly impossible
to access files from the installation media with %post commands. Modified CD
images that previously only required a few added files, a mkisofs and a cdrecord
now need a custom built anaconda as well to undo this.