Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 83816 - Installer mishandles LVM /usr
Summary: Installer mishandles LVM /usr
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: anaconda
Version: phoebe
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks: 79578
TreeView+ depends on / blocked
 
Reported: 2003-02-09 10:53 UTC by Harris Landgarten
Modified: 2007-04-18 16:50 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-02-13 21:57:42 UTC


Attachments (Terms of Use)
fstab as requested (deleted)
2003-02-10 22:29 UTC, Harris Landgarten
no flags Details

Description Harris Landgarten 2003-02-09 10:53:14 UTC
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
3.
    

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 19:56:43 UTC
This works for me here...  could you attach your /etc/fstab?

Comment 2 Harris Landgarten 2003-02-10 22:29:18 UTC
Created attachment 89980 [details]
fstab as requested

Comment 3 Jeremy Katz 2003-02-13 19:14:06 UTC
This is because your /usr is a jfs filesystem.  We don't support jfs filesystems.

Comment 4 Harris Landgarten 2003-02-13 21:27:57 UTC
You do obviously support JFS in the kernel so in what way don't you support JFS?

Comment 5 Harris Landgarten 2003-02-13 21:32:35 UTC
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 21:57:42 UTC
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 22:32:41 UTC
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.