I’m building a custom image for the Raspberry Pi platform. My image contains a gadget snap, standard kernel and six required snaps. It also contains a custom splash screen which I’ve adapted from here.
As @ogra mentioned in his blog Building an Ubuntu Core appliance image, device initialization can take quite some time on ARM because snaps are checksummed and installed on first boot. The image is intended for home users to download, flash to an SD card and then run on their Pi-based smart mirror setup; so an automated “factory boot” is not possible since we’re not shipping the actual device.
Now here’s the problem: Even though we’re providing users with the info “the first boot takes quite some time”, I’m getting feedback from quite a few people who think that the boot failed and shut down the device before initialization has completed.
Questions
Is it possible to shorten the device initialization process significantly? I’m assuming no since the root cause seems to be snapd SHA384-hashing each snap before installation, but I’d like to be wrong on that
If not: I could boot the image myself, let it initialize the seeds and then grab an image via dd or similar. But that is a) cumbersome and error-prone (I need to shrink the file system & volume size manually because Core expands the FS to the full size of the SD card), and b) results in a significantly larger image size (~530 MB for gzipped ubuntu-image output, > 2GB for manual image copy or else I risk cutting of existing files). BUT my knowledge in that area is sketchy at best, so any hints and tips are welcome
If 1. and 2. are a clear no-no, is there some way to provide user feedback during initialization? My first thought was to switch out the splash screen logo after the device has been initialized, so that the first screen would show something along “grab a coffee, this will take some time”; then replace it with the regular file for subsequent boots. The custom splash screen is implemented via psplash, i.e. a binary file created during the gadget snap’s snapcraft run, so I’d like to exhaust all other options before diving into that.
AFAIK there’s not much you can do with your image to shorten the time to boot. Regarding the SHA384 hashing, I provided a 3-4 times speedup of SHA3 hashing to the go project, but it has yet to be reviewed and accepted. You could subscribe or give a +1 to https://github.com/golang/go/issues/28148 if you wanted, but it seems unlikely that it will go forward at this point.
Additionally, there has been some work on measuring and enumerating the time it takes to perform operations in snapd, but that work is currently just measurement, but will hopefully lead to faster boot times in the future.
There is a way to display text in psplash … so as a hack we could surely add something that shows some “Initializing System, please wait …” line during first start …
@mvo mentioned something in IRC about improving ubuntu-image to preinstall snaps in the generated image, or did I misunderstand that? If that’s something feasible and planned, I’d be happy to help and/or test
preinstalling snaps in an image is described in my blog post i think (you add them to the model definition in the required-snaps list) …
along with that you can use the --extra-snaps option to point ubuntu-image to additional snaps to put in the image (but these will not be in the seed, the required-snaps way is definitely the clean option here)
That’s what I’m using already, but maybe I used the wrong terminology here My understanding is that required-snaps in the model definition will put the snaps into the image, but on first boot snapd will nonetheless run the whole installation process for each of those snaps, i.e. the SHA384 verification + everything else that would run when you type snap install xyz on a normal Core installation. Which is the main reason why first boot takes such a long time.
I noticed image preseed support for quicker boot times in the snapd 2.46 release notes, and the command description looks quite promising for this issue Would very much like a write-up on the snapcraft blog or similar!
Unfortunately that feature is for classic images only at the moment, but we do hope to eventually expose some of that functionality for Core devices, but it is rather complicated because the classic case is a bit easier to run preseeding in the build environment because it’s basically just a chroot, whereas for Ubuntu Core, it would need to be much closer to the actual environment which is difficult to mock/setup without just standing up an entire VM of the image.
Would very much like a write-up on the snapcraft blog or similar!