Hide Forgot
Created attachment 527544 [details] kickstart Description of problem: Hello, we have a problem with Red Hat Satellite that occurs when doing a re-provisioning in a system with RHEL 5.5. The Anaconda installer freeze the system when mounting the file systems to begin copying the packages listed on Kickstart. This only occurs when it has been installed previously a system with LVM in the same disks. Apparently in the disks where it is installing keeps some of LVM metadata, that makes Anaconda to fail. I made several tests, which concluded that: * The problem does not occur in the first installation, when the disks where you install the system have not been used before. * The problem occurs only when reinstalling RHEL 5.5 with anaconda-11.1.2.209, I have not managed to use another version of anaconda. * The problem occurs only when the disk that will reinstall the system had been installed previously using LVM * The problem occurs on physical machines and virtual machines. * The problem was reproduced using another satellite server * The issue causes the system to freeze, not allowing any action. It only remains to reboot. * I added the parameter in the kickstart: "clearpart -all -drives=sda,sdb" * The problem occurs even filling the disks with zeros using a script in %pre (dd if = / dev / zero of = / dev / sda bs = 1M) * The installation log redirected to a remote machine with debug level does not show useful information: rhel5.5 ERROR running vgscan failed: 5 rhel5.5 ERROR running vgchange failed: 5 rhel5.5 ERROR running vgmknodes failed: 5 rhel5.5 INFO trying to mount OperatingSystem/root on / rhel5.5 INFO set SELinux context for mountpoint / to system_u:object_r:root_t:s0 I attached kickstart and log files. Thanks in advance. Version-Release number of selected component (if applicable): - satellite 5.4.1 - anaconda 11.1.2.209 How reproducible: Using satellite 5.4.1 and reinstalling more than twice a RHEL 5.5 machine using LVM on your disks. Actual results: The installation fails, the system freezes. Expected results: A successful installation. Additional info:
Created attachment 527545 [details] Remote installation log
Looks to be an anaconda problem. Changing component.
What happens if you remove the extra "clearpart --all" in your kickstart file and change the remaining one to "clearpart --all --initlabel"?
(In reply to comment #2) > Looks to be an anaconda problem. Changing component. This problem not occurs when we install from DVD with the same kickstart. Obviously, cleaning added satellite configuration.
(In reply to comment #3) > What happens if you remove the extra "clearpart --all" in your kickstart file > and change the remaining one to "clearpart --all --initlabel"? Occurs the same problem. Now I'm testing again adding %pre script with dd command cleaning all discs. Still I think the LVM metadata is the problem.
Hi all, the results of the tests are as follows: 1.- Cleaning discs in rescue mode dd before installation, it works without problems. 2.- Commenting out the line of VG activation in the section "pre%" of kickstart, it works without problems. See "lvm vgchange -ay $vg" --------------------------------------------------------------- # Try LVM if that didn't work if [ "$rhn_keys_found" = "no" ]; then lvm lvmdiskscan vgs=$(lvm vgs | tail -n +2 | awk '{ print $1 }') for vg in $vgs; do # Activate any VG we found # COMENTADO POR FAAG # lvm vgchange -ay $vg done lvs=$(lvm lvs | tail -n +2 | awk '{ print "/dev/" $2 "/" $1 }') for lv in $lvs; do tmpdir=$(mktemp -d findkeys.XXXXXX) mkdir -p /tmp/${tmpdir} mount $lv /tmp/${tmpdir} || continue # Skip to next volume if this fails # Let's see if the keys are in there if [ -f /tmp/${tmpdir}$SYSTEM_ID ]; then cp -a /tmp/${tmpdir}$SYSTEM_ID /tmp/rhn/ rhn_keys_found="yes" umount /tmp/${tmpdir} break # We're done! fi umount /tmp/${tmpdir} rm -r /tmp/${tmpdir} done # And clean up.. for vg in $vgs; do lvm vgchange -an $vg done fi --------------------------------------------------------------- I confirm that this problem only happens installing from satellite for RHEL 5.5, when it has been previously installed a system with LVM on the same machine. I appreciate your help.
I comment that I found it a bit cleaner to solve this issue, I added a %pre script with the following: --------------------------------------------- dd if=/dev/zero of=/dev/sda bs=1M count=512 dd if=/dev/zero of=/dev/sdb bs=1M count=512 rm -Rf /etc/lvm/cache/.cache lvm pvscan lvm vgscan lvm lvscan --------------------------------------------- This cleans the metadata stored on the disks and the cache of LVM. With which Anaconda installs without problems. I stay aware of your comments, thanks.
Felipe, I'm going to go ahead and close this bug out since there's been no interaction on this in a while. In talking with the engineering team ... we don't see any remaining work that needs done here. Seems you solved the immediate problem per comment #7. If there are additional problems we need to solve in this BZ, please feel free to reopen the customer case and work with your support representative to get this bug reopened and prioritized. Thanks! Jeremy West Red Hat Support Supervisor