Cubietruck RTC problem with Jessie kernel 4.3.3

[Andrew Findlay 0]

Since updating to the (vanilla) 4.3.3 kernel, my Cubietruck has not read the real-time clock at boot time.

This causes all log messages to show "Jan  1 01:00:10" until the NTP daemon kicks in. It also causes cron to remain confused about daylight savings until it is restarted.

 

Looking at the release history at http://www.armbian.com/logbook/I see that v4.81 / 28.12.2015 includes a fix for a "Jessie RTC bug". Unfortunately it seems that this release has introduced an RTC bug!

 

What was the fix, and is there an option I can use to reverse it?

 

Before the update the boot messages looked like this:

 

Jan 14 00:45:07 localhost kernel: [    0.000000] Linux version 4.2.6-sunxi (root@production) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #1 SMP Sun Nov 29 10:33:44 CET 2015
...

Jan 14 00:45:07 localhost kernel: [    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_
mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
...

Jan 14 00:45:07 localhost kernel: [    1.928318] sunxi-rtc 1c20d00.rtc: rtc core: registered rtc-sunxi as rtc0
Jan 14 00:45:07 localhost kernel: [    1.928335] sunxi-rtc 1c20d00.rtc: RTC enabled

...

Jan 14 00:45:07 localhost kernel: [    2.108059] sunxi-rtc 1c20d00.rtc: setting system clock to 2016-01-14 00:44:58 UTC (1452732298)
 

After the update I get:

 

Jan  1 01:00:10 localhost kernel: [    0.000000] Linux version 4.3.3-sunxi (root@production) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #3 SMP Mon Dec 28 11:27:16 CET 2015
...

Jan  1 01:00:10 localhost kernel: [    0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
...

Jan  1 01:00:10 localhost kernel: [    1.927517] sunxi-rtc 1c20d00.rtc: rtc core: registered rtc-sunxi as rtc0
Jan  1 01:00:10 localhost kernel: [    1.927537] sunxi-rtc 1c20d00.rtc: RTC enabled
...
 and there is no attempt to set the system clock from RTC.

 

 

 

Thanks

[Igor 2451]

We forgot to include this package install to the upgrade procedure:

apt-get install fake-hwclock

This RTC bug fix was a must fix since your upgrade from legacy kernel ended up with non bootable system.

 

Fixed for future upgrades.

[Andrew Findlay 0]

That will certainly reduce the problems, but the Cubietruck does have a hardware real-time clock and it used to work!

[EtlARM 5]

I would like to put the statement that in the past the RTC was running fine also on my Cubietruck(s)!

It was necessary to do a 'hwclock -w' once, but afterwards the time was correct even during startup.

 

Now I have 1970 during boot and I don't think a fake-hwclock is the right solution if the real RTC has proved to work.

 

Is there some background information, why and how the RTC fix was done?

[zador.blood.stained 765]

It's known to be working OK until you switch from legacy kernel to mainline, which in case of Jessie results in completely unbootable system, in case of Wheezy/Trusty results in network errors.

It's a userspace (libc) problem combined with different offset for storing year in RTC.

This change doesn't disable RTC, it just prevents setting time on boot by kernel, instead it is set by fake-hwclock and later time is actualized by NTP client in userspace.

 

Yes, year 1970 in early boot and using fake-hwclock may look unnecessary, but it's nothing compared to completely bricked systems, using sysvinit in Jessie or restarting network in init scripts.

 

You can read more here: Original Armbian issue, systemd issue, isc-dhcp-client issue, Armbian commit that disabled setting time from RTC.

[EtlARM 5]

Thank you for the links!

If I understand correctly, systemd should work now on Jessy (Legacy)? I still get errors:

 

 

root@Cubietruck:~[0]# systemctl -l status systemd-remount-fs.service
â— systemd-remount-fs.service - Remount Root and Kernel File Systems
   Loaded: loaded (/lib/systemd/system/systemd-remount-fs.service; static)
   Active: failed (Result: exit-code) since Thu 1970-01-01 01:00:08 CET; 46 years 0 months ago
     Docs: man:systemd-remount-fs.service(8)
           http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
 Main PID: 164 (code=exited, status=1/FAILURE)

Jan 01 01:00:08 Cubietruck systemd-remount-fs[164]: mount: / not mounted or bad option
Jan 01 01:00:08 Cubietruck systemd-remount-fs[164]: In some cases useful info is found in syslog - try
Jan 01 01:00:08 Cubietruck systemd-remount-fs[164]: dmesg | tail or so.
Jan 01 01:00:08 Cubietruck systemd[1]: systemd-remount-fs.service: main process exited, code=exited, status=1/FAILURE
Jan 01 01:00:08 Cubietruck systemd[1]: Failed to start Remount Root and Kernel File Systems.
Jan 01 01:00:08 Cubietruck systemd[1]: Unit systemd-remount-fs.service entered failed state.

 

[zador.blood.stained 765]

Jan 01 01:00:08 Cubietruck systemd-remount-fs[164]: mount: / not mounted or bad option

Probably your /etc/fstab is wrong, if you have "data=writeback" option for root, you need to remove it.

[EtlARM 5]

Thanks, that fixed it. I have no idea how this option came there...

[apollon77 6]

I have that in my /etc/fstab too and on http://www.armbian.com/cubietruck/it is listed as a performance tweak ...

 

When this is needed to do?

[zador.blood.stained 765]

Quote from "man mount"

       data={journal|ordered|writeback}
              Specifies the journaling mode for file data.  Metadata is always
              journaled.  To use modes other than ordered on the root filesysâ€
              tem,  pass  the mode to the kernel as boot parameter, e.g. rootâ€
              flags=data=journal.

So setting data mode on rootfs via fstab is deprecated, but still works on older distributions - wheezy and trusty.

[apollon77 6]

Ok, so if I upgrade from Wheezy to Jessie I should check that before rebooting ... correct?!

 

@Igor: Or does that get's corrected automatically by your upgrade-script?

[Igor 2451]

@Igor: Or does that get's corrected automatically by your upgrade-script?

 

Wheezy to Jessie upgrade procedure is stock Debian. 

 

When doing distribution upgrade some problems might occur so you just need to be prepared for rescue operations if system doesn't boot for some reason. It's an rear event but it happens.

[EtlARM 5]

Ok, so if I upgrade from Wheezy to Jessie I should check that before rebooting ... correct?!

It worked also with that option for several month now... You just get an error message in the logs and when you query the systemd status. I wrote down a note some month ago to investigate this further, but forgot about it, as everything seems to work correctly.

 

After thinking about the source for this entry in /etc/fstab I have the strong feeling that it is a default setting from Armbian. At least in the version I installed first (which was most likely 4.5). I found the same value on my Cubieboard2 test system which is is a stock Armbian just as reference.

Maybe it takes only effect when installing to NAND (which I do)?

[amhairghin 0]

To fix "Cannot change data mode on remount" and fix the degraded init state.

 

Initially, there are these default options present:

# tune2fs -l /dev/nand2 | grep Default
Default mount options:    user_xattr acl
Default directory hash:   half_md4

Add the data=writeback to this list:

# tune2fs /dev/nand2 -o journal_data_writeback

And it'll look like this:

# tune2fs -l /dev/nand2 | grep Default
Default mount options:    journal_data_writeback user_xattr acl
Default directory hash:   half_md4

Then, even the option in /etc/fstab in not really neccessary but you can left it there.

 

I think that this can be added into install script.