+++ This bug was initially created as a clone of Bug #623656 +++
repquota from Fedora-14 parses /etc/mtab. repquota from git HEAD (actually since d271d0a329a5b3e99f4ad209b5270a8648739ff0 (Use /proc/mounts for mountpoint scanning)) parses /proc/mounts.

The mount point line in time of repquota exec looks following:

$ grep scratch /etc/mtab
/dev/mapper/vg_dhcp0122-test--scratch /mnt/test-scratch xfs rw,context="system_u:object_r:nfs_t:s0",usrquota,grpquota,noquota,usrquota,grpquota 0 0

$ grep scratch /proc/mounts 
/dev/mapper/vg_dhcp0122-test--scratch /mnt/test-scratch xfs rw,context=system_u:object_r:nfs_t:s0,relatime,attr2,usrquota,grpquota 0 0

As you can see mount(8) edits mtab in really weird manner and that confuses repqouta.

--- Additional comment from esandeen on 2010-11-23 16:39:58 GMT ---

yeesh!

Ok so somebody was doing a mount -o remount, and I think that's what led to the really weird mount string?

For what its worth, quota-4.0.0 on a rhel6 box passes unmodified test 231 for me ... I can't demonstrate a test script bug.

--- Additional comment from ppisar on 2010-11-23 17:24:13 GMT ---

I cannot see double mount on RHEL-6 (and it does not complain about busy file system), however in Fedora-14 I can see it by strace:

$ < /tmp/231.log  grep execve |grep mount | grep -E '(scratch|dm-7)'
[pid 32155] execve("/bin/umount", ["umount", "/dev/dm-7"], [/* 97 vars */]) = 0
[pid 32166] execve("/bin/mount", ["/bin/mount", "-t", "xfs", "-o", "context=system_u:object_r:nfs_t:"..., "/dev/dm-7", "/mnt/test-scratch/"], [/* 97 vars */]) = 0
[pid 32409] execve("/bin/mount", ["/bin/mount", "-t", "xfs", "-o", "context=system_u:object_r:nfs_t:"..., "/dev/dm-7", "/mnt/test-scratch/"], [/* 97 vars */]) = 0
[pid 32434] execve("/bin/mount", ["mount", "-o", "remount,noquota", "/dev/dm-7"], [/* 97 vars */]) = 0
[pid 32435] execve("/bin/mount", ["mount", "-o", "remount,usrquota,grpquota", "/dev/dm-7"], [/* 97 vars */]) = 0
[pid 32495] execve("/bin/mount", ["mount", "-o", "remount,noquota", "/dev/dm-7"], [/* 97 vars */]) = 0
[pid 32496] execve("/bin/mount", ["mount", "-o", "remount,usrquota,grpquota", "/dev/dm-7"], [/* 97 vars */]) = 0
[pid 32528] execve("/bin/mount", ["mount", "-o", "remount,noquota", "/dev/dm-7"], [/* 97 vars */]) = 0
[pid 32529] execve("/bin/mount", ["mount", "-o", "remount,usrquota,grpquota", "/dev/dm-7"], [/* 97 vars */]) = 0
[pid 32542] execve("/bin/umount", ["umount", "/dev/dm-7"], [/* 97 vars */]) = 0

Here you can see the funny remount stuff leading to disruptive /etc/mtab.

Fedora-14 behaviour is not subject of this bug report, I just add it as notice there are such problems.

--- Additional comment from esandeen on 2010-11-24 14:53:11 GMT ---

Weird.  Well, thanks.  I'll keep an eye out for it.

--- Additional comment from ppisar on 2010-11-25 16:05:32 GMT ---

Created attachment 462931 [details]
Fix

Back-ported fix from 4.00_pre1 upstream version.

This patch makes quota tools to parse /proc/mounts in favor to /etc/mtab as /etc/mtab gets corrupted by noquota/usrquota remounts.

--- Additional comment from ppisar on 2010-11-25 16:28:15 GMT ---

How to test:

(1) Create XFS file system
(2) Mount it with -o usrquota
(3) remount with -o remount,noquota
(4) remount with -o remount,usrquota
(5) run repquota -nu on the file system

Affected version complains:
repquota: Mountpoint (or device) /mnt/test not found or has no quota enabled.
repquota: Not all specified mountpoints are using quota.

Fixed version print quota details:
*** Report for user quotas on device /dev/mapper/vg_dhcp0122-test
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
#0        --       0       0       0              3     0     0