Last Modified: Jul 23, 2021
See more info
Known Affected Versions:
14.1.0, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 14.1.2, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 14.1.3, 188.8.131.52, 14.1.4, 184.108.40.206, 220.127.116.11, 18.104.22.168, 15.1.0, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 15.1.1, 15.1.2, 18.104.22.168, 15.1.3, 22.214.171.124, 16.0.0, 126.96.36.199, 16.0.1, 188.8.131.52, 184.108.40.206, 16.1.0
Opened: Jun 09, 2021
Forcing a file system check on the next system reboot, as described in K73827442, does not check all filesystems, but only the root (/) filesystem. This should not be the case and is a regression compared to previous BIG-IP versions. After the reboot, you can inspect which filesystems were checked by running the following command: journalctl --all --no-pager | grep -i fsck
Some filesystems will not be fixed, and will continue to be corrupted. This can have a number of negative consequences. For instance, enlarging a filesystem (via the 'tmsh modify sys disk directory' command) can fail when a filesystem is dirty.
A BIG-IP Administrator follows the procedure to force a file system check on the next system reboot.
You can boot the system from the Maintenance Operating System (MOS), and perform all needed file system check operations from there. To boot the system into MOS, simply type 'mosreboot'. Note that once the system reboots into MOS, you will need video console access (for VE systems) or serial console access (for hardware systems) to be able to run fsck and the reboot the system into a regular BIG-IP boot location. For more information on MOS, please refer to K14245.