No because his key needs to be signed by the canonical key when he uploads the key (unless you can move the time backwards on the server that hosts the canonical key somehow - please don’t try 
)
1 Like
LOL, i’m not that powerful
Thanks for the info, unless I find the motivation to re build the kernel snap (or buy a compatible RTC), I’ll put this on hold for now.
@ijohnson Sounds like the fix exists but is making its way through the release pipeline. If that’s the case, any chance you can share the estimated release date (this answer may influence buying an RTC module) ?
Hey @dav,
Recently, I tried the edge channel and it works. I hope, it helps you with your exploration of Ubuntu Core.
2 Likes
Thanks, I’ll give it a go.
It looks good until the very end:
Fetching snapd
Fetching pi-kernel
Fetching core20
Fetching pi
Fetching htop
Crash in state machine
Traceback (most recent call last):
File "/snap/ubuntu-image/215/lib/python3/site-packages/ubuntu_image/__main__.py", line 393, in main
list(state_machine)
File "/snap/ubuntu-image/215/lib/python3/site-packages/ubuntu_image/state.py", line 82, in __next__
step()
File "/snap/ubuntu-image/215/lib/python3/site-packages/ubuntu_image/common_builder.py", line 348, in populate_bootfs_contents
self._populate_one_bootfs(name, volume)
File "/snap/ubuntu-image/215/lib/python3/site-packages/ubuntu_image/common_builder.py", line 329, in _populate_one_bootfs
for filename in os.listdir(src):
FileNotFoundError: [Errno 2] No such file or directory: '/sharedmount/build/unpack/gadget/$kernel:dtbs/dtbs/broadcom/'
note:
-
/sharedmountis the shared directory between the docker container that builds the image and the host. - It’s running ubuntu-image 1.11+snap1
- /sharedmount/build/unpack/gadget only contains
boot-assets,metaandsnapdirectories
EDIT: exploring the file in question (common_builder.py) , I ran into this comment block which sounds
# Not using "snap prepare-image" (or old snap
# binary) - the below code path will not
# understand new style "$kernel:" references in
# gadget.yaml and will fail if used with these
# references.
Makes me think I am somehow using an old binary…
I am building using this command: export UBUNTU_STORE_AUTH_DATA_FILENAME=/root/mycreds; ubuntu-image snap -w /sharedmount/build -O /sharedmount /sharedmount/iris-model.model
1 Like
@dav, I just gave it a try now and it worked here. I built the image on native Ubuntu Desktop 20.04.
ubuntu-image snap pi-model.assert
Probably, you are having an environment-related issue. Sorry it is hard to help without having a similar environment
Well that encourages me to try harder. I’ll make a fresh Focal docker container and try again with as little tweaks as possible.
Got it to work. Not sure what did it, but I think upgrading snapd to --edge was the winning move.
2 Likes
Hi,
Thanks for those hints, I also observed the same probem with host’s snapd (stable/11402) :
No such file or directory: '/tmp/tmpcp3sp3cn/unpack/gadget/$kernel:dtbs/dtbs/broadcom/'
Update to edge/2.50+git1666.g799fa37 fixed the issue.
ubuntu-image --version
ubuntu-image 1.11+snap1
snap --version
snap 2.50+git1666.g799fa37
snapd 2.50+git1666.g799fa37
series 16
ubuntu 20.10
Now by setting pi and pi-kernel to “edge” channel, I used this recipe as source:
The pc one works as expected (on vm) not the pi one:
There is signal on HDMI showing black screen
then signal is gone (rebooting?)
and signal is back with black display
I tried combination of various channels but not luck yet.
Did I miss something ?
Related links:
The DTB handling changed in the edge channel … it will still take a bit until this fully lands on stable so better build with everything (kernel, gadget in the image … and on the build host: snapd, ubuntu-image) from edge to get properly working images ATM …
1 Like
Previous issue reported has been solved also on armhf with:
This is encouraging,
but I am not sure it works using a recent generated key:
For the record I am still observing this:
[ 8.464501] the-tool[207]: 2021/04/26 10:28:50.214073 secboot_tpm.go:222: cannot open TPM connection: no TPM2 device is available
[ 8.488510] [the-toolFAILED[207]: ] error: cannot load metadata and verify essential bootstrap snaps [base kernel snapd gadget]: cannot accept some assertions:Failed to start the-tool.service.
[8.489324] the-tool[207]: - assertion is signed with expired public key “???” from “???”
[ 8.548594] systemd[1]: the-tool.service: Main process exited, code=exited, status=1/FAILURE
[ 8.568428] systemd[1]: the-tool.service: Failed with result ‘exit-code’.
[ 8.584401] systemd[1]: Failed to start the-tool.service.
[ 8.604353] systemd[1]: Startup finished in 2.246s (kernel) + 0 (initrd) + 6.273s (userspace) = 8.520s.
Image contains those edge’s snaps:
core20 1029
pi 101
pi-kernel 284
snapd 11990
I am using edge tools:
snapcraft 4.7.1 6466 latest/stable canonical✓ classic
snapd 2.50+git1685.g72d9b26 11987 latest/edge canonical✓ snapd
ubuntu-image 1.11+snap1 218 latest/edge canonical✓ classic
Relate-to:
https://forum.snapcraft.io/search?q=assertion%20is%20signed%20with%20expired%20public%20key
hmm, i would have expected this to be fixed by:
1 Like
That fix needs to be released into the initrd, which takes a bit of time. The release process steps for the uc20 initrd are as follows:
- Fix snap-bootstrap in master ✓
- Release snapd Deb with fixed snap-bootstrap to snappy-dev image PPA for focal ✓
- Rebuild the ubuntu-core-initramfs package to use the snapd Deb from 2
- Rebuild the kernel snap using the ubuntu-core-initramfs PKG from 3
AIUI, 3 is being done right now, and 4 is done at least every 2 weeks as per kernel SRU cadence
3 Likes
@ijohnson ok thx for feedback I am looking at tip of this repo:
Currently " 2021-04-26 [UBUNTU: Ubuntu-pi-5.4.0-1035.38]"
so I guess a new version will be released soon.
Meanwhile I’ve tried Pi3 with an external RTC module (pcf8563) but I am afraid it won’t work on current base as I commented at:
I’ll try to rebuild kernel maybe later but I am unsure this can be done without signing it using canonical keys, BTW I’ll be curious to know if it is possible to rebuild from scratch all snaps from UC, and if this is documented anywhere.
Well, I’ve found some hints on this page:
(but IMHO it can be more detailed on how to use tools)
Sorry if i am drifting a bit from the subject of this thread, but it might also help other blocked users.
To be clear about my steps above, step 3 is now done - version 45 of ubuntu-core-initramfs is now released to the snappy-dev image PPA, so we just need the 20 channel of the pi-kernel to be rebuilt to pick it up (step 4).
For the pi, since you don’t need to sign it with EFI keys or anything like that the way you need to do for amd64 due to UEFI, you can just rebuild the kernel and use a dangerous model assertion. I have not build the pi-kernel myself before, but I understand it to be a bit complicated, perhaps @ogra or @ondra have some pointers on how to build a kernel snap for UC20 
At some point we should definitely have a doc page about how to build all the snaps from scratch like this, but it would take a while to get everything together for that
1 Like
Totally not complicated … for custom kernels that do not need to be built from the binary deb the kernel trees all ship a snapcraft.yaml in the top-level of the tree … you just call snapcraft when in the tree … (current snapcraft does not support --target-arch so you need to do it on the native target architecture)
2 Likes
Some updates, it’s fixed !!!
thanks a lot to those who were involved in updates.
I was able to build and boot my own arm64 images for pi3 or pi4 using:
core20 1033
mir-kiosk 6981
pi 97
pi-kernel 285
pinball-table-hurd 20
snapd 12068
If curious there is more to come about this “demo” project:
3 Likes
Does core20 on stable channel work now?