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): Kernel 2.6.18-1.2739.el5 How reproducible: 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 the rpms. 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 sleep 10 done 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". Actual results: Filesystem on /tmp/sda2 is not unmounted before %post section of ks.cfg executes. Expected results: Filesystem on /tmp/sda2 should not be mounted when %post section of ks.cfg executes. Additional info: 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 sync;sync;sync # lazy unmount. Unmount when filesystem is not busy anymore. umount -l /tmp/isodir/ # commit again sync;sync;sync 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 not.
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-11.1.2.16-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 11.1.2.17-1.
Ah, that would explain why beta2-candidate is failing. It has version 11.1.2-16.1. Would 11.1.2.17-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.