Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #175009 > unrolled thread

forcefsck inconsistency

Back to article view | Back to linux.debian.user

Contents

  forcefsck inconsistency Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2016-11-22 20:00 +0100
    Re: forcefsck inconsistency David Wright <deblis@lionunicorn.co.uk> - 2016-11-22 20:50 +0100
      Re: forcefsck inconsistency Pierre Frenkiel <pierre.frenkiel@gmx.com> - 2016-11-22 23:50 +0100
        Re: forcefsck inconsistency David Wright <deblis@lionunicorn.co.uk> - 2016-11-23 20:10 +0100
          Re: forcefsck inconsistency Pierre Frenkiel <pierre.frenkiel@gmx.com> - 2016-11-26 10:30 +0100
            Re: forcefsck inconsistency Richard Hector <richard@walnut.gen.nz> - 2016-11-28 14:20 +0100
              Re: forcefsck inconsistency Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2016-11-28 14:30 +0100
              Re: forcefsck inconsistency Michael Biebl <biebl@debian.org> - 2016-11-28 14:50 +0100
                Re: forcefsck inconsistency Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2016-11-28 15:20 +0100
                  Re: forcefsck inconsistency Michael Biebl <biebl@debian.org> - 2016-11-28 18:10 +0100
                    Re: forcefsck inconsistency Pierre Frenkiel <pierre.frenkiel@gmx.com> - 2016-11-28 20:00 +0100
                      Re: forcefsck inconsistency Michael Biebl <biebl@debian.org> - 2016-11-29 00:20 +0100
                        Re: forcefsck inconsistency Pierre Frenkiel <pierre.frenkiel@gmail.com> - 2016-11-29 08:50 +0100
                          Re: forcefsck inconsistency Michael Biebl <biebl@debian.org> - 2016-11-29 12:40 +0100
                            Re: forcefsck inconsistency Pierre Frenkiel <pierre.frenkiel@gmx.com> - 2016-11-29 13:50 +0100

#175009 — forcefsck inconsistency

hi everybody,
trying to force the exec of fsck at boot, I found in init.d/checkfs.sh:

       if [ -f /forcefsck ] || grep -q -s -w -i "forcefsck" /proc/cmdline
 		then
 			force="-f"
 		else
 			force=""
 		fi

So, I typed "touch /forcefsck", and rebooted.
This gave me several strange (IMHO) things

1/  fsck was run on 3 of my 5 ext4 partitions
     but not on / (which actually has fs_passno=1)
     and not for the 5th partition ,/dev/sdg1, which has fs_passno=2.
     I have in syslog:

      "EXT4-fs (sdg1): warning: maximal mount count reached, running e2fsck is recommended"

2/ I have in syslog:

    "systemd-fsck[2553]: Please pass 'fsck.mode=force' on the kernel
     command line rather than creating /forcefsck on the root file system."

    Does that mean that the guys working on checkfs.sh and systemd-fsck don't
    communicate?
    Anyway, I also tried this method, which gave me the same results.

    A workaround would be to boot with a live cd, and run fsck manually, but is
    there an easier solution?

best regards,
-- 
Pierre Frenkiel

[toc] | [next] | [standalone]

#175010

On Tue 22 Nov 2016 at 19:50:50 (+0100), Pierre Frenkiel wrote:
> trying to force the exec of fsck at boot, I found in init.d/checkfs.sh:
> 
>       if [ -f /forcefsck ] || grep -q -s -w -i "forcefsck" /proc/cmdline
> 		then
> 			force="-f"
> 		else
> 			force=""
> 		fi
> 
> So, I typed "touch /forcefsck", and rebooted.
> This gave me several strange (IMHO) things
> 
> 1/  fsck was run on 3 of my 5 ext4 partitions
>     but not on / (which actually has fs_passno=1)
>     and not for the 5th partition ,/dev/sdg1, which has fs_passno=2.
>     I have in syslog:
> 
>      "EXT4-fs (sdg1): warning: maximal mount count reached, running e2fsck is recommended"
> 
> 2/ I have in syslog:
> 
>    "systemd-fsck[2553]: Please pass 'fsck.mode=force' on the kernel
>     command line rather than creating /forcefsck on the root file system."
> 
>    Does that mean that the guys working on checkfs.sh and systemd-fsck don't
>    communicate?
>    Anyway, I also tried this method, which gave me the same results.
> 
>    A workaround would be to boot with a live cd, and run fsck manually, but is
>    there an easier solution?

