From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: Anaconda complains about /usr/tmp being a directory rather than a symlink and aborts the upgrade process, but doesn't mount /usr. The /usr filesystem is on a separate partition in the same volume group as /tmp, /var etc., which is also separate partitions. All other filesystems than /usr get mounted. Mounting /usr manually in the shell provided with anaconda works fine, and reveals that /usr/tmp is indeed a (relative) symlink. The anaconda log says that it found /usr, and is going to mount it, but fails to do so, without any error message. I don't have the exact messages at hand, but you get the picture. I've included the kickstart file as an attachment. The method of upgrade used is quite simple, using boot.iso and the kickstart file on a floppy, but I don't think that has anything to do with it failing. The machine in question is recently installed from scratch, and is running RHEL3U4 with all updates installed. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Boot from boot.iso provided with RHEL4 cd#1 2.Specify kickstart install with the attached kickstart file Actual Results: Explained above Expected Results: The system is upgraded without errors Additional info:
Created attachment 111305 [details] kickstart file I've edited out the root passwd.
Can you provide /var/log/anaconda* from after the upgrade (or grab /tmp/anaconda.log and /tmp/syslog from when the upgrade starts)
Created attachment 111328 [details] /tmp/anaconda.log from when the upgrade has started
Created attachment 111329 [details] /tmp/syslog from when the upgrade has started
In the above attachments, the machine was booted from harddrive, with ks.cfg also on the harddrive, and using grub to boot with vmlinuz/initrd grabbed from boot.iso. In principle no different from booting from cd with ks.cfg on a floppy, and I get exactly the same error. Just FYI.
I just tried the same upgrade process on another machine, which also has /usr on a separate partition, but doesn't use LVM at all. Big success :)
There's nothing there where the /usr LV is trying to be mounted. Are you sure it's specified in the fstab?
Created attachment 111420 [details] /etc/fstab from the rhel3 box As you can see, /usr is specified in /etc/fstab, and there's nothing fancy about it. This kind of partitioning is pretty standard at our site. I'll check to see if I get the same result on boxes with nearly identical configuration. The bug may just be a freak occurrance..
I've now done ks-upgrade of a few boxes that use LVM and has /usr on a separate LV. No problem. My conclusion is then that this problem is limited to a few (or one) machines with some unknown criteria that make them special in some way. Regardless, it's still a bug which should be fixed. PS. The fact that tg3.ko doesn't work is a much more serious problem. Please attend to this (bug id #149682). This one really bites us..
Do you know if the other LVs are getting mounted? Could there be something like LVM1 snapshots or anything interesting about the LVM setup on the box that failed?
All other LVs are getting mounted, and there is nothing special about the LVM setup on this particular machine. I'll attach the output from 'vgdisplay -v'.
Created attachment 112172 [details] output from 'vgdisplay -v'
I had the exact same problem on Fedora Core 4. My usr filesystem is on an LVM partition, and my fstab lists it with the LABEL=/usr syntax. I changed the LABEL=/usr syntax to a device (/dev/mapper...) and also added a link in the /usr mount point to ../var/tmp and the installation progressed. Not sure which adjustment solved the problem, but my money is on the link...
It was removing the LABEL that solved the problem.
FYI: In-place upgrades across major releases do not preserve all system settings, services, and custom configurations. For this reason, Red Hat strongly recommends that you perform a fresh installation rather than a system upgrade between major versions. Upgrade is to be used for minor versions. Did this issue occur with a major release update of minor release update?
It was a major release upgrade. We are aware that a fresh installation is the recommended option, and has switched to this some time ago. This bug is no longer an issue for me. If you feel like closing it, please do so :)