Bug 1214524 - quotacheck on ext4 fails to mount the fs readonly
Summary: quotacheck on ext4 fails to mount the fs readonly
Status: RESOLVED INVALID
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Jan Kara
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-23 10:38 UTC by Thomas Blume
Modified: 2023-08-24 09:08 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
/etc/fstab (592 bytes, text/plain)
2023-08-23 10:52 UTC, Thomas Blume
Details
testlog with output of /proc/mounts (8.72 KB, text/plain)
2023-08-23 10:53 UTC, Thomas Blume
Details
dmesg (156.19 KB, text/plain)
2023-08-23 11:05 UTC, Thomas Blume
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Blume 2023-08-23 10:38:30 UTC
A recent openSUSE tumbleweed:

-->
# cat /etc/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20230819"
--<

has entries to enable quota in /etc/fstab:

-->
# cat /etc/fstab 
UUID=e2c10d86-b086-4501-9142-2c0bb54108bb  /          ext4  usrquota,grpquota               0  1
UUID=3ba8d33f-3159-45f5-b458-e44a8f44171f  /mnt1      ext4  usrquota,grpquota,data=ordered  0  2
UUID=F558-7EE7                             /boot/efi  vfat  utf8                            0  2
UUID=ef3a5247-bceb-47fb-9934-837ac12f734f  /STORE     ext4  usrquota,grpquota,data=ordered  0  2
UUID=581aa75c-ec2c-41d6-84ed-68055471c33a  swap       swap  defaults                        0  0
UUID=b05177ba-4f53-4f98-9b59-5bd4d30d8c29  /mnt/rshare1 ext4  _netdev,usrquota,grpquota,data=ordered  0  2
--<


Running quotacheck on an rw mounted ext4 file system in order to recreate the aquota.* files results in an error:

-->
# quotaoff -ug /mnt1
# 
# ls -l /mnt1/
total 32
-rw------- 1 root root  6144 Aug 22 11:39 aquota.group
-rw------- 1 root root  6144 Aug 22 11:39 aquota.user
-rw-r--r-- 1 root root     0 Aug 21 14:42 bla
drwx------ 2 root root 16384 Jun 28 08:36 lost+found


# rm /mnt1/aquota.*
#

# umount /mnt1 && mount -o,rw /mnt1/

# quotacheck -ug /mnt1/
quotacheck: Cannot find filesystem to check or filesystem not mounted with quota option.
#

# ls -l /mnt1/
total 16
-rw-r--r-- 1 root root     0 Aug 21 14:42 bla
drwx------ 2 root root 16384 Jun 28 08:36 lost+found
--<

The test succeeds though, when the file system is mounted ro:

-->
# rm /mnt1/aquota.*
# 

# ls -l /mnt1/
total 16
-rw-r--r-- 1 root root     0 Aug 21 14:42 bla
drwx------ 2 root root 16384 Jun 28 08:36 lost+found

# umount /mnt1 && mount -o,ro /mnt1/
# 
# quotacheck -ug /mnt1/
quotacheck: Your kernel probably supports ext4 quota feature but you are using external quota files. Please switch your filesystem to use ext4 quota feature as external quota files on ext4 are deprecated. You can enable the feature by unmounting the file system and running 'tune2fs -O quota <device>'.
# 

# ls -l /mnt1/
total 32
-rw------- 1 root root  6144 Aug 23 12:24 aquota.group
-rw------- 1 root root  6144 Aug 23 12:24 aquota.user
-rw-r--r-- 1 root root     0 Aug 21 14:42 bla
drwx------ 2 root root 16384 Jun 28 08:36 lost+found
--<

This behaviour differs from the manpage states:


-->
quotacheck expects each filesystem to be checked to have quota files
       named [a]quota.user and [a]quota.group located at the root of the associated filesystem.  If a file is not present, quotacheck will create it.
[...]
To prevent this, quotacheck tries to remount the filesystem read-only before starting the scan.  After the scan is done it remounts the filesystem read-write.
--<

So, there seem to be 2 issues:

1. The error message when the fs is mounted rw indicates that there are no quot mount options, but they are:

-->
# quotacheck -ug /mnt1/
quotacheck: Cannot find filesystem to check or filesystem not mounted with quota option.
# 
# cat /proc/mounts | grep mnt1
/dev/vdc /mnt1 ext4 rw,relatime,quota,usrquota,grpquota,data=ordered 0 0


2. quotacheck apparently fails to remount the fs ro as stated in the manpage but it succeeds to remount the fs rw again after successful check:


# umount /mnt1 && mount -o,ro /mnt1/

# cat /proc/mounts | grep mnt1
/dev/vdc /mnt1 ext4 ro,relatime,quota,usrquota,grpquota,data=ordered 0 0

quotacheck -ug /mnt1/
quotacheck: Your kernel probably supports ext4 quota feature but you are using external quota files. Please switch your filesystem to use ext4 quota feature as external quota files on ext4 are deprecated. You can enable the feature by unmounting the file system and running 'tune2fs -O quota <device>'.

# cat /proc/mounts | grep mnt1
/dev/vdc /mnt1 ext4 rw,relatime,quota,usrquota,grpquota,data=ordered 0 0
Comment 1 Thomas Blume 2023-08-23 10:52:39 UTC
Created attachment 868967 [details]
/etc/fstab
Comment 2 Thomas Blume 2023-08-23 10:53:03 UTC
Created attachment 868968 [details]
testlog with output of /proc/mounts
Comment 4 Thomas Blume 2023-08-23 11:04:16 UTC
> 2. quotacheck apparently fails to remount the fs ro as stated in the manpage
> but it succeeds to remount the fs rw again after successful check:

I might have been wrong with this, dmesg of my tests indicates that quotacheck does the rmount:

-->
[10208.022750] EXT4-fs (vdc): mounted filesystem 3ba8d33f-3159-45f5-b458-e44a8f44171f r/w with ordered data mode. Quota mode: journalled.
[10240.257558] EXT4-fs (vdc): mounted filesystem 3ba8d33f-3159-45f5-b458-e44a8f44171f ro with ordered data mode. Quota mode: journalled.
[10253.145118] EXT4-fs (vdc): re-mounted 3ba8d33f-3159-45f5-b458-e44a8f44171f ro. Quota mode: journalled.
[10253.154069] EXT4-fs (vdc): re-mounted 3ba8d33f-3159-45f5-b458-e44a8f44171f r/w. Quota mode: journalled.
--<

Attaching dmesg too.
Comment 5 Thomas Blume 2023-08-23 11:05:03 UTC
Created attachment 868971 [details]
dmesg
Comment 6 Thomas Blume 2023-08-24 09:08:46 UTC
(In reply to Thomas Blume from comment #5)
> Created attachment 868971 [details]
> dmesg

After investigation by Jan, it turned out that the issue was caused by a corrupted system root filesystem.
That, in turn affected the kernel module loading of the kernel module with quota format.
After re-installation of the system, the issue is not reproducible anymore.

So, this report was invalid, closing.