Shorten device initialization (or at least give user feedback)


#1

Context

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

  1. 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 :slight_smile:

  2. 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 :smiley:

  3. 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.


#2

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.


#3

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 …


#4

That’s great news! Do you happen to have a pointer on how I could inform psplash that it’s running for the first time?


#5

Thanks for the link, gave my +1 but I don’t have any substantial knowledge in these areas, so can’t be of much help I’m afraid.


#6

@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 :slight_smile:


#7

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)


#8

That’s what I’m using already, but maybe I used the wrong terminology here :slight_smile: 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’ve dug through my IRC log; @mvo stated that

we want to improve this (hopefully in the next cycle) by doing as much as we can in the image creation time.

That’s what I meant with “pre-installing” in the sense that snaps are completely good-to-go once the image is built – if that is even possible?