On 04/08/2015 09:05 PM, Ben Hutchings wrote:
Control: tag -1 unreproducible
On Thu, 12 Mar 2015 10:25:34 -0400 jpw <jap...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
