boot-time fsck details

English Install/Boot/Login
#1

Hi, When a filesystem is flagged dirty, does the automatic filesystem recovery at boot time do an actual fsck, or is it just a journal playback?

If it does an actual fsck, does it run it in repair mode, instead of just diagnostic mode?

There is just not enough detail in /var/log/boot.msg to answer these questions.

If the answers depend on OS/kernel version, the questions surely apply to latest of such, but also possibly to 11.4 and kernel 2.6.x (all versions in between are unimportant).

Thank you

#2

On 2014-07-07 07:16, skosner wrote:
>
> Hi, When a filesystem is flagged dirty, does the automatic filesystem
> recovery at boot time do an actual fsck, or is it just a journal
> playback?

That’s more or less up to that particular filesystem designers. Which is
to say, it varies.

For instance, for XFS you need to attempt a mount first to replay the
log, and only then a repair works.

> If it does an actual fsck, does it run it in repair mode, instead of
> just diagnostic mode?

The idea is to do an automated diagnostic and repair. If it needs manual
intervention, aborts and dumps you in emergency mode.

> There is just not enough detail in /var/log/boot.msg to answer these
> questions.

Because that file is deprecated, systemd doesn’t write it (it is filled
by plymouth, if used). The real log is in “/var/log/messages”.

> If the answers depend on OS/kernel version, the questions surely apply
> to latest of such, but also possibly to 11.4 and kernel 2.6.x (all
> versions in between are unimportant).

Ah, 11.4.

That one is the last fully system V version, so, yes, it does support
/var/log/boot.msg, and no, it does not write anything about the disk
check in there. Only on the display.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#3

Thanks for your response.

That’s more or less up to that particular filesystem designers. Which is
to say, it varies.

For instance, for XFS you need to attempt a mount first to replay the
log, and only then a repair works.

Filesystem is ext4, though it can be a normal partition, or one contained within a luks encrypted container. We can assume that a mount will be attempted.

The idea is to do an automated diagnostic and repair. If it needs manual
intervention, aborts and dumps you in emergency mode.

Does this always (or almost) apply if a particular filesystem does a true fsck at boot-time? Does it apply to ext4?

Thank you

#4

When I see an “fsck” (which is rare) on “ext4”, it is always reporting “recovering from journal”, followed by a note that the file system is clean. And yes, for me, that is usually within an encrypted LVM.

For example, if my laptop freezes (seems to be a video problem with Intel), and I force a power off, I will usually see:

  • Recovering from journal (for the root file system “ext4”);
  • Normal “fsck” (freeing inodes and other messages) for “/boot” which uses “ext2”;
  • Recovering from journal (for “/home” file system “ext4”).
#5

On 2014-07-07 18:46, skosner wrote:

>> The idea is to do an automated diagnostic and repair. If it needs manual
>> intervention, aborts and dumps you in emergency mode.
>
> Does this always (or almost) apply if a particular filesystem does a
> true fsck at boot-time? Does it apply to ext4?

If I recall correctly, ext4 only does a quick test. Log replay is
mandatory, of course, when it ends the filesystem must be mountable.

On occasion, fsck failed to notice some problems, and I had to do a
manual test on my own. Let me see… I think this has happened to me
with reiserfs and ext4.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#6

Ok, so it sounds like in the experiences for each of you, only a journal playback is performed for ext4.
This information is helpful and appreciated.

Thank you very much