Recovering Ubuntu Core

Introduction A note of caution, most of this is an experiment and lacks finess. Ubuntu Core was released over half a year ago using this nice thing called snappy, the design allows for transactional updates among others, these updates keep on rolling though their streams and can be kicked out (rolled back) if something was fishy, guaranteeing a certain level of confidence that the system should not break. Now introduce the concept of storage, that thing that will always limit you no matter the amount; with this consider that a popular method to avoid this is to garbage collect, old things you forgot about will just go away.

Grub and snappy updates

This week, the snappy powered Ubuntu Core landed some interesting changes with regards to how it handles grub based systems. History The original implementation was based on traditional Ubuntu systems, where a bunch of files that any debian package could setup influenced the resulting grub.cfg that resulted after running update-grub. This produced a grub.cfg that was really hard to manage or debug, and what is most important, out of our control.

The github or launchpad dilemma

We wanted to start a migration path from bazaar to git given how ubiquitous it is and due to the fact that most in our team prefer it. A few months ago the decision was easy, since launchpad did not support git, we would just switch to github given it’s popularity. That’s not true anymore… Today launchpad supports git and our comparison becomes finer grained and we have to break it down a bit more.

Snappy rolling back on kernel panic

Image you get an update and the kernel panics with that update, what are you to do? Suppose now that you have a snappy based system, this is automatically solved for you. Here’s a short video showing this on a Beagle Bone Black, the concept is quite simple, if there is a panic, we revert to the last known state. In this video I inject an initrd that panics on boot after issuing a snappy update and before rebooting into the update.

Updates to snappy and ubuntu-device-flash

The past few weeks in the snappy world have been a revolt, better said a rapid evolution for it to be closer to what we wanted it to be. Some things have change, if you are tracking the bleeding edge you will notice a couple of changes, the store for example now exposes packages depending on the OS release, and system images are now built against an OS release as well.

Preliminary support for dtb override from OEM snaps

Today the always in motion ppa ppa:snappy-dev/tools has landed support for overriding the dtb provided by the platform in the device part with one provided by the oem snap. The package.yaml for the oem snap has been extended a bit to support this, an example follows for extending the am335x-boneblack platform. name: mydevice.sergiusens vendor: sergiusens icon: meta/icon.png version: 1.0 type: oem branding: name: My device subname: Sergiusens Inc. store: oem-key: 123456 hardware: dtb: mydtb.dtb The path hardware/dtb key in the yaml holds a value which is the path to the dtb withing the package, so in this case, I put mydtb.dtb in the root of the snap.

Snappy Things

A while back, Snappy was introduced and it was great, while that was happening we were already working on the next great thing, Snappy for devices, or as everyone calls it, things. Today that was finally announced. It’s been lots of fun working on this. Enablement aside, we also created a very minimal webdm, it is a Web Device Management snap framework provided in the store which can be easily installed on existing devices by calling sudo snappy install webdm On networks where it is allowed, it can be accessed by going to http://webdm.local:4200.

Ubuntu Core

Ubuntu Core is what we’ve been working on this past time, it has been an interesting ride. It was developed completely in the open, there was just no real promotion about it until we were ready. If you had noticed, we use ubuntu-device-flash to create this core image, and for development we used it across the board with the core subcommand. We did learn a couple of things from the phone and decided to just provide a static image that we could make sure would work for everyone giving it a try (aka more QA).

Travis and ruby gems setup on Ubuntu

Quick install Most of the instalation instructions that dangle the web just make you sudo gem install, I don’t like that, so here’s the quick reference for when I need to do this next time: sudo apt install ruby-dev export GEM_HOME=$HOME/gems gem install travis -v 1.7.4 --no-rdoc --no-ri And this goes into ~/.bashrc: export GEM_HOME=$HOME/gems export PATH=$PATH:$GEM_HOME/bin