Bug 455945
| Summary: | Resizing a lv results in the fstab entry being altered | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Jonathan Peatfield <j.s.peatfield> | ||||
| Component: | system-config-lvm | Assignee: | Marek Grac <mgrac> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 5.2 | CC: | agk, cluster-maint, dwysocha, mbroz, prockai | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| 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 08:42:55 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 312182 [details]
avoid updating fstab in at least some cases
Patch included in upstream: http://git.fedoraproject.org/git/system-config-lvm.git?p=system-config-lvm.git;a=commit;h=fa41ee38b2acbae5a2cfb8429006ed9cc8531842 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 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. http://rhn.redhat.com/errata/RHBA-2010-0267.html 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? @Jonathan: I'm not sure link works for me (even from non-RH network) |
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.