Red Hat Bugzilla – Bug 149384
RHEL4: Anaconda doesn't mount /usr when upgrading via kickstart
Last modified: 2008-07-28 11:37:30 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
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):
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
Created attachment 111305 [details]
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
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.
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 :)