System update UI shows 'last updated in 1970'

[Lisette Slegers]

Exact message:

No software update available. Last updated 1970-01-01 02:04:36

Please also see bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1215901

I don't know the build number because it is not included under 'About this phone'.

[Sebastien Bacher (seb128)]

> No software update available. Last updated 1970-01-01 02:04:36

that's a bug in the system image service

> I don't know the build number because it is not included under 'About this phone'.

That should be fixed with the most recent upload (not sure it made it to a green image yet)

[Barry Warsaw (barry)]

I'm not entirely convinced that this is a bug in system-image, so let's explore it a little bit (if you can still reproduce it).

s-i gets it's "last update date" from the mtime of one of three files. The first of these files that it finds, it takes the mtime and converts that to a date string of the format you show. The files are:

/userdata/.last_update
/etc/system-image/channel.ini
/etc/ubuntu-build

So the first thing to do is to ls -l each of these files (via adb shell) and see if any of them give you an mtime matching 1970-01-01 02:04:36.

What's strange is that date. We use Python's datetime object to convert from a POSIX timestamp to a timestamp string. If I run the conversion in reverse, it means that the file would have to have kind of a weird timestamp:

>>> d = datetime(1970, 1, 1, 2, 4, 36)
>>> d.timestamp()
7476.0

(Note that this would be slightly different on amd64, so try that on your device).

Why *that* number?

Note that if let's say the mtime were 0, we'd get a different timestamp:

>>> d = datetime.fromtimestamp(0)
>>> print(d)
>>> d = datetime.fromtimestamp(0)
>>> print(d)
1970-01-01 00:00:00

Which is off by 2h4m36s. I suppose it's possible that some mobile devices would return different values for timestamp 0 (just as it does on amd64). Be sure to test this with Python 3.

If that's the case, then identifying which of the three above files exists and has the bogus mtime will be key to debugging this.

Another possibility. Let's say that none of those files exist (for some inexplicable reason). system-image-dbus in that case will return the string 'Unknown' as the timestamp. Can system-settings handle that? I wonder if when it sees 'Unknown' it returns the bogus date string?

Anyway, I can't reproduce this, nor can I see how it would even be possible, so more information is necessary.

[Sebastien Bacher (seb128)]

let's close it, the UI changed and the bug can't be reproduced easily/might be fixed in the current version