fixrtc is ineffective when there is no battery for the RTC

[Alfonso Sanchez-Beato]

When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

This debdiff adds a fixrtc-mount that helps with this issue by looking at dates from files, once root has been mounted.

[Oliver Grawert (ogra)]

well, i'd rather find out why the original fixrtc did not work in the first place ... dumpe2fs output of the respecitve failing disk captured from an initrd shell on first boot of the device would be interesting debug data

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

This is the output of dumpe2fs:

http://paste.ubuntu.com/24815516/

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

New patch version, which includes now a patch from ogra (LP: #1623125)

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "add-fixrtc-mount.patch" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Stefan Bader (smb)]

I was reviewing the latest patch and beside of this part being modified (@Ogra, would you be fine with that? And btw Jan 1 2017 is a Saturday), I am not fully understanding what exactly looking at file dates gains. The date will be less wrong but still potentially off by days. The system date would be corrected via NTP and I believe that would also update the RTC (which without a battery is lost again).
Could you elaborate what would be gained by using the file date compared to possibly just extending ogra's patch to move anything before the year x or without a date to an artificial year x?

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

@smb what I have seen is that devices lacking RTC battery tend to never had a good date in the "last mount day" date of the root filesystem, as when root is mounted the date is always near the epoch. The patch can correct this, otherwise we would be getting the date systemd was built.

Of course this is not terribly accurate, but solves issues with certificates/assertions that were deemed as not yet valid on first boot if there was no network.

[Stefan Bader (smb)]

@Alfonso, right, but the details about what exactly failed is quite important/useful information. If some certificates are deemed invalid on boot until there is network this does not sound too bad at first. If this causes services to not start, then this becomes more important to fix.
Also wondering how this works on different arches (like armhf/raspberrypi). Those things have no RTC and also no links to kernel/initrd in /. Those come up ok even with last mount time being off. But then maybe those do not run whatever is having issues.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

@smb the concrete problem this was solving was happening with an armhf device running Ubuntu Core. UC assertions were not validated and a system user could not be created if there was no network (no date update). Not sure if this was breaking the system even if later you connected the device.

[Stefan Bader (smb)]

Looking at the complete fixrtc-mount script (the part which was fixed in bug #1623125 makes me think that this would fix your problem as well. And that with much less required change. That script checks not only mount but also create time of the fs. If create time is more recent than mount time, then it will set the time to that. And the time of creating the Ubuntu Core image should be recent enough to meet any expectations of the certificates. What I think has happened is that the "n/a" result was causing date to return an error. And because the scripts are executed with "-e" this would stop execution right there and the time was not set at all.
With the check for "n/a" as the change is in its original form, it would set mount time to 1999 but then use the create time which is newer. And since that is done pre-mount, this will set mount time to create time, too.

So right now I tend to mark this bug as duplicate of bug #1623125, then get that fix in (preferred because it would be much smaller/simpler). Should this turn out to not be enough, we still can un-dup and look for a bigger solution. Thank you for your efforts, and sorry for me being so resistant. I am just trying to fix the problem with as little change as possible. The less change, the less one can break.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

@smb, actually, there is no create time field in the fs header, see

http://paste.ubuntu.com/25478756/

(this comes from a file with the mount time already corrected). This is a partition created with android tools, as the ones from mkfs.ext4 do not work for this device (for unknown reasons). I understand this is sort of a special case though.