Bug 1024714 - mount displays FS as read-write (rw) but the FS is read-only (ro)
mount displays FS as read-write (rw) but the FS is read-only (ro)
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: util-linux-ng (Show other bugs)
6.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Karel Zak
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-30 06:00 EDT by Nenad Peric
Modified: 2013-10-31 08:59 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-31 08:46:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nenad Peric 2013-10-30 06:00:30 EDT
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.
Comment 3 Karel Zak 2013-10-31 08:46:06 EDT
> 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.
Comment 4 Nenad Peric 2013-10-31 08:59:22 EDT
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 :)

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