[Bug 432237] Re: difficult to recover from filesystem errors

[Scott James Remnant]

On Fri, 2009-10-09 at 13:45 +0000, Dave Martin wrote:

> However, I still have a couple of issues:
> 
> 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.

At the same time, we have had bugs in the past with the system and
hardware clock in Ubuntu being inconsistent - so we've wanted the hard
error to collect the bug reports.


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

> The novice user may not have a
> good idea what to type in the maintenenace shell anyway.  The problem
> will persist across boot until the system is sufficiently convinced to
> mount the fs read-write  My suggestion would be that if the only
> apparent error with the root filesystem is that it was mounted in the
> future, boot should proceed, although a warning is appropriate.  This
> appears to have been the Jaunty behaviour.
> 
Indeed, but sadly for the wrong reasons.

You can get the jaunty behaviour by creating an /etc/e2fsck.conf file
with the contents:

	[options]
	buggy_init_scripts = 1

(see what I mean about political? <g>)

> 2) If the mountall-shell exits with non-zero exit status, boot does not
> resume:
> 
> init: mountall-shell main process (749) terminated with status 1
> <...hang...>
> 
>  This is unlikely to be appropriate: the default exit status of a shell
> is simply the exit status of the last command executed... which was not
> necessarily fsck. I believe fsck can exit with non-zero status 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.

Scott
-- 
Scott James Remnant
scott at ubuntu.com

-- 
difficult to recover from filesystem errors
https://bugs.launchpad.net/bugs/432237
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs