Hide Forgot
Description of problem: initscripts does not support a straight forward mechanism to run a later quotacheck on even clean partitions. Version-Release number of selected component (if applicable): initscripts-7.93.11.EL-1 How reproducible: Always Steps to Reproduce: 1. install RHEL4 2. create some new partitions 3. mount some new partitions 4. decide to use quota on this (now already used) new partitions 5. extend entries in /etc/fstab 6. reboot Actual Results: Got quota error message, systen can't start quota because of missing quota files Expected Results: rc.sysinit is more smarter, e.g. 1) support file /forcequotacheck 2) check on partitions with quota enabled in /etc/fstab for the quota files and force quotacheck if not existing (so called initialize) Additional info:
Created attachment 114987 [details] /forcequotacheck support in rc.sysinit This is a proposed solution to this - a patch to /etc/rc.sysinit from Fedora Core 3. There is no easy way to enable quotas or force quotacheck because of corrupted quota files so I think support for /forcequotacheck is needed. It could now only be done in single user mode - quotacheck remount filesystems readonly, which is impossible on life system - especially on "/" or "/var". Very hard for unskilled administrator. It could be possible to add support for checking quotas of some, not all filesystems - but I think it is not needed. Also there could be possible to force quotacheck if a filesystem have quotas enables but no quota files - but this could trigger everytime for example on XSF filesystem, which does not need quota files.
qutacheck should be run automagically when fsck fix a bug on FS because there will be surely inconsistence (as FS has been modified and quota entries did not).
...my users always complaining after unexpected crashes when fsck has been succesfully auto-run (and FS has been succesfully fixed). As I have 700+ users and low quota, some of them are sometimes over the quota even they have empty homedir and I have to run quotacheck manually in singleuser mode (and walk to the server's room).
This problem is scheduled to be resolved in the next release of Red Hat Enterprise Linux. Red Hat does not currently plan to provide a resolution for this in a Red Hat Enterprise Linux update for currently deployed systems. With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating changes for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.