This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 455945 - Resizing a lv results in the fstab entry being altered
Resizing a lv results in the fstab entry being altered
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: system-config-lvm (Show other bugs)
5.2
All Linux
low Severity high
: rc
: ---
Assigned To: Marek Grac
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-18 22:29 EDT by Jonathan Peatfield
Modified: 2016-04-26 11:06 EDT (History)
5 users (show)

See Also:
Fixed In Version: system-config-lvm-1.1.5-3.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 04:42:55 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)
avoid updating fstab in at least some cases (1.04 KB, patch)
2008-07-18 22:29 EDT, Jonathan Peatfield
no flags Details | Diff

  None (edit)
Description Jonathan Peatfield 2008-07-18 22:29:37 EDT
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:

100%

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 InputController.py apply() it does:

...
            # remove old fstab entry
            Fstab.remove(self.mount_point)
            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-18 22:29:37 EDT
Created attachment 312182 [details]
avoid updating fstab in at least some cases
Comment 4 Jonathan Peatfield 2009-12-15 09:31:29 EST
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 08:48:14 EST
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 08:52:56 EST
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 15:52:55 EST
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 04:42:55 EDT
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.

http://rhn.redhat.com/errata/RHBA-2010-0267.html
Comment 11 Jonathan Peatfield 2010-03-30 06:52:05 EDT
Trying to follow the link given in #10 results in a not found error (redirecting to https://rhn.redhat.com/file_not_found.pxt), is this because the errata is actually still pending or have I misunderstood what is going on?
Comment 12 Marek Grac 2010-04-02 08:50:47 EDT
@Jonathan:

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.