Jump to content

Cubietruck RTC problem with Jessie kernel 4.3.3

Andrew Findlay

By Andrew Findlay
in Allwinner sunxi

 Share

Recommended Posts

Andrew Findlay

Andrew Findlay

Posted
Posted

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

Igor

Posted
Posted

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.

EtlARM

EtlARM

Posted
Posted

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

zador.blood.stained

Posted
Posted

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

EtlARM

Posted
Posted

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

zador.blood.stained

Posted
Posted

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

apollon77

Posted
Posted

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

Igor

Posted
Posted

@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

EtlARM

Posted
Posted

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

amhairghin

Posted
Posted

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.
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept