[SOLVED] Where is boot-time fsck output logged, after /forcefsck?

NewWorld · 2013-06-16 20:47:00

Hello,

Title says it all. I want to see if any filesystem errors were fixed, fragmentation of the partition, etc.

I can't find anything in /var/log/fsck (this dir doesn't exist). Grepping `journalctl` for "fsck" doesn't yield the fsck results either.

Thank you in advance.

Last edited by NewWorld (2013-06-17 16:11:26)

WonderWoofy · 2013-06-16 22:30:26

Really, grepping for fsck yields nothing? I get something... what is the command you are using? I used "journalctl -b --no-pager | grep fsck" and I can see the systemd-fsck service that runs on my /boot (EFI System Partition) every boot.

The thing is that unlike SysV/initscripts, systemd fsck's the fsck'able filesystems on every boot. Additionally, if you have the fsck hook added to your mkinitcpio.conf, then your root filesystem will be fscked before being mounted, thus making it fixable without requiring read-only mounting or the reboot when inconsistencies are detected. I don't know that the /forcefsck is really doing anything with systemd.

NewWorld · 2013-06-17 08:52:56

WonderWoofy wrote:

Really, grepping for fsck yields nothing? I get something... what is the command you are using? I used "journalctl -b --no-pager | grep fsck" and I can see the systemd-fsck service that runs on my /boot (EFI System Partition) every boot.
The thing is that unlike SysV/initscripts, systemd fsck's the fsck'able filesystems on every boot. Additionally, if you have the fsck hook added to your mkinitcpio.conf, then your root filesystem will be fscked before being mounted, thus making it fixable without requiring read-only mounting or the reboot when inconsistencies are detected. I don't know that the /forcefsck is really doing anything with systemd.

You're right `touch`ing /forcefsck didn't invoke boot-time fsck-check (strange). So I had to add the kernel parameter: "fsck.mode=force", in order to check my root partition. Immediatly after the check I ran:

# journalctl -b --no-pager | grep fsck

and still got no fsck output!

I can see the fsck message each time the OS boots, reporting info on the root partition. Something like:

/dev/sda6: clean, 123456/12345678 files, 123456/12345678 blocks

Yet this is not in the journal either!

Here is the output of `journalctl -b --no-pager` from the boot after I forced fsck.

The 'fsck' HOOK was already in /etc/mkinitcpio.conf

falconindy · 2013-06-17 11:16:09

It isn't logged to the journal precisely because you have the fsck hook in your initramfs.

NewWorld · 2013-06-17 13:34:24

falconindy wrote:

It isn't logged to the journal precisely because you have the fsck hook in your initramfs.

Aha! I removed the HOOK and rebuilt the initramfs image. Now `journalctl` shows some more output after I force fsck boot-time check:

Jun 17 14:14:07 myarch systemd-fsck[108]: /dev/sda6: 381295/7610368 files (18.4% non-contiguous), 29173582/30439150 blocks

At boot time, it spits out the above line as soon as it's finished with the FS check.

But that's still very terse. Is it not showing more details because the FS is totally clean and nothing needed to be fixed?

I've noticed that other distros have a full log in /var/log/fsck/checkfs . I tried creating dir, "/var/log/fsck" but, still, nothing was written there.

falconindy · 2013-06-17 13:47:35

NewWorld wrote:

falconindy wrote:
It isn't logged to the journal precisely because you have the fsck hook in your initramfs.
Aha! I removed the HOOK and rebuilt the initramfs image. Now `journalctl` shows some more output after I force fsck boot-time check:
Jun 17 14:14:07 myarch systemd-fsck[108]: /dev/sda6: 381295/7610368 files (18.4% non-contiguous), 29173582/30439150 blocks
At boot time, it spits out the above line as soon as it's finished with the FS check.

Note that you don't actually want to remove this hook... fsck'ing the device before it's mounted is far better than fsck'ing it while it's mounted.

NewWorld wrote:

But that's still very terse. Is it not showing more details because the FS is totally clean and nothing needed to be fixed?

Right. It's clean, so nothing was done.

NewWorld wrote:

I've noticed that other distros have a full log in /var/log/fsck/checkfs . I tried creating dir, "/var/log/fsck" but, still, nothing was written there.

That's what other distros do. Arch isn't other distros.

All this said, future versions of mkinitcpio will log early userspace to kmsg.

NewWorld · 2013-06-17 14:16:12

falconindy wrote:

NewWorld wrote:
falconindy wrote:
It isn't logged to the journal precisely because you have the fsck hook in your initramfs.
Aha! I removed the HOOK and rebuilt the initramfs image. Now `journalctl` shows some more output after I force fsck boot-time check:
Jun 17 14:14:07 myarch systemd-fsck[108]: /dev/sda6: 381295/7610368 files (18.4% non-contiguous), 29173582/30439150 blocks
At boot time, it spits out the above line as soon as it's finished with the FS check.
Note that you don't actually want to remove this hook... fsck'ing the device before it's mounted is far better than fsck'ing it while it's mounted.

falconindy wrote:

All this said, future versions of mkinitcpio will log early userspace to kmsg.

That makes sense, but then, with the hook in place, how can I get a log of the fsck check (to see what errors were fixed, etc.)? Do I have to wait for this new version of mkinitcpio that will show this log in `dmesg`?

