Comment 43 for bug 432237

> > 1) A "filesystem last mounted in future" error is still treated as
> > serious enough to interrupt the boot process and require
> interaction
> > via mountall-shell. My view is that this is not appopriate because
> > this may well happen when Windows fiddles with the clock on a
> > dual-boot system, or when there's some other RTC problem.
> >
> The filesystem upstream author disagrees unfortunately; which
> is why that error is there. Apparently the inconsistency
> causes problems for journalled filesystems.
>
> Now, you might say that this is one of those errors that fsck
> -a should fix automatically - but this issue has become a bit
> politically charged and the ext3/4 upstream is currently
> holding out having it a boot-critical error.

OK... I don't know enough about the fs design to comment, but it sounds plausible.

Would it be possible simply to do a full filesystem check instead of the maintenance shell? I can foresee problems with portable devices where the console text console is not easily to access or use. If the full fs check fails, then dropping to a shell is more appropriate.

This will slow down boot in most circumstances when RTC problems occur, rather than exploding every time.

[...]

> For the Windows case - the hardware clock is in localtime,
> and our installer automatically sets that up when it detects
> the partition.

OK, fair enough. Otherwise, it seemed a good argument :)

>
> You can get the jaunty behaviour by creating an
> /etc/e2fsck.conf file with the contents:
>
> [options]
> buggy_init_scripts = 1
>

If there's a workaround that may be good enough for me. Is this documented somewhere? Otherwise, I'd have no clue to enable this option to work around a buggy RTC :)

[...]

> > for various non-fatal situations anyway? It's necessary to
> quit the
> > shell with "exit 0" to work around this... again, the
> novice user will
> > have no clue about that.
> >
> Good catch, I've committed a fix for that.

OK, thanks. I'll try it... is it in the PPA?