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 455945 - Resizing a lv results in the fstab entry being altered
Summary: Resizing a lv results in the fstab entry being altered
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: system-config-lvm
Version: 5.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Marek Grac
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-19 02:29 UTC by Jonathan Peatfield
Modified: 2016-04-26 15:06 UTC (History)
5 users (show)

Fixed In Version: system-config-lvm-1.1.5-3.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-03-30 08:42:55 UTC
Target Upstream Version:

Attachments (Terms of Use)
avoid updating fstab in at least some cases (deleted)
2008-07-19 02:29 UTC, Jonathan Peatfield
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0267 normal SHIPPED_LIVE system-config-lvm bug fix update 2010-03-29 12:54:55 UTC

Description Jonathan Peatfield 2008-07-19 02:29:37 UTC
Description of problem:

If an admin uses system-config-lvm to online resize an existing mounted volume
then after it completes it re-writes the fstab entry and removes any non-default
mount options.

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

system-config-lvm-1.1.3-2.0.el5.noarch but it seems to have done this for a long
time, I just tested on EL5.2, EL5.1, EL4.4 boxes that I have access to today.

How reproducible:


Steps to Reproduce:
1. add nosuid,nodev,quota to an fstab options entry /home say
2. use system-config-lvm to increase it a little (edit the properties of the lv)
3. look at the fstab entry now
Actual results:

the nosuid,nodev,quota options have gone from fstab so won't be used next time
the fs is mounted.  Luckily it doesn't do the remount itself.

Expected results:

it should leave the fstab alone if there is already a valid entry.

Additional info:

the problem seem to be that in apply() it does:

            # remove old fstab entry
            if mount_at_reboot_new:
                # add new entry
                Fstab.add(lv_path, mountpoint_new, fsname)

even if there is already an active fstab entry.  That is about line 2192 in the
file from system-config-lvm-1.1.3-2.0.el5.noarch

Possibly it shouldn't do that when just doing something like a size change.

I've attached a patch which stops it messing with fstab under some conditions
but it may be totally wrong or break other stuff.  Ideally the existing options
should be read from fstab so e.g. a move to a different mount point or an lv
rename etc could work properly.

If things like nosuid,nodev are removed by accident then this could cause
security problems, or if quota is removed it may cause other problems but only
if an admin does the lv resize using this tool and doesn't notice that fstab is
'altered'.  I decided not to check the 'security' box, but feel free to correct me.

Comment 1 Jonathan Peatfield 2008-07-19 02:29:37 UTC
Created attachment 312182 [details]
avoid updating fstab in at least some cases

Comment 4 Jonathan Peatfield 2009-12-15 14:31:29 UTC
That still does a remove followed by an add so though the new entry should have the right options the *order* of entries can be changed.

Consider an fstab which contains:

  /dev/VG2LV1 /local  ext3 defaults,nosuid  1 2
  /dev/VG3LV2 /local/store  ext3 defaults,nosuid  1 2

then editing the properties of the first (/local) would seem to move it to the end of fstab - and cause problems on next boot (/local/store may not exist and even if it does the later mount of /local would cover it).

Of course trying to work out all the possible ways this can break is hard which is why it seemed a good idea to leave the existing fstab alone unless something was actually being changed - not that my hack patch did the right thing either...

A modified version of __remove() could be written which added an entry at the point of a removal but it might need to be given mount_point and mountpoint_new to look for both (if the mountpoints arn't the same I suppose that moving the line to the end isn't too bad since the admin probably needs to manually edit the fstab anyway)...

Or am I mis-reading the new logic?

Of course the new version should be much better than the old one, since the odd cases where it will break things are probably far less common.

 -- Jon

Comment 5 Marek Grac 2009-12-16 13:48:14 UTC
Thanks, for comment.

Order was not mentioned in your first post but you are right. If you are not really against it, I would like to mark this bug as fixed and create a new bug with ordering problem. That way we can push this patch into next update and it is better then previous state :)

Comment 6 Jonathan Peatfield 2009-12-16 13:52:56 UTC
Yes sure.  Sorry the fstab order issue only occurred to me while I was reading the patch, so that probably should be added to this ticket.

Comment 8 Brian Brock 2010-03-08 20:52:55 UTC
bugfix verified in system-config-lvm-1.1.5-4.el5

/etc/fstab now keeps fs mount options throughout usage of s-c-lvm

Comment 10 errata-xmlrpc 2010-03-30 08:42:55 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Comment 11 Jonathan Peatfield 2010-03-30 10:52:05 UTC
Trying to follow the link given in #10 results in a not found error (redirecting to, is this because the errata is actually still pending or have I misunderstood what is going on?

Comment 12 Marek Grac 2010-04-02 12:50:47 UTC

I'm not sure link works for me (even from non-RH network)

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