Some things got a bit out-of-date perhaps. What works is to edit the
linux line in grub, adding

forcefsck

This gets processed by scripts in the initrd.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#175016

On Tue, 22 Nov 2016, David Wright wrote:

> Some things got a bit out-of-date perhaps. What works is to edit the
> linux line in grub, adding

   Hi David,
   It would be interesting to know which one is out-of-date, checkfs.sh or systemd-fsck?
   Anyway, my question was not "how to force fsck". This can be done either with
   "touch /forecfsck" which gives warnings, but does not prevent fsck to run.
   or
   at boot, edit the command line, adding "fsck.mode=force"
   both methods have the advantage that the force mode is removed after the boot.

   My question is: why fsck does not process the 2 partitions / and /dev/sdg1 ?

cheers,
-- 
Pierre Frenkiel

[toc] | [prev] | [next] | [standalone]

#175038

On Tue 22 Nov 2016 at 23:32:34 (+0100), Pierre Frenkiel wrote:
> On Tue, 22 Nov 2016, David Wright wrote:
> 
> >Some things got a bit out-of-date perhaps. What works is to edit the
> >linux line in grub, adding [forcefsck]

>   It would be interesting to know which one is out-of-date, checkfs.sh or systemd-fsck?
>   Anyway, my question was not "how to force fsck". This can be done either with
>   "touch /forecfsck" which gives warnings, but does not prevent fsck to run.
>   or
>   at boot, edit the command line, adding "fsck.mode=force"
>   both methods have the advantage that the force mode is removed after the boot.
> 
>   My question is: why fsck does not process the 2 partitions / and /dev/sdg1 ?

I don't know what the issue is with /dev/sdg1. I do know that
/etc/fstab needs to be more sane than used to be the case. Although
man fstab says that it is scanned and acted upon sequentially, that
appears no longer to be so: later bad entries can affect earlier ones.

As for the root filesystem, are you saying that it was not checked
even when you did what I suggested? What does
# tune2fs -l /dev/sda1 | grep 'st ch'
show (assuming / is /dev/sda1)?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#175082

[Multipart message — attachments visible in raw view] — view raw

On Wed, 23 Nov 2016, David Wright wrote:

> As for the root filesystem, are you saying that it was not checked
> even when you did what I suggested? What does
> # tune2fs -l /dev/sda1 | grep 'st ch'
> show (assuming / is /dev/sda1)?
>

   hi David,
   I said "inconsistency, but I must add "behaviour impossible to understand":

   1/
      According the tune2fs output, the check on / was actually done.
      I naïvely looked at syslog to find the checked devices, and I could  not imagine
      that the fsck checks are reported in syslog for all partitions, but not for /...

   2/
      An other strange behaviour. For my /dev/sda3 ext4 partition, I get:
      in syslog
          Nov 26 07:53:37 pfr2 systemd[1]: Started File System Check on /dev/sda3.
      with ->>tune2fs -l /dev/sda3 | grep 'st ch'
          Last checked:             Wed Nov 23 11:35:43 2016

   3/
     for the /dev/sdg1 partition for which no check was done at boot, I tried
     manually, but that didn't work. I then decided to recreate it (it was just
     a backup):
        - delete all partitions on /dev/sdg
        - add a Linux partition
        - run mkfs.ext4
     After that, the "Maximum mount count" was -1. Is this normal?
     I then set it to 30, and the behaviour is half normal: the fsck check is not
     done at boot, but I can do it manually. I imagine that it's a specific feature of
     this Seagate model.

