Created attachment 199932 [details] Patch https://svnweb.freebsd.org/base?view=revision&revision=339008 broke repquote on UFS. To fix it, I use attached patch. Apparently it wants qf->qfname to be filled in by hasquota(). No idea if calling hasquota() hurts for non-UFS...
Notify committer of r339008.
I saw the original email about the issue, but have not looked any deeply into it yet.
ok. repquota is going through and reading the quoata file. Which it can only do on UFS. There is, as far as I can tell, no problem with checking hasquota() first, although if it returns no error, then there's no reason to call quotactl() afterwards, I think. This means the code should be moved around and refactored a bit to get the tests done in the right way -- namely, only call quotactl() if hasquota() fails, but fail if quotactl() fails, but also if hasquota() succeeds but it's not UFS. (For now, anyway.)
A commit references this bug: Author: sef Date: Thu Feb 7 21:51:39 UTC 2019 New revision: 343881 URL: https://svnweb.freebsd.org/changeset/base/343881 Log: r339008 broke repquota for UFS. This rectifies that. Refactor the function calls and tests so that, on UFS, the proper fields are filled out. PR: 233849 Reported by: Andre Albsmeier Reviewed by: mav, delphij MFC after: 1 month Sponsored by: iXsystems Inc Differential Revision: https://reviews.freebsd.org/D18785 Changes: head/lib/libutil/quotafile.c
A commit references this bug: Author: sef Date: Thu Feb 7 22:10:21 UTC 2019 New revision: 343882 URL: https://svnweb.freebsd.org/changeset/base/343882 Log: r343881 had an uninitialized error. This fixes that. PR: 233849 Reported by: Andre Albsmeier MFC after: 1 month Sponsored by: iXsystems Inc Differential Revision: https://reviews.freebsd.org/D18785 Changes: head/lib/libutil/quotafile.c
Hello FreeBSD FreeBSD 12.0-STABLE r344111 GENERIC amd64 We are use groupquota. repquota return data about only wheel group # repquota -g /mnt/hosting Block limits File limits User used soft hard grace used soft hard grace wheel -- 2385444 0 0 - 60633 0 0 - edquota/quotacheck/quota -gv uses normally. If yor execute quotaoff -a , everything works fine - repquota return data about all group. # repquota -g /mnt/hosting Block limits File limits User used soft hard grace used soft hard grace wheel -- 2385444 0 0 - 60633 0 0 - operator -- 192 0 0 - 1 0 0 - staff -- 328876 0 0 - 19568 0 0 - www -- 1240 0 0 - 29 0 0 - mariadb -- 3653288 0 0 - 948 0 0 - Patch https://reviews.freebsd.org/D18785 helped us. Please commit this in STABLE branche. Thanks a lot
A commit references this bug: Author: sef Date: Mon Mar 11 03:00:33 UTC 2019 New revision: 344997 URL: https://svnweb.freebsd.org/changeset/base/344997 Log: MFC r343881 r339008 broke repquota for UFS. This rectifies that. Refactor the function calls and tests so that, on UFS, the proper fields are filled out. PR: 233849 Changes: _U stable/12/ stable/12/lib/libutil/quotafile.c
A commit references this bug: Author: sef Date: Mon Mar 11 03:01:58 UTC 2019 New revision: 344998 URL: https://svnweb.freebsd.org/changeset/base/344998 Log: MFC r343882 r343881 had an uninitialized error. This fixes that. PR: 233849 Changes: _U stable/12/ stable/12/lib/libutil/quotafile.c
Not committed in 11-STABLE, 11.3-RELEASE, repquota doesn't work: FreeBSD XXX 11.3-STABLE FreeBSD 11.3-STABLE #23 r349909: Thu Jul 11 16:01:04 CEST 2019 repquota /home Block limits File limits User used soft hard grace used soft hard grace root -- 836341780 0 0 - 62221 0 0 - No users reported, only root.
Fix committed to head and stable/12 Pending stable/11 MFC ^Triage: Assign to committer resolving
My question is does this need to go into 11/stable? I don't have the test systems for this any longer, which makes me a bit hesitant, but I can't try to reproduce them.
I can confirm this bug on my end still exists: root@srv2:~ # repquota / Block limits File limits User used soft hard grace used soft hard grace root -- 18505800 0 0 - 843339 0 0 - root@srv2:~ # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 11.3-RELEASE from update2.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 11.3-RELEASE-p3. root@srv2:~ # uname -v FreeBSD 11.3-RELEASE-p2 #0: Tue Aug 6 05:07:20 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
> My question is does this need to go into 11/stable? Yes.
A commit references this bug: Author: sef Date: Tue Sep 3 04:50:39 UTC 2019 New revision: 351730 URL: https://svnweb.freebsd.org/changeset/base/351730 Log: MFC r343881, r343882 r339008 broke repquota for UFS. This rectifies that. PR: 233849 Changes: _U stable/11/ stable/11/lib/libutil/quotafile.c
Ok, I MFC'd the two patches.
quotacheck has the same problem. It only works with quotaoff.
I did the patch for 11.3-RELEASE-p3 on quotafile.c and compiled it, but it still didn't worked.
The function "quota_maxid" gives a zero in return with quotaon, but gives the real "maxid" with quotaoff. So there is the bug. The patch for ufs is useless. I put temperarely "maxid = 65534;" (nobody) in repquota and quotacheck And that works.
After upgrade from 11.2 to 11.3-RELEASE-p6 i got same problem on two servers. I applied patch from here: New revision: 351730 URL: https://svnweb.freebsd.org/changeset/base/351730 It works!
11.3-RELEASE-p8 included an update to /usr/src/usr.bin/quota/quota.c but unfortunately it did not resolve the issue.
(In reply to Philip Petrov from comment #20) Because the problem is in lib/libutil/quotafile.c. I don't understand, why it takes so long time to close an outright bug.
(In reply to freebsd from comment #21) Because people forget to compile both /usr/src/lib/libutil/quotafile.c AND /usr/src/usr.sbin/repquota/repquota.c or else the patch doesn't work. The issue has been solved months ago. Update it with freebsd-update.
(In reply to johan liet from comment #22) This(In reply to johan liet from comment #22) Fix only in STABLE.
(In reply to freebsd from comment #23) There was a freebsd-11.3 update for repquota on 4 Oct 2019 on the release branch. Wasn't that the bug fix ?
(In reply to johan liet from comment #24) No.
(In reply to freebsd from comment #25) Then you have to compile the source like I said in comment 22 or upgrade to Freebsd-release-11.4. Release 11.3 will be end of life over 2 months. I am not a maintainer so that's all I can tell you about repquota.
(In reply to johan liet from comment #26) I build kernel and world from source, so get the patch from STABLE is not problem for me. 11.4 is not released yet.
(In reply to freebsd from comment #27) release 11.4 is about to be released or upgrade to release-12.1 As a last solution you can download my repquota from http://homeunix.nl/downloads/repquota it is a ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.3, FreeBSD-style, stripped
(In reply to johan liet from comment #28) I don't need this. And your file is useless, because problem in /lib/libutil.so.9 :)
(In reply to johan liet from comment #28) This is not helping and fixing the issue.
(In reply to Philip Petrov from comment #30) Last time, then I give up. remember. it is a 32 bit executable /lib/libutil.so.9: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, stripped http://homeunix.nl/downloads/libutil.so.9
(In reply to johan liet from comment #31) No one in their right mind will download binary files from an unknown source. Sorry.
(In reply to freebsd from comment #32) Shure, I am subscribed to this bug list and try to help you the last 4 hours just to hack your computer. Have a good day.
We just want the fix will appear in RELENG.
The fix should be available in all supported releases; please re-open with details if this is not the case.