falconindy · 2013-06-17 14:33:08

NewWorld wrote:

That makes sense, but then, with the hook in place, how can I get a log of the fsck check (to see what errors were fixed, etc.)?

Currently, you can't.

WonderWoofy · 2013-06-17 14:59:09

From reading this, I take it that you have a single partition for your entire system. If this is the case, then that is why nothing is showing up in your journal. As falconindy mentioned above if it is taken care of in ithe intiramfs, it does not need to be done by systemd once the filesystem has been mounted and switch root happens.

Interestingly, despite the fact that I mentioned that the system is fsck'ed on every boot, and that the fsck hook will fsck the root filesystem on every boot, you continued to try to "force" fsck. I'm really not entirely sure why you were so set on trying to force something that was already happening...

NewWorld · 2013-06-17 15:05:12

falconindy wrote:

NewWorld wrote:
That makes sense, but then, with the hook in place, how can I get a log of the fsck check (to see what errors were fixed, etc.)?
Currently, you can't.

That's too bad. I guess I'll use a LiveCD whenever I want to check my root partition until mkinitcpio adds the feature.

Thanks for all the help, falconindy and WonderWoofy.

WonderWoofy wrote:

From reading this, I take it that you have a single partition for your entire system. If this is the case, then that is why nothing is showing up in your journal.

Yes, 1 partition, but swap on another partition.

WonderWoofy wrote:

As falconindy mentioned above if it is taken care of in ithe intiramfs, it does not need to be done by systemd once the filesystem has been mounted and switch root happens.
Interestingly, despite the fact that I mentioned that the system is fsck'ed on every boot, and that the fsck hook will fsck the root filesystem on every boot, you continued to try to "force" fsck. I'm really not entirely sure why you were so set on trying to force something that was already happening...

Well it doesn't scan the whole partition every boot unless I add kernel boot parameter, "fsck.mode=force" or wait until partition has been mounted XX number of times. Then it takes 10 mins scanning with that progress bar.

Last edited by NewWorld (2013-06-17 15:13:29)

falconindy · 2013-06-17 15:12:59

NewWorld wrote:

That's too bad. I guess I'll use a LiveCD whenever I want to check my root partition until mkinitcpio adds the feature.

I don't understand this at all. If you're watching bootup and it's fast enough that you can't see what happened, I assure you that fsck reported the filesystem as clean. In any other case, you'll see exactly what's happening.

Last edited by falconindy (2013-06-17 15:13:39)

WonderWoofy · 2013-06-17 15:18:19

The mkinitcpio fsck output is printed to the console. So although you can't get this "log" you are so fixated on, it will show up in tty1.

I'm really not sure why you would find it necessary to boot from a livecd every time you want to fsck your rootfs. It is doing it on boot if you have the fsck hook (and I think it will still do it with the systemd-fsck-root.service if you don't). It would seem that if you absolutely require that your rootfs fsck be logged to the journal, then simply allowing the use of systemd-fsck-root.service gives you exactly what you want. As long as it is clean, there are no real disadvantages to this.

NewWorld · 2013-06-17 16:11:04

falconindy wrote:

I don't understand this at all. If you're watching bootup and it's fast enough that you can't see what happened, I assure you that fsck reported the filesystem as clean. In any other case, you'll see exactly what's happening.

WonderWoofy wrote:

The mkinitcpio fsck output is printed to the console. So although you can't get this "log" you are so fixated on, it will show up in tty1.

Ahh there's the solution! I didn't know I could see the fsck output in tty1 once Arch finished booting. Thank you.

I was fixated on the log, because I didn't want to spend 10 mins staring at the screen in case fsck found any errors and to see the fragmentation level that it outputs at the end of the scan.

WonderWoofy wrote:

It would seem that if you absolutely require that your rootfs fsck be logged to the journal, then simply allowing the use of systemd-fsck-root.service gives you exactly what you want. As long as it is clean, there are no real disadvantages to this.

Hmm, systemctl says that "systemd-fsck-root.service" was enabled the whole time:

systemd-fsck-root.service loaded inactive dead File System Check on Root Device

I'm happy with the tty1 solution, but I'm curious what you mean by "as long as it is clean". What would be the problem if it wasn't clean?

falconindy · 2013-06-17 16:53:57

NewWorld wrote:

I'm happy with the tty1 solution, but I'm curious what you mean by "as long as it is clean". What would be the problem if it wasn't clean?

Well, fsck would tell you what's wrong... isn't that the point of what you're trying to do here?

Arch Linux

#1 2013-06-16 20:47:00

[SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#2 2013-06-16 22:30:26

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#3 2013-06-17 08:52:56

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#4 2013-06-17 11:16:09

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#5 2013-06-17 13:34:24

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#6 2013-06-17 13:47:35

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#7 2013-06-17 14:16:12

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#8 2013-06-17 14:33:08

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#9 2013-06-17 14:59:09

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#10 2013-06-17 15:05:12

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#11 2013-06-17 15:12:59

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#12 2013-06-17 15:18:19

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#13 2013-06-17 16:11:04

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

#14 2013-06-17 16:53:57

Re: [SOLVED] Where is boot-time fsck output logged, after /forcefsck?

Board footer