Filesystem with last mount time in the 'future' halts boot with little help for user

Bug #510403 reported by Ryan Haigh
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: util-linux

I installed ubuntu 9.04 (since upgraded to 9.10) on my friends computer. Yesterday he called because his computer wouldn't boot since his brother had turned the computer off at the wall. I recognized this scenario from other experiences with some of my older computers, the hardware clock had been reset because the cmos battery was dead.

When I was checking his system I noted that the error message wasn't particularly helpful, from what I can recall (not sure if I can reproduce in a VM) the 'last mounted in future' part was not visible. Changing the grub entry by removing 'splash' allowed me to see the full error message and confirm my suspicions. I then went on to run fsck -y /dev/sdxx (ext3) which repaired the problem and allowed the system to boot.

I have encountered this scenario on a number of occasions and while I am able to recognize the problem and implement the fix, 'average users' may not, particularly considering that the best indication of the specific error is hidden due to the splash. I think this could be improved by either of the following:

* Ensure that the relevant error message, and perhaps simple instructions for repair are visible to the user when the error occurs. This may mean asking them to run fsck and reboot or check there hardware clock, both of which may be to technical a task for 'the average user'
* Modify the behavior of the system such that this error is automatically repaired rather than forcing the user to repair the problem. The quote below is from a debian forums post here: http://forums.debian.net/viewtopic.php?f=10&t=45797#p261964
My only concern with this is whether the clock will be set correctly by the system once booted, is ntp support installed by default now?

QUOTE:
    "
    /etc/e2fsck.conf

    [problems]

    # Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
    0x000031 = {
        preen_ok = true
        preen_nomessage = true
    }

    # Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
    0x000032 = {
        preen_ok = true
        preen_nomessage = true
    }

This config then tells e2fsck that the superblock mount and write time issues are ok to be auto-fixed (preen_ok=true) and that I don't want to see e2fsck mentioning it (preen_nomessage=true). More info can be found in e2fsc.conf man page.

The numeric codes (0x000031, 0x000032) are not really in the man page, but you can find them in e2fsck sources (http://e2fsprogs.sourceforge.net/), specifically in e2fsck/super.c (usage) and e2fsck/problem.h (value definition)."

Revision history for this message
Sam Liddicott (sam-liddicott) wrote :

I'm having a similar problem on O2 Joggler hardware which does not have a hardware clock, and so the clock is ALWAYS wrong until after the network comes up and NTP can work.

Ubuntu Netbook Remix Lucid Beta 2 goes in an inifinite loop from mountall of trying to fsck the driver but failing with exit code 4.

I can edit /etc/init/mountall.conf to make it fsck first (hard wired) by why - there is nothing wrong with the disk, I don't want all the delay of fsck, I just want the e2fsck tools to realise that the superblock time being in the future doesn't always indicate something about the file system but often something about the hwclock, or lack of.

Revision history for this message
bassam (abdellatif-bassam) wrote :

I had this problem on my Dell inspiron 1525 operated with ubuntu 10.04. I found myself forced to change the coin cell battery, and I nearly destroyed my dell because this battery is too covered. The problem with THE LAST MOUNT TIME IN THE FUTURE remains (for one more time) and a FSCK had to be run manually. Searching on the internet, I found that I have to boot from a Live CD or USB. and to reboot in a recovery mode ..... But The SOLUTION WAS TOO SIMPLE as pressing one letter on the keyboard

the Solution was:

to press the F letter from the error message screen. This force FSCK to run manually ....

I am agree that the help message was not helpful .... It may be more helpful to indicate to the user to press F if he wants to run FSCK manually.

I hope this help for others

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in util-linux (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.