On 04/08/2015 09:05 PM, Ben Hutchings wrote:
Control: tag -1 unreproducible On Thu, 12 Mar 2015 10:25:34 -0400 jpw <japers@comcast.net> wrote:Package: initramfs-tools Version: 0.119 Severity: important Dear Maintainer, A basic change in function for fsck at boot time has resulted following upgrade of this package from 0.116 to 0.119. Following deprecation of "touch /forcefsck" earlier this past year for forcing fsck at next reboot I started using a line in rc.local (tune2fs -c 0 /dev/sda1) to set maximum mount count so that in-depth file system checks would never occur unless I specified. I then issued "tune2fs -c 1 /dev/sda1" from a root prompt on the remote systems to force the in-depth fsck on next reboot. The remote systems used to execute an in-depth fsck on the boot partition at next reboot when I followed this procedure. This function no longer works.[...] It works for me. However, the forced fsck is now done from the initramfs (for the root and /usr filesystems), not under systemd or initscripts. Is the real problem to do with logging the output of fsck? Ben.
Hi!I was trying to force the type of fsck which results in a report of the % of discontiguous files on remote systems that I maintain. In the spirit of avoiding the use of the deprecated "touch /forcefsck" I was using a line (tune2fs -c 0 /dev/sda1) in rc.local to cause the check to never run unless I issued "tune2fs -c 1 /dev/sda1" from a root prompt and then rebooted.
So when you say that "it" works for you, do you mean that "touch /forcefsck" still gets the check for file system fragmentation, or that using the tune2fs trick works. Because, for me, "touch /forcefsck" still works (but I'm trying to avoid it), but using the tune2fs trick stopped working when initramfs-tools was upgraded from 0.116 to 0.119.
By that, I mean that issuing "systemctl status -l systemd-fsck-root.service" stopped showing me % discontiguous following a reboot when I tried to run the full fsck check using the tune2fs command.
Now I am just using grub-reboot to make the system use a new entry I created in the grub boot menu which contains the mode.fsck=force command on the next reboot, and I get my report.
So I have a workaround to replace the previous workaround.If my bug report against initramfs-tools is invalid because initramfs is actually working as designed, I'm content to have the bug closed. But does the change in behavior mean, essentially, that maximum mount count is no longer a controller in determining whether or not the more extensive type of file system check is run at boot time?
Just curious. I'm trying to keep my rather vague conceptual structure about this as up-to-date as possible. It's an old brain, and there is no longer enough coffee in the world...
:-)And thank you for all the work you do. I see your name on a lot of changelogs and on many of the most useful posts on various lists!
Best regards, JP