Bug 1024714
| Summary: | mount displays FS as read-write (rw) but the FS is read-only (ro) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Nenad Peric <nperic> |
| Component: | util-linux-ng | Assignee: | Karel Zak <kzak> |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.5 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-31 12:46:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
> mount: warning: /etc/mtab is not writable (e.g. read-only filesystem). > It's possible that information reported by mount(8) is not > up to date. For actual information about system mount points > check the /proc/mounts file. I guess this warning explains everything. It's known issue. > Expected results: > If a FS is read-only, mount command should not tell the user that it is > read-write. It means that mount(8) has to re-verify all information from /etc/mtab. It's ugly task and invasive change to mount(8) code. Sorry, won't fix. Note that this problem does not exist on RHEL7/Fedora where we don't use /etc/mtab any more. Well I can understand a reluctance to fix a known issue.. I suppose if it is too complicated and dangerous, it makes sense. Could the output just be modified, since 'mount' obviously knows it has issues sometimes. Say, to put in those brackets (unknown) or nothing at all since the information such as (rw) is quite unreliable? And even leaving the warning below as a complementary hint of what to do next is quite good. That should not be such an invasive and destructive change, it is just a matter of changing some of the output but would make it probably clearer to the user that mount actually has no clear idea of what is going on at that time. Saying (rw) when in fact it is not really known, is misleading :) |
Description of problem: If during booting a fsck of a filesystem needed fails due to misconfiguration of fstab, you will be dropped to maintenance mode, in which case the mount command shows wrong permissions on root (/) filesystem Version-Release number of selected component (if applicable): kernel-2.6.32-424.el6 util-linux-ng-2.17.2-12.14.el6 How reproducible: Everytime Steps to Reproduce: I created a crypt filesystem, but supplied a nonexistant password file, in which case the crypt fs was not unlocked, and device needed for fsck/mount was not created. It caused fsck to fail and drop me to maintenance mode. Inside it mount was showing / as RW where it actually was RO Actual results: fsck.exChecking all file systems. [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/mapper/vg_virt008-lv_root /dev/mapper/vg_virt008-lv_root: clean, 96038/440640 files, 651605/1759232 blocks . . fsck.ex fsck.ext3 -a /dev/mapper/enc_home fsck.ext3: No such file or directory while trying to open /dev/mapper/enc_home /dev/mapper/enc_home: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> [FAILED] *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. *** Warning -- SELinux is active *** Disabling security enforcement for system recovery. *** Run 'setenforce 1' to reenable. [root@virt-008 ~]# mount /dev/mapper/vg_virt008-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) mount: warning: /etc/mtab is not writable (e.g. read-only filesystem). It's possible that information reported by mount(8) is not up to date. For actual information about system mount points check the /proc/mounts file. After remount of /, everything came back to normal, meaning the system was read-write as it was said by a mount command. Expected results: If a FS is read-only, mount command should not tell the user that it is read-write.