After discussing the issue with Adam Blomberg (paradox606), he suggested enabling the verbose option to get more information regarding the scan.
He indicated that this can be done by modifying /etc/default/rcS to include "VERBOSE=yes", and that it is also possible to force the repair of errors with the "FSCKFIX=yes" option. This will result in additional detail in the logs SideShowFry (fry-n) was looking at. Adam's suggested method: 12.04 Force FIlesystem Check: ----------------------------------------- # tell system to force filesystem checks on startup for all filesystems in /etc/fstab with indications to do filesystem checks. touch /forcefsck # Tell system to be more verbose at startup sudo sed -i "s/VERBOSE=no/VERBOSE=yes/" /etc/default/rcS # Then, after reboot, examine /var/log/boot.log, the results of the filesystem check will be visible there. # If you also want the filesystem check to perform all repairs, make this change: sudo sed -i "s/FSCKFIX=no/FSCKFIX=yes/" /etc/default/rcS 14.04 Force FIlesystem Check: ----------------------------------------- # tell system to force filesystem checks on startup for all filesystems in /etc/fstab with indications to do filesystem checks. touch /forcefsck # Tell system to be more verbose at startup sudo sed -i "s/#VERBOSE=no/VERBOSE=yes/" /etc/default/rcS # Then, after reboot, examine /var/log/upstart/mountall.log, the results of the filesystem check will be visible there. # If you also want the filesystem check to perform all repairs, make this change: sudo sed -i "s/#FSCKFIX=no/FSCKFIX=yes/" /etc/default/rcS Performing this myself I find the following on a 14.04 system: # cat /var/log/upstart/mountall.log fsck from util-linux 2.20.1 /dev/vda1: clean, 248966/3670016 files, 2280909/14679040 blocks fsck from util-linux 2.20.1 e2fsck 1.42.9 (4-Feb-2014) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/vda1: 248988/3670016 files (0.2% non-contiguous), 2281324/14679040 blocks Be sure to note the number sign that has been added in the 14.04 config file - the two sed commands are not interchangeable. Also as per Adam, on 16.04 the /forcefsck functionality is not available, so the recommended method of triggering a filesystem check on boot is to use tune2fs, as this method will work on 12.04, 14.04 and 16.04: sudo tune2fs -CCOUNT DEVICE Setting the count to 1 will cause an fsck on each reboot, while -1 disables the scan. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mountall in Ubuntu. https://bugs.launchpad.net/bugs/513644 Title: Does not log fsck invocations in /var/log/fsck/ Status in mountall package in Ubuntu: Triaged Bug description: Binary package hint: mountall This concerns mountall 1.0 in Karmic. After fsck is invoked at boot time, the two log files in /var/log/fsck/ remain empty. In Jaunty, the /etc/init.d/check{fs,root}.sh scripts saved the output of the commands to that directory ("A log is being saved in ${FSCK_LOGFILE} if that location is writable") but mountall has yet to do this. As this would have to be newly implemented, I'd like to request a slight change from the Jaunty behavior, and have entries be appended to the log files rather than the files being overwritten each time with the latest (single) entry. Log rotation on these files may be good, too, although I'm not sure which package would/should be responsible for that. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/513644/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