cheers,
-- 
Pierre Frenkiel

[toc] | [prev] | [next] | [standalone]

#175154

[Multipart message — attachments visible in raw view] — view raw

On 26/11/16 22:03, Pierre Frenkiel wrote:
>      According the tune2fs output, the check on / was actually done.
>      I naïvely looked at syslog to find the checked devices, and I
> could  not imagine
>      that the fsck checks are reported in syslog for all partitions, but
> not for /...

Because / was mounted read-only while being checked, so syslog couldn't
be written, perhaps?

Richard

[toc] | [prev] | [next] | [standalone]

#175155

[Multipart message — attachments visible in raw view] — view raw

On Tue, 29 Nov 2016, Richard Hector wrote:

> On 26/11/16 22:03, Pierre Frenkiel wrote:
>>      According the tune2fs output, the check on / was actually done.
>>      I naïvely looked at syslog to find the checked devices, and I
>> could  not imagine
>>      that the fsck checks are reported in syslog for all partitions, but
>> not for /...
>
> Because / was mounted read-only while being checked, so syslog couldn't
> be written, perhaps?
>
> Richard
>

   hi Richard,
   you are probably right, but I imagine that the available space in memory
   should allow the kernel to store a few lines there, until / is
   re-mounted rw

best regards,
-- 
Pierre Frenkiel

[toc] | [prev] | [next] | [standalone]

#175158

[Multipart message — attachments visible in raw view] — view raw

Am 28.11.2016 um 14:11 schrieb Richard Hector:
> On 26/11/16 22:03, Pierre Frenkiel wrote:
>>      According the tune2fs output, the check on / was actually done.
>>      I naïvely looked at syslog to find the checked devices, and I
>> could  not imagine
>>      that the fsck checks are reported in syslog for all partitions, but
>> not for /...
> 
> Because / was mounted read-only while being checked, so syslog couldn't
> be written, perhaps?

/ and /usr are fscked by the initramfs.
Assuming you use initramfs-tools, which is the default in Debian, you
can find the log files at
/run/initramfs/fsck*


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#175159

On Mon, 28 Nov 2016, Michael Biebl wrote:

> / and /usr are fscked by the initramfs.
> Assuming you use initramfs-tools, which is the default in Debian, you
> can find the log files at
> /run/initramfs/fsck*
>
>

  thank you for this usefull information, but some inconsistency remains:

