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.
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’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.
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.
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.
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:
kernel boot, has no idea about time at this point (RTC driver is a module)
systemd starts, moves time forward to it’s own build date
during boot the rtc-ds1307.ko gets loaded
the pi-kernel config states: CONFIG_RTC_HCTOSYS=y and CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
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)
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.