Bug 149384
Summary: | RHEL4: Anaconda doesn't mount /usr when upgrading via kickstart | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Trond H. Amundsen <t.h.amundsen> | ||||||||||||
Component: | anaconda | Assignee: | Peter Jones <pjones> | ||||||||||||
Status: | CLOSED NOTABUG | QA Contact: | |||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||
Priority: | medium | ||||||||||||||
Version: | 4.0 | CC: | cch1 | ||||||||||||
Target Milestone: | --- | ||||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | i386 | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2008-07-28 15:37:30 UTC | Type: | --- | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Attachments: |
|
Description
Trond H. Amundsen
2005-02-22 17:50:28 UTC
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 :) |