Ubuntu Touch devices sometimes come up with hwclock set to 1970

Bug #1353591 reported by Paul Larson
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Canonical System Image
New
Undecided
Unassigned
Ubuntu
Confirmed
Undecided
Unassigned

Bug Description

In smoke testing, starting around image 165, we started seeing a lot of autopilot tests start to fail with apparmor denials. After some further digging, we found that sometimes the device came up with a reasonable date/time, and sometimes it comes up after install with a date back in 1970. We found this in the syslog:
Aug 6 05:06:31 ubuntu-phablet ntpdate[2787]: step time server 91.189.89.199 offset 1400004685.653897 sec
(see: http://q-jenkins.ubuntu-ci:8080/job/utopic-touch-mako-smoke-daily/666/artifact/clientlogs/ubuntu_calculator_app/syslog/*view*/ for full syslog from a failed run)

Because we now precompile the apparmor rules, the updated rules getting pushed in via aa-clickhook happen before ntpdate has successfully updated the time and are getting timestamped with a very old date. Since apparmor sees that it already has newer rules cached, it does not update.

There are a few things at play here:
1. devices don't reliably come up with a reasonable time
2. It takes a bit for ntpdate to get the time/date fixed
3. hwclock -w is only called on proper shutdown, which is unlikely to happen for phones

tags: added: lt-category-noimpact lt-prio-high
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1353591/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubuntu:
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

https://wiki.ubuntu.com/HardwareClock might be useful to understand the current design, and if you need to amend that design for this case then it would be worth feeding information back into that wiki page.

Revision history for this message
Ondrej Kubik (ondrak) wrote :

I have investigated similar issue on krillin.
In case of krillin hw clock is set at the factory to 1st of January 2014, 0:00am.
This causes first boot (out of the box experience) to last 2mins 40 seconds before welcome wizard appears, with over 2minutes of it being white screen with bootloader logo (Google in case of N4, BQ for krillin)
Proposed and tested fix is to have upstart job, which would check time stamps of installed custom and rootfs builds. HW clock is then adjusted to those time stamps.
This will not set time to correct value, however it will set it to something more realistic and at least to time which is ahead of the time when images in the phone were built, and more importantly when apparmour caches were created.
This makes first boot accept precompiled apparmour caches.

Revision history for this message
Ondrej Kubik (ondrak) wrote :
Revision history for this message
John McAleely (john.mcaleely) wrote :

@pat - can you give this bug suitable milestone love so we can land the fix?

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.