# Hardware/System Clock are OK, "mount" uses wrong time SOLVED

## nagmat84

Hello,

after I set my system time due to the switch from winter to summer time, mount complains about a last mount time in the future or that my root partition has run for >10.000 days without being checked.

But everything seems fine so far. My BIOS reports the correct local time (CEST at the moment), and under Linux "date" as well as "hwclock --show" gives my the correct (local) time.

```

# /etc/conf.d/clock

# Set CLOCK to "UTC" if your system clock is set to UTC (also known as

# Greenwich Mean Time).  If your clock is set to the local time, then

# set CLOCK to "local".  Note that if you dual boot with Windows, then

# you should set it to "local".

CLOCK="local"

# Select the proper timezone.  For valid values, peek inside of the

# /usr/share/zoneinfo/ directory.  For example, some common values are

# "America/New_York" or "EST5EDT" or "Europe/Berlin".

TIMEZONE="Europe/Berlin"

# If you wish to pass any other arguments to hwclock during bootup,

# you may do so here.

CLOCK_OPTS=""

# If you want to set the Hardware Clock to the current System Time

# during shutdown, then say "yes" here.

CLOCK_SYSTOHC="no"

### ALPHA SPECIFIC OPTIONS ###

# If your alpha uses the SRM console, set this to "yes".

SRM="no"

# If your alpha uses the ARC console, set this to "yes".

ARC="no"

```

```

hek509 ~ # ls -l /etc/localtime

lrwxrwxrwx 1 root root 2295 2007-03-11 15:52 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin

```

But still the following happens:

```

hek509 ~ # date

Tue Mar 27 21:46:41 CEST 2007

hek509 ~ # date --utc

Tue Mar 27 19:46:45 UTC 2007

hek509 ~ # hwclock --show

Tue 27 Mar 2007 09:46:52 PM CEST  -0.813477 seconds

hek509 ~ # tune2fs -l /dev/sda3

tune2fs 1.39 (29-May-2006)

Filesystem volume name:   gentoo

Last mounted on:          <not available>

Filesystem UUID:          2f3a48a7-fae2-4bd0-9181-d6b822473808

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal ext_attr filetype needs_recovery sparse_super

Default mount options:    acl

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              7325696

Block count:              14651280

Reserved block count:     732564

Free blocks:              10840341

Free inodes:              6871472

First block:              0

Block size:               4096

Fragment size:            4096

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         16352

Inode blocks per group:   511

Filesystem created:       Fri Dec  8 19:04:14 2006

Last mount time:          Tue Mar 27 23:06:11 2007

Last write time:          Tue Mar 27 23:06:11 2007

Mount count:              1

Maximum mount count:      48

Last checked:             Tue Mar 27 23:01:24 2007

Check interval:           15552000 (6 months)

Next check after:         Sun Sep 23 23:01:24 2007

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               128

Journal inode:            8

First orphan inode:       1422671

Default directory hash:   tea

Directory Hash Seed:      f2b28fc1-a8ab-4158-8f8e-41b8320d90ef

Journal backup:           inode blocks

```

You see, the local time is 21:XX (both date and hwclock), UTC time is 19:XX, but the mount time is 23:XX (2 hours in the future). Why?

MatthiasLast edited by nagmat84 on Wed Mar 28, 2007 2:12 pm; edited 1 time in total

----------

## Kingmilo

Looks like your BIOS (HW Clock) is incorrect for one.

I would;

```
# emerge ntp

# etc-update add ntpd default

# /etc/init.d/ntpd start

# /etc/init.d/ntp-client start
```

Then restart, it might moan about "modification time in the future", but once it starts ntpd it will be fine  :Wink: 

----------

## NeddySeagoon

nagmat84,

Welcome to Gentoo.

If your system only uses Linux, your hardware clock should be set to UTC, then your timezone settings take care of everything else. This is how *NIX is supposed to work

When you dual boot with Windows, set your hardware clock (BIOS) to your local time and choose the local timezone.

This prevents Windows and Linux time systems from fighting over the the time.

----------

## zorth

hi all.

sorry but i dont speak english well  :Smile: 

i have the same problem in my gentoo receiving boot messages error about the system dont know when my partitions are mounted the last time. every start i see the errors talking about my gentoo advance in future, 4000 days of more without a check.

i stop now the ckecks filesystem pushing ctrl+d but i believe that is a bug. some strange happen here with this.

