You might want to pull the code from Mandriva before the 16'th.

Source RPM: systemd-37-15.mga2.src.rpm => systemd-38-3.mga2.src.rpm

Problem cause by missing modules:
/lib/systemd/system/hwclock-load.service
/lib/systemd/system/hwclock-save.service

this is wrong because they are not provided by systemd anymore

CC: (none) => dmorganec

(In reply to comment #2)
> Problem cause by missing modules:
> /lib/systemd/system/hwclock-load.service
> /lib/systemd/system/hwclock-save.service
> 
> this is wrong because they are not provided by systemd anymore

Ok, tell me which services is doing the hwclock save/load operation during shutdown/startup and I'll open a bug report against them.

what about this bug with systemd 40 ?

(In reply to comment #4)
> what about this bug with systemd 40 ?

No idea. I opened the problem report, copied scripts/units from Mandriva and they worked just fine. 

I am not doing a clean install+upgrade just to test the bug report. systemd has done nothing but get worse.

I have done my last clean install+upgrade until beta1. My patch_2 script will test if problem was resolved and if so, I'll test it.

Confirm this. I've made a clean install of Mageia Alpha 2, which was then upgraded to Cauldron and kept current. System clock is not being updated during shutdown. (systemd-43-1.mga2)

CC: (none) => mitya

(In reply to comment #2)
> Problem cause by missing modules:
> /lib/systemd/system/hwclock-load.service
> /lib/systemd/system/hwclock-save.service
> 
> this is wrong because they are not provided by systemd anymore

Just did another beta2 clean install, applied updates, deleted orphans, ran
hwclock --set --date="3/22/12 16:45:05"
and rebooted.

still get the error messages and last two lines indicated
Give root password for maintenance
(or type Control-D to continue):

So I went ahead and hit Control d every time it came up and console locked up and my VB Guest screen is not showing any activity. Runlevel 3 with splash=silent deleted from /boot/grub/menu.lst.

This bug will impact all users who turn off their machine. :-(

Source RPM: systemd-43-3.mga2.src.rpm => systemd-44-2.mga2.src.rpm

OK, so looking into this it just seems that this is fundamentally wrong:

systemd-fsck: local: Superblock last write time (Fri Dec 16 14:13:59 CST 2011,
systemd-fsck: now = Mon Dec 19 04:35:59 2011) is in the future.
systemd-fsck: local: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.


Now unless my geographic knowledge is severely fsck'ed up, Dec 19th is always after Dec 16th regardless of timezones!!

So something in the comparison is quite messed up. I'm not sure if it's actually systemd doing this of the fsck of the filesystem in question (I suspect the latter). What fs is this?


The test you did in comment 7 is somewhat invalid AFAICT. I mean if you mess with the hwclock, it's kinda expected that bad things can happen. The logic behind not calling hwclock any more is that we really shouldn't be messing with it.


commit da2617378523e007ec0c6efe99d0cebb2be994e1
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Wed May 25 18:21:36 2011 +0200

    drop hwclock-save.service
    
    We don't want to fiddle around changing the RTC, not on bootup, not
    on shutdown.
    
    If we don't run NTP, we have absolutely no clue what's the current
    time to store in the RTC. If we run NTP, the kernel syncs the system
    time every 11 minutes to the RTC.
    
    Especially in multi-boot environents we must not call hwclock(8)
    which tries to be smart with calculating/storing/applying drifts
    and such.
    
    Live-CDs must never touch the RTC, because we don't know if it is
    running in UTC or locatime.

commit 7948c4dfbea73ac21250b588089039aa17a90386
Author: Kay Sievers <kay.sievers@vrfy.org>
Date:   Tue May 24 20:23:07 2011 +0200

    rtc in localtime: use settimeofday(NULL, tz) instead of hwclock(8)
    
    We check for LOCAL in /etc/adjtime and if needed, ask the kernel to
    apply the timezone delta to the system clock.
    
    The very first call of settimeofday() without a time, but a timezone
    warps the system clock, so that it properly runs in UTC.



So I wonder if the problem is that you simply didn't have ntpd running or didn't have an internet connection?


Anyway, I don't think the problem is as simple as adding these units back.


> This bug will impact all users who turn off their machine. :-(

Only if they run a hwclock command to mess with their clocks!

CC: (none) => mageia

(In reply to comment #8)
> OK, so looking into this it just seems that this is fundamentally wrong:
> 
> systemd-fsck: local: Superblock last write time (Fri Dec 16 14:13:59 CST 2011,
> systemd-fsck: now = Mon Dec 19 04:35:59 2011) is in the future.
> systemd-fsck: local: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> 
> 
> Now unless my geographic knowledge is severely fsck'ed up, Dec 19th is always
> after Dec 16th regardless of timezones!!
> 
> So something in the comparison is quite messed up. I'm not sure if it's
> actually systemd doing this of the fsck of the filesystem in question (I
> suspect the latter). What fs is this?
> 
> 
> The test you did in comment 7 is somewhat invalid AFAICT. I mean if you mess
> with the hwclock, it's kinda expected that bad things can happen. The logic
> behind not calling hwclock any more is that we really shouldn't be messing with
> it.
> 
> 
> commit da2617378523e007ec0c6efe99d0cebb2be994e1
> Author: Kay Sievers <kay.sievers@vrfy.org>
> Date:   Wed May 25 18:21:36 2011 +0200
> 
>     drop hwclock-save.service
> 
>     We don't want to fiddle around changing the RTC, not on bootup, not
>     on shutdown.
> 
>     If we don't run NTP, we have absolutely no clue what's the current
>     time to store in the RTC. If we run NTP, the kernel syncs the system
>     time every 11 minutes to the RTC.
> 
>     Especially in multi-boot environents we must not call hwclock(8)
>     which tries to be smart with calculating/storing/applying drifts
>     and such.
> 
>     Live-CDs must never touch the RTC, because we don't know if it is
>     running in UTC or locatime.
> 
> commit 7948c4dfbea73ac21250b588089039aa17a90386
> Author: Kay Sievers <kay.sievers@vrfy.org>
> Date:   Tue May 24 20:23:07 2011 +0200
> 
>     rtc in localtime: use settimeofday(NULL, tz) instead of hwclock(8)
> 
>     We check for LOCAL in /etc/adjtime and if needed, ask the kernel to
>     apply the timezone delta to the system clock.
> 
>     The very first call of settimeofday() without a time, but a timezone
>     warps the system clock, so that it properly runs in UTC.
> 
> 
> 
> So I wonder if the problem is that you simply didn't have ntpd running or
> didn't have an internet connection?
> 
> 
> Anyway, I don't think the problem is as simple as adding these units back.
> 
> 
> > This bug will impact all users who turn off their machine. :-(
> 
> Only if they run a hwclock command to mess with their clocks!

(In reply to comment #8)
 
Sorry, hit wrong control key. Trying again.

> Only if they run a hwclock command to mess with their clocks!

Ok. I just did a hwclock --systohc and will save system, restore system tomorrow and reboot to see if fsck shows up.

Keep a note of the fsck message and the dates shown (as you did in the first comment) to see if the comparison is just "weird" if it does show up.

[    8.326179] dracut: 91-root: Superblock last write time is in the future.
[    8.336300] dracut: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED.

This happens for anyone in a utc minus timezone, as the root filesystem
is mounted before systemd has determined that the hardware clock is
in local time, so it hasn't added the difference yet to calculate
the utc time correctly.  (I'm assuming the superblock time is utc).

CC: (none) => davidwhodgins

(In reply to comment #11)
> Keep a note of the fsck message and the dates shown (as you did in the first
> comment) to see if the comparison is just "weird" if it does show up.

Sorry about that. I had the megia problem, knew I opened one in mandriva, so I copied the problem report and changed the date rather than retype the whole thing.

Changing the hwclock time was just to speedup test time. Did another VirtualBox install last night, saved it, opened it just now, applied today's updates, reboot and no problem. Frap I really hate when these things make me look like a idiot.

For the most part, I do not open problem reports unless I they are re-creatable in normal operation.

As far as I am concerned, the problem no longer happens. I leave up to you,
Dimitri and Dave if it is resolved.

$ date -R
Mon, 02 Apr 2012 10:38:05 -0500

seems to indicate I am a minus timezone user, clock is set UTC and 
grep -i dracut /var/log/dmesg shows no superblock future message.

(In reply to comment #13)
> Changing the hwclock time was just to speedup test time. Did another VirtualBox
> install last night, saved it, opened it just now, applied today's updates,
> reboot and no problem. Frap I really hate when these things make me look like a
> idiot.

Don't feel bad. Everyone does this, myself included, and the signal-to-noise ratio is still massively in credit!

I'd like feedback from the others too to see what they think as this could still be a serious issue from an "impact" perspective, even if it's not super likely to occur naturally and without prompting.

I do get it each time I boot cauldron but was just ignoring it, as
it doesn't seem to have any impact.

It only affects people in the western hemisphere who have the clock
set to local time.

I'm not sure how much of an offset fsck.ext4 will accept.  If it's
less than 11 hours, then people in the utc-11 timezone will have
problems.

Would probably be best to have the utc/localtime option set in
the initrd prior to the fsck on the root drive.

The new e2fsprogs release contains config that will prevent dropping to a debug shell when there are issues with the clock, so I consider this bug fixed in that regard.

There may be more work to be done regarding the handling of the clock generally, but that's something that I think should be handled as a different bug report.

Hope that's OK with everyone. Further discussion on how we should handle the clock should probably take place on the mailing list first.

Resolution: (none) => FIXED
Status: NEW => RESOLVED