-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Theodore Tso schrieb:
> On Sun, Nov 15, 2009 at 10:34:33PM +0100, Eugeniy Meshcheryakov wrote:
>> Hello,
>>
>> Thanks for reply. This option will probably fix problem with systems
>> with clock set to local timezone, but not for systems like FreeRunner
>> where clock content is lost when battery is removed. It will be good to
>> have option that disables mount time in the future check entirely.
>
> Note that the file system isn't the only place that might assume that
> time is correct. For example, the UUID generation algorithm derives
> its uniqueness guarantees from the fact that time is correctly set.
> If you don't have an accurate clock, you may have all sorts of strange
> behavior as a result.
New UUIDs are not so often needed..
>
> As far as the FreeRunner is concerned, it currently takes me under 8
> seconds to check a 70gig SSD drive. If you put 8GB SD card into the
> FreeRunner smartphone, the first check after a failed battery should
> take at most a second. Hardly worth people going into hysterics and
> calling this a "grave" bug.
Yes those realy worth people care about such problems, because it *is* a
problem that the whole systems fails because of a wrong clock set!
And don't forget, there are also worth people on the earth who do not
answer first for 1 1/2 month on a report and then siilently downgrade
the bug without any comment.
And it isn't that I say "completly ignore it", I am happy with it if it
continues with the fsck then, but it should not simply fail and drop the
user to an maintenance shell, just because his/her laptop is for example
out of battery while it was running.
And it is also even bad if users do not know what to do now..
Don't understand me wrong, it is nice to see, that you answered and gave
so much possible workarounds and fixes, but that won't help any user who
knows how to install some basic software and working with an office
suite, they do not want to know why it failed, they want an running system.
>
> If you really want to disable the future check, you can do this:
>
> [problems]
> 0x000031 = {
> preen_ok = true
> }
> 0x000032 = {
> preen_ok = true
> }
>
> I consider this a botch to work around broken hardware, though...
>
> - Ted
- --
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: [email protected]
[email protected]
Comment:
Always if we think we are right,
we were maybe wrong.
*/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAksAfDcACgkQ2XA5inpabMfvhQCfaxdTfpW635iXlH2Si/M1gENo
dmQAn3+/fXuxnxu7CBG6F2Wd5MR5pOdD
=d+v/
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
