Adding ubuntu core fails on first boot with rtc is present

HI, I am using CM4 with UC20. During the first boot with RTC Errors that I have seen are:

  • “assertion not valid anymore”
  • “assertion is signed with expired public key”

I tried to implement the “fixrtc” on cmdline.txt as suggested on :

But that doesnt seem to do anything

I don’t know about fixrtc but IIRC on UC20, if there is no RTC, the time would first be set from the initrd build time making it a lower bound. On top of this, but only in install & recover modes, build times of snaps loaded from the system seed can provide an improved lower bound, but that’s about it.

Perhaps some of the UC folks have more info, cc @abeato @valentind

It would be helpful if you could provide a serial console log.

in the serial console: it displays

statenegine.go 149: state ensure error: devimgr: cannot seed: cannot accept some assertions: -assertion is signed with expired public key “” from “canonical”

  • no matching public key “” for signature by canonical

If there is another way i can record the serial console info on first boot, please let me know.

Sorry, I forgot to mention before. The RTC i am using is ds3231 and it is an external RTC connected to i2c-1 bus on the CM4

Sorry, I’ve misunderstood your problem. So there is an RTC, but it’s not configured, so it’s probably reporting time that’s totally off. Let’s see if the Ubuntu Core folks have any suggestions on how to fix that.

Any chance that the serial logs contain a timestamp which would indicate what is the system time?

the time stamp was in seconds and not time : [317.345160]. The message that i posted above occurred at this timestamp

Hi @rahul-tt,

There was a similar discussion last year that can be seen in the thread below.

The initial problem was available in all of the systems that do not have a RTC. Basically, the initrd was stuck at Nov 2019, so if you created the key that you signed your model assertion with after that date, then the image was unable to boot. Then the engineering team improved the situation by introducing fetching the timestamp of the trusted assertions (e.g.model-assertion, system-user assertion) and move the system time forward accordingly. Therefore, the problem was solved.

Considering that, if I understand your situation correctly, although you have a RTC in your system, it is not actively used. So your situation is identical.

By looking at the error messages you have shared;

statenegine.go 149: state ensure error: devimgr: cannot seed: cannot accept some assertions: -assertion is signed with expired public key “” from “canonical”

  • no matching public key “” for signature by canonical

Why is there an assertion in your system that is signed by “canonical” ? I would highly recommend double checking your model.json and assertion files in case you used an assertion coming from Canonical rather than you.

Hi @bugraaydogar,

My model has the authority id set to my brand store id: I am not sure why it is checking assertion from canonical instead.

But after trying 10 time for signature from canonical . It retries to check for assertion from my brand store id.

I have an image of the serial console output. But it has some keys which i cannot share

Understood, it is okay. Then the only possible reason might be your RTC. Are you sure that the RTC is not initialized and reverted the system time to an old date? If possible, I would suggest disconnecting the RTC and checking the results.

Just recently, I have created an UC20 image for my Rpi4 (with no RTC) and I am able to boot.

Hi @bugraaydogar,

It is due to the RTC for sure. When i disconnect the RTC or if the RTC time is syncronised. The Ubuntu core first boot work normally as intended.

But only when i reset the RTC time to its default value, the system takes the old date from RTC and the first boot assertion fails.

After some time, the OS writes to the RTC the correct date. I have to power cycle after this step for everything to boot normally again.

The process goes like this:

  • First boot
  • read RTC
  • Sets system time from RTC
  • Check for asserstion signing keys–> which fails due to wrong RTC time
  • Syncs RTC time with the NTP server
  • Stuck in a loop

I think this order should be fixed

We investigated this issue some more and it seems the issue is triggered by the fact that the ds3231 driver is build as a module (rtc-ds1307.ko). The sequence of events is:

  1. kernel boot, has no idea about time at this point (RTC driver is a module)
  2. systemd starts, moves time forward to it’s own build date
  3. during boot the rtc-ds1307.ko gets loaded
  4. the pi-kernel config states: CONFIG_RTC_HCTOSYS=y and CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
  5. this means the kernel code in drivers/rtc/class.c:__devm_rtc_register_device is called which then will run rtc_hctosys(rtc) - at this point the clock moves back to 200-01-01 (or whatever the default of the RTC is)
  6. if there is network eventually systemd-timesyncd will do an NTP sync and fix things again

The easiest way to fix this would be to simply build rtc-sd1307 into the kernel. However there are 101 rtc-*.ko modules in the 5.15 kernel (have not looked at 5.4 but probably a similar number) so just including all might be a bit too much.

1 Like

There is also a systemd upstream bugreport about this

I also reported