Red Hat Bugzilla – Bug 455945
Resizing a lv results in the fstab entry being altered
Last modified: 2016-04-26 11:06:42 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
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.
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
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.
it should leave the fstab alone if there is already a valid entry.
the problem seem to be that in InputController.py apply() it does:
# remove old fstab entry
# 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.
Created attachment 312182 [details]
avoid updating fstab in at least some cases
Patch included in upstream:
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.
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 :)
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.
bugfix verified in system-config-lvm-1.1.5-4.el5
/etc/fstab now keeps fs mount options throughout usage of s-c-lvm
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.
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?
I'm not sure link works for me (even from non-RH network)