in /run/initramfs/fsck.log, I find:

      Log of fsck -C -a -V -t ext4 /dev/sda2
      Sat Nov 26 06:53:12 2016

      fsck from util-linux 2.25.2
      [/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2
      /dev/sda2: clean, 424229/1679360 files, 3245606/6704384 blocks

      Sat Nov 26 06:53:13 2016
      ----------------

and tune2fs -l /dev/sda2 gives:

     Last checked:             Fri Nov 25 22:45:38 2016

and on an other PC, the difference is much bigger (24/10/2016 and 17/11/2016)

as for fsck-root, it is empty on both.

best regards,
-- 
Pierre Frenkiel

[toc] | [prev] | [next] | [standalone]

#175176

[Multipart message — attachments visible in raw view] — view raw

Am 28.11.2016 um 15:10 schrieb Pierre Frenkiel:
> On Mon, 28 Nov 2016, Michael Biebl wrote:

>  thank you for this usefull information, but some inconsistency remains:
> 
> in /run/initramfs/fsck.log, I find:
> 
>      Log of fsck -C -a -V -t ext4 /dev/sda2
>      Sat Nov 26 06:53:12 2016
> 
>      fsck from util-linux 2.25.2
>      [/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2
>      /dev/sda2: clean, 424229/1679360 files, 3245606/6704384 blocks
> 
>      Sat Nov 26 06:53:13 2016
>      ----------------
> 
> and tune2fs -l /dev/sda2 gives:
> 
>     Last checked:             Fri Nov 25 22:45:38 2016
> 
> and on an other PC, the difference is much bigger (24/10/2016 and
> 17/11/2016)
> 
> as for fsck-root, it is empty on both.

Oh, this is quite simple to explain.
If your file system is clean, fsck will simply do nothing.

The "Last checked" attribute is only reset, if fsck is actually run due to
1/ unclean file system
2/ forced fsck (fsck.mode=force on the kernel command line)
3/ max mount count or check interval reached.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#175191

On Mon, 28 Nov 2016, Michael Biebl wrote:

> Oh, this is quite simple to explain.
> If your file system is clean, fsck will simply do nothing.
>
> The "Last checked" attribute is only reset, if fsck is actually run due to
> 1/ unclean file system
> 2/ forced fsck (fsck.mode=force on the kernel command line)
> 3/ max mount count or check interval reached.
>
  that's clear now, but was not really obvious: syslog tells when fsck is
  launched, and tune2fs when it did something. I checked that it's true
  not only for /, but for other partitions too.
  It seems that one must not be too curious, as each time you dig too
  deep, you find some kind of mystery. Last example: looking at syslog, I
  found some sequences repeated 10 to 12 times in 1 minute, like:

      Mounted /d2.
      Mounted /d5.
      Mounted /d3.
      Mounted /we.
      Mounted /data.
      Mounted /.
      Mounted /w.
or
     Started File System Check on /dev/sda3.
     Started File System Check on /dev/disk/by-uuid/70d8e3f7-010d-4a11-b265-5727509735ed.
     Started File System Check on /dev/disk/by-uuid/60c4562b-9c8f-4e82-ae58-2db298bc0a43.
     Starting File System Check on /dev/disk/by-uuid/9abca58e-191a-4894-98cf-a87e59569038...
     Started File System Check on /dev/disk/by-uuid/9abca58e-191a-4894-98cf-a87e59569038.

best regards,
-- 
Pierre Frenkiel

[toc] | [prev] | [next] | [standalone]

#175206

[Multipart message — attachments visible in raw view] — view raw

Am 28.11.2016 um 19:35 schrieb Pierre Frenkiel:
>  It seems that one must not be too curious, as each time you dig too
>  deep, you find some kind of mystery.

On the contrary, I think this is what makes Linux great. There might be
things which are a mystery to you at first, but you are allowed to look
behind the curtain.

It's certainly one reason why I love Linux. I can take it apart and go
as deep as I want.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#175210

On Tue, 29 Nov 2016, Michael Biebl wrote:

> Am 28.11.2016 um 19:35 schrieb Pierre Frenkiel:
>>  It seems that one must not be too curious, as each time you dig too
>>  deep, you find some kind of mystery.
>
> On the contrary, I think this is what makes Linux great. There might be
> things which are a mystery to you at first, but you are allowed to look
> behind the curtain.
>
> It's certainly one reason why I love Linux. I can take it apart and go
> as deep as I want.

   I don't disagree. When you go deeper and are lost, you often find
   some people which can explain what seems a mystery to you, but you
   must be prepared to spend some time....
   For example, how do you explain the presence in syslog of 12 times
   the same 12 lines?

cheers,
-- 
Pierre Frenkiel

[toc] | [prev] | [next] | [standalone]

#175213

[Multipart message — attachments visible in raw view] — view raw

Am 29.11.2016 um 08:40 schrieb Pierre Frenkiel:
>   For example, how do you explain the presence in syslog of 12 times
>   the same 12 lines?

The lines you posted are not the same. They are for different mount points.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#175219

On Tue, 29 Nov 2016, Michael Biebl wrote:

> Am 29.11.2016 um 08:40 schrieb Pierre Frenkiel:
>>   For example, how do you explain the presence in syslog of 12 times
>>   the same 12 lines?
>
> The lines you posted are not the same. They are for different mount points.
>
>
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>
  sorry, but missed what I wrote yesterday:
"some sequuences repeated 10 to 12 times", and not "somes lines"!
I thoought it would not be a good idea
to post the actual 144 lines...
cheers,
Pierre Frenkiel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web