sorry again for my english. i hope you all understand me...   :Embarassed: 

regards

----------

## Kingmilo

 *zorth wrote:*   

> hi all.
> 
> sorry but i dont speak english well 
> 
> i have the same problem in my gentoo receiving boot messages error about the system dont know when my partitions are mounted the last time. every start i see the errors talking about my gentoo advance in future, 4000 days of more without a check.
> ...

 

Zorth, this will solve your problem;

```
# emerge ntp 

# etc-update add ntpd default 

# /etc/init.d/ntpd start 

# /etc/init.d/ntp-client start
```

FYI - Your motherboard CMOS battery could need replacing as it seems that it is not keeping the time correctly.  :Wink: 

Your english is very good.  :Wink: 

----------

## nagmat84

Hi,

thank all of you for your solutions, but they do not and actually cannot work.

 *Quote:*   

> 
> 
> Looks like your BIOS (HW Clock) is incorrect for one. 
> 
> I would;
> ...

 

@Kingmilo: As a said my hardware clock, BIOS Clock, RTC or however you want to call it, is set correctly. See my output from "hwclock --show". Even if I enter the BIOS during POST I see the correct local time in the BIOS screen. NTP does not (and cannot) help, because my root partition is mounted before NTP starts, and that is the point where the mount time is written to the super block. Furthermote NTP would not have any effect, because the hardware clock and the system clock are in in sync and correct. Despite of this, NTP is running.

@NeddySeagoon: Well, I use dual boot with Windows, so I need the local time in the BIOS. Windows shows the correct time. So no problems there.

Anyhow, thank you for your answers so far,

Matthias

----------

## wynn

There was a problem with baselayout-1.12.6 and earlier to do with the order of the clock initscript and the checkfs script. See sys-fs/e2fsprogs-1.39 always reports superblock last mount time in future, mount time and Strange superblock boot message (mount time in future). This appears to have been corrected though.

----------

## nagmat84

You might be right, because during my init sequence the clock initialization comes after the file system check. But I have baselayout-1.12.9, so this bug shouldn't exist anymore.

But if I look at /sbin/rc, line 158 reads

```

get_critical_services() {

   local x=

   CRITICAL_SERVICES=

   

   if [ -f "/etc/runlevels/${BOOTLEVEL}/.critical" ]

   then

      for x in $(< /etc/runlevels/${BOOTLEVEL}/.critical)

      do

         CRITICAL_SERVICES="${CRITICAL_SERVICES} ${x##*/}"

      done

   else

      CRITICAL_SERVICES="checkroot modules checkfs localmount clock bootmisc"

   fi

   export CRITICAL_SERVICES

   return 0

}

```

and line 440

```

# Start checkroot and modules before we load volumes

export START_CRITICAL="yes"

for x in checkroot modules ; do

   [[ " ${CRITICAL_SERVICES} " != *" ${x} "* ]] && continue

   start_critical_service "${x}"

done

```

This seems to be the old code from previous versions. The bug reports suggest different solutions.

Change the order in the CRITICAL_SERVICES variable

Replace "for x in checkroot modules" by "for x in clock checkroot modules"

Modify the depend{} in /etc/init.d/checkroot

What is the best or the intended way?

Matthias

----------

## nagmat84

OK, I just did all three options and now it works. Thank you very much. But just one correction: The bug is still open and not corrected yet. It seems that there are some not easy to solve problems with the correct boot order, if you have special hard disks that needs some kernel modules first. But for my standard PC the suggested solutions are fine.

Thank you, Matthias

----------

## Mugen096

Just to update...

I also had the same problem with mine.  Not dual booting, but running Linux, in multiple flavors, hosted on a Virtual Server 2005...which the BIOS clock for the virtual PC, no matter what you do, is always going to match the local clock on the hosting server OS...local time.

I did some testing, and got away with only having to change the:

Replace "for x in checkroot modules" by "for x in clock checkroot modules" 

On line 440 of the /sbin/rc file.  Thank you very much for the hint though, I would have never thought to check there.  I guess, baselayout, or not, now that we are entering the virtual age, don't we all think it is time for the Kernel to percieve the BOIS clock as local time, or at least have the option to set a time zone in the Kernel itself???

I am also running Baselayout-1.12.9-r2, still a bug...

Thank you again for your insight...

Dan

----------

