Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 83816 - Installer mishandles LVM /usr
Installer mishandles LVM /usr
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
Depends On:
Blocks: 79578
  Show dependency treegraph
Reported: 2003-02-09 05:53 EST by Harris Landgarten
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-02-13 16:57:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fstab as requested (1.05 KB, text/plain)
2003-02-10 17:29 EST, Harris Landgarten
no flags Details

  None (edit)
Description Harris Landgarten 2003-02-09 05:53:14 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021216

Description of problem:
I ran a phoebe upgrade install on Redhat 8 with /usr mounted on an LVM  volume.
Anaconda installed a new /usr on / partition and copied all /usr files there. It
then mounted the /usr in fstab (the LVM one) properly leaving all of the files
copied to /usr invisable and an unstable system  

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:
1.Create LVM VG and mount /usr one it in RH 8
2.Upgrade to phoebe

Actual Results:  none of the files in /usr were upgraded and alot of disk space
disappeared for the root volume

Expected Results:  the /usr in fstab should have been used in the upgrade

Additional info:
Comment 1 Jeremy Katz 2003-02-10 14:56:43 EST
This works for me here...  could you attach your /etc/fstab?
Comment 2 Harris Landgarten 2003-02-10 17:29:18 EST
Created attachment 89980 [details]
fstab as requested
Comment 3 Jeremy Katz 2003-02-13 14:14:06 EST
This is because your /usr is a jfs filesystem.  We don't support jfs filesystems.
Comment 4 Harris Landgarten 2003-02-13 16:27:57 EST
You do obviously support JFS in the kernel so in what way don't you support JFS?
Comment 5 Harris Landgarten 2003-02-13 16:32:35 EST
In addition, even if you don't support JFS in anaconda, a fact that I didn't see
documented anywhere, you couldn't have pick a worse choice for handling an
unsupported filesystem. You just decide to ignore what was in fstab and without
any user notification create a new /usr. Wouldn't it have been a much better
choice to stop the installation and let the user decide what to do like you do
for third party rpms?
Comment 6 Jeremy Katz 2003-02-13 16:57:42 EST
It's not supported because it's not a filesystem type we allow you to create
during the installation process.   I'll fix this better in a future release, but
for now am just sucking the jfs module onto the second stage and then it'll
mount.  It's still not a supported configuration, though.
Comment 7 Harris Landgarten 2003-02-13 17:32:41 EST
If an upgrade installation runs to completion, you should deliver a stable
working system. There must be something you can do to abort the installation if
a system partition is on a jfs volume. Even if you can't read the volume in
stage one, you can certainly read fstab so long as /etc isn't jfs. Secondly,
isn't a missing /usr an exception that should be noticed.

I know you can do better than creating a new partion and then mounting the jfs
partion on top of it making it invisable and not notifying the user that
anything is wrong.

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