[arch-general] Unwanted forced fsck at each startup - Was: How do I _really_ fix the superblock?

[Leonid Isaev]

On Sat, Jun 07, 2014 at 10:34:12PM +0200, Ralf Mardorf wrote:
> Date: Sat, 07 Jun 2014 22:34:12 +0200
> From: Ralf Mardorf <ralf.mardorf at rocketmail.com>
> To: arch-general at archlinux.org
> Subject: Re: [arch-general] Unwanted forced fsck at each startup - Was: How
>  do I _really_ fix the superblock?
> X-Mailer: Evolution 3.12.2
> 
> On Sat, 2014-06-07 at 13:23 -0400, Leonid Isaev wrote:
> > That's actually interesting. Whether / will be fsck'ed or not depends
> > on your mkinitcpio hooks (fsck) and kernel cmdline. What are them? Do
> > you have "ro" in the cmdline?
> 
> The GRUB lines for my kernels all include 'ro'.
> 
> [rocketmouse at archlinux ~]$ grep HOOKS /etc/mkinitcpio.conf | grep -v "#"
> HOOKS="base udev autodetect modconf block filesystems keyboard fsck vboxhost"

So, your / is being checked twice on boot...

> 
> "1) Use the 'fsck' hook, use 'rw' on the kernel commandline.
> 2) Don't use the 'fsck' hook, use 'ro' on the kernel commandline." -
> https://bbs.archlinux.org/viewtopic.php?pid=1307895#p1307895
> 
> So I should remove fsck from the hooks?

Since you are seeing the fsck warning even after an extended downtime, I can
think of two possibilities:

1. The superblock mod time is _really_ wrong (like in 2020), that is OS does
something strange. You can check this by running "tune2fs -l" or dumpe2fs from
a live environment, possibly disabling your timesync tool for this one
experiment.

2. Something happens in between the two runs of fsck. I'd remove the fsck hook
to let systemd check the filesystems and see if that helps.

> If so, why didn't it cause the issue before the systemd update?
> 

I don't know.

> Regards,
> Ralf
> 
> Off-topic PS:
> > Just an advice: replace this with a continuously tunning ntpd or at
> > least with ntpd -q.
> 
> Is this useful for a DAW? Part of the audio tuning could be turning off
> Internet connections, but at least I will run as less services as
> possible. Ok, the -q "ntpd will not daemonize and will exit after the
> clock is first synchronized" seems to be something I could use.
> 

I meant "running", not "tunning". Also, I can only suspect what you mean by
DAW. Anyway, ntpd daemon can handle intermittent network access just fine...
Unless you have an extremely CPU/memory-constrained system, you really should
use the daemon IMHO because it offers continuous time synchronization, etc. 

-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
                  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140607/9b2e04dd/attachment.asc>