Snappy on RPi 2 Certificate Bug -- and other thoughts...

Louis St-Amour louisstamour at
Sun Feb 15 19:48:38 UTC 2015

Hi all,

Not sure what the correct channel is to report this, but if you Google
around you'll notice on Reddit and RPi forums that folks like myself are
picking Ubuntu Core in part because it seems easy to install Docker.

But you'll encounter two issues. The first is that default Snappy images
for the Raspberry Pi do not have NTP enabled and well, the Raspberry Pi
doesn't seem to have a default system clock set out of the box. ;-)

So once you get past not knowing that the default username is ubuntu/ubuntu
you then encounter a mysterious certificate error to which the fix is to
use "sudo date MMDDhhmmYYYY" to set the time to the current time. And you
have to do this each time you start the dang thing, which does not make
this easy!

I only discovered "webdm" when I googled 'ubuntu "webdm"' and Google
initially thought I was searching for webmd ;-) From there, visiting
http://webdm.local:4200/ was cool.

I see this is build number 2, and there's not even a dozen apps in the
store, so this is just getting started on ARM. But I really like this
approach. It's just NTP that's missing from making this a usable system. If
NTP is seen as "too much bloat" ;-) well, perhaps there could be an NTP ARM
package added to the store, and like webmd, this could be included by
default in the image?

Okay, here ends the consise feedback. What follows is more of a "stream of
consciousness" on the project as an outsider:

Just doing an ls /usr/bin reveals that this install of ubuntu core, at
least, seems far from small. It appears to include dpkg, perl and two
copies of python, which I guess are dependencies for other commands, like
ubuntu-core-config? I've no idea what that does, it just prints something
like timezone: UTC if I give it the -d command. Seems far more overkill to
bundle two copies of python and a perl interpreter unless it's needed by
drivers and things. I see by the logs left in /var/log that this was once a
more full-featured install, then packages were removed via apt-get, etc.

It also surprised me that the download was over 700MB given it was a
minimal install, but I suppose that was the nature of packaging it as a 3GB
disk image. The total in use is 768M, 8.5M, 27M, 4K and 60M, so excluding
all the zeros, somewhere around 82% compression. Of this, 575MB is the /lib
folder and 128M is /usr. Most of /lib judging by folder names is just
kernel drivers and features. (It can speak Appletalk!) So I guess it really
is quite minimal for a stock system, but I could see a future where, as an
embedded systems author, I might want to make my own distribution of Core
with unnecessary files removed and maybe some other drivers pre-installed?

I really like the read-only approach, but I'd almost want to build my own
Ubuntu image with my app pre-installed on the read-only partition, such
that deploying new apps then becomes installing a new OS and rebooting. As
it stands now, I can see that this project will make /apps read-only, but
it's concerning to read that currently, apps make the folder on
installation: ... it
seems like another answer would be to use a Packer-style tool to make a
read-only OS image that includes just the apps you'd want. Or deploy a new
apps partition, a/b style, the advantage being that to switch partitions
you'd only need to have the OS restart the apps instead of restarting the
entire OS? Actually, now that I think about it, you could do a graceful
restart from one app partition to the next, rather than today's "stop the
universe, update, then start it again..." It'd have to be the app's job to
fully support such a scenario, since ideally the old and new versions of
the app could run and briefly co-exist during the handover. Alternatively,
move it down the stack and deploy apps using a framework that supports such
behavior, I suppose.

Well, thanks for reading this far! ;-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the snappy-devel mailing list