cannot boot - superblock last mount time is in the future

[kavol]

After running out of the battery, the system time got reset. The automatic synchronisation got screwed somehow, so I've run ntp client manually. After rebooting the phone, I cannot boot any more because the boot process hangs on fsck, asking for root password - which I cannot provide via touchscreen ...

In fact, there are two problems:

1. fsck Y2K bug

2. that fsck considers this thing a blocking issue - it is really nothing unusual that the system time gets moved to the past; e.g. you make a mistake when entering the date, you realise it the other day and set correct time ... kaboom, device unusable just because of trivial typo in unimportant command? seriously?

[kavol]

http://imageshack.us/photo/my-images/692/p1020769a.jpg/

[radekp]

Well your filesystem is corrupted. If your filesystem would be ok, then regular automatic fsck would proceed. You can try boot from NAND and repair the filesystem manually as the text suggest. I dont think this is QtMoko issue, so closing the bug report.

[kavol]

Well your filesystem is corrupted.

well, would you be so kind to point out exactly in which way the filesystem is corrupted?

If your filesystem would be ok, then regular automatic fsck would proceed.

well, IMO this is false, correct statement would be "If there is no Y2K bug in fsk then regular automatic fsck would proceed."

You can try boot from NAND and repair the filesystem manually as the text suggest.

pardon my ignorance, but are we reading the same text?

I do not see any mention of booting from NAND ...

I dont think this is QtMoko issue, so closing the bug report.

then I have no other option then to ask you to rethink

this is clearly a bug

fsck states that the last mount time is Sun Nov 26 05:18:17 1933 and that the current date is Mon Oct 1 18:18:46 2012 - but the year 1933 is not in the future for the year 2012 for sure

as fsck is not developed within this project, you may pass this to the upstream project instead of fixing it yourself, but in that case it is a good habit to keep the downstream bug report open until upstream fixes the problem and the fix reaches the downstream release

also, the second point is a good RFE material (if not considered a bug) for QtMoko which would justify not closing this - well, maybe you, as a developer and a person willing to play and spend hours of time in vain with your electronic toys see it differently, but believe me that I, as an ordinary user, really do not like the idea of having to reflash the phone or do another magic just because of clock change

[radekp]

Well if we want to continue, at least provide some basic info: which hardware is this (Freerunner/GTA04), what type of filesystem is this (ext2, ext3, ext4...).

Sorry to be repeating myself, but can you try booting from NAND and try to mount/fsck the filesystem?

[kavol]

just FTR, having the following set in the default distro config would probably workaround the issue

but I don't care anymore, this was the last drop of developer ineptness that made me switch from Freerunner (with all its unusable distros ranging from Om2007 to QtMoko) to Samsung dumbphone then to SE with Android (CM)

man e2fsck.conf -

   broken_system_clock
          The e2fsck(8) program has some heuristics that assume that the system clock is correct.  In addition, many system programs make similar assumptions.  For example, the UUID library depends on time not  going  backwards
          in  order  for  it  to  be  able to make its guarantees about issuing universally unique ID's.  Systems with broken system clocks, are well, broken.  However, broken system clocks, particularly in embedded systems, do
          exist.  E2fsck will attempt to use heuristics to determine if the time can not be trusted; and to skip time-based checks if this is true.  If this boolean is set to true, then e2fsck will always assume that the system
          clock can not be trusted.

[kavol]

just FTR, having the following set in the default distro config would probably workaround the issue

but I don't care anymore, this was the last drop of developer ineptness that made me switch from Freerunner (with all its unusable distros ranging from Om2007 to QtMoko) to Samsung dumbphone then to SE with Android (CM)

man e2fsck.conf -

   broken_system_clock
          The e2fsck(8) program has some heuristics that assume that the system clock is correct.  In addition, many system programs make similar assumptions.  For example, the UUID library depends on time not  going  backwards
          in  order  for  it  to  be  able to make its guarantees about issuing universally unique ID's.  Systems with broken system clocks, are well, broken.  However, broken system clocks, particularly in embedded systems, do
          exist.  E2fsck will attempt to use heuristics to determine if the time can not be trusted; and to skip time-based checks if this is true.  If this boolean is set to true, then e2fsck will always assume that the system
          clock can not be trusted.

[radekp]

I'd rather say this is reporter's ineptness. You havent provided basic information and instead you are copy pasting here e2fsck manual pages. I was suggesting to boot from NAND and run fsck manually. You didnt do it. You even havent told us which filesystem it is (ex2, ext3, ext4?). From my experience i know that filesystem on SD cards sometimes corrupt - if you want stable phone boot from NAND. Now what you expect from me to do? If you want the problem get fixed then cooperate. If not go trolling somewhere else.

[radekp]

Btw i have now checked your theory about "need to reflash because of wrong time" and it's not true. On NAND fsck is disabled in fstab. On ext3 i booted with year 2000, changed time to 2013 and rebooted. Fsck was launched - same way as on your screenshot and passed without errors the phone booted. So again - your SD card is corrupted.