Bug 149384 - RHEL4: Anaconda doesn't mount /usr when upgrading via kickstart
RHEL4: Anaconda doesn't mount /usr when upgrading via kickstart
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-22 12:50 EST by Trond H. Amundsen
Modified: 2008-07-28 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-28 11:37:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
kickstart file (744 bytes, text/plain)
2005-02-22 12:53 EST, Trond H. Amundsen
no flags Details
/tmp/anaconda.log from when the upgrade has started (8.23 KB, text/plain)
2005-02-23 04:28 EST, Trond H. Amundsen
no flags Details
/tmp/syslog from when the upgrade has started (18.03 KB, text/plain)
2005-02-23 04:28 EST, Trond H. Amundsen
no flags Details
/etc/fstab from the rhel3 box (926 bytes, text/plain)
2005-02-25 04:55 EST, Trond H. Amundsen
no flags Details
output from 'vgdisplay -v' (2.56 KB, text/plain)
2005-03-21 05:31 EST, Trond H. Amundsen
no flags Details

  None (edit)
Description Trond H. Amundsen 2005-02-22 12:50:28 EST
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:
Comment 1 Trond H. Amundsen 2005-02-22 12:53:10 EST
Created attachment 111305 [details]
kickstart file

I've edited out the root passwd.
Comment 2 Jeremy Katz 2005-02-22 13:21:33 EST
Can you provide /var/log/anaconda* from after the upgrade (or grab
/tmp/anaconda.log and /tmp/syslog from when the upgrade starts)
Comment 3 Trond H. Amundsen 2005-02-23 04:28:10 EST
Created attachment 111328 [details]
/tmp/anaconda.log from when the upgrade has started
Comment 4 Trond H. Amundsen 2005-02-23 04:28:47 EST
Created attachment 111329 [details]
/tmp/syslog from when the upgrade has started
Comment 5 Trond H. Amundsen 2005-02-23 04:32:42 EST
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.
Comment 6 Trond H. Amundsen 2005-02-24 05:39:34 EST
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 :)
Comment 7 Jeremy Katz 2005-02-24 15:43:23 EST
There's nothing there where the /usr LV is trying to be mounted.  Are
you sure it's specified in the fstab?
Comment 8 Trond H. Amundsen 2005-02-25 04:55:48 EST
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..
Comment 9 Trond H. Amundsen 2005-03-01 04:41:32 EST
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..
Comment 10 Jeremy Katz 2005-03-14 11:53:41 EST
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?
Comment 11 Trond H. Amundsen 2005-03-21 05:30:40 EST
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'.
Comment 12 Trond H. Amundsen 2005-03-21 05:31:53 EST
Created attachment 112172 [details]
output from 'vgdisplay -v'
Comment 13 Chris Hapgood 2006-01-25 15:10:46 EST
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...

 
Comment 14 Chris Hapgood 2006-01-25 18:52:57 EST
It was removing the LABEL that solved the problem.
Comment 15 Joel Andres Granados 2008-07-09 05:30:43 EDT
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?
Comment 16 Trond H. Amundsen 2008-07-09 08:42:10 EDT
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 :)

Note You need to log in before you can comment on or make changes to this bug.