![]() This will take a while as it’ll need to download files from those external servers, repack some bits but once it’s done, you’ll have a new image published. To generate your first image, simply run “bin/import-images”. Lastly we need to actual create the channel and device in the server, this is done by calling “bin/si-shell” and then doing: pub.create_channel("test")įor keyring in ("archive-master", "image-master", "image-signing", "blacklist"):Īnd that’s it! Your server is now ready to use. This channel will contain up to 15 images and will start at image ID “1”.ĭoing all this can be done with that bit of configuration (you’ll need to change your server’s FQDN accordingly) in etc/config: įiles = ubuntu, device, custom-savilerow, keyring, versionįile_ubuntu = remote-system-image trusty-proposed ubuntuįile_device = remote-system-image trusty-proposed device keyring=archive-masterįile_custom-savilerow = http name=custom-savilerow,monitor= It’ll mirror both the ubuntu and device tarball from the main public server (using the trusty-proposed channel over there), repack the device tarball to swap the GPG keys, then download a customization tarball from an http server, stack a keyring tarball (overriding the keys in the ubuntu tarball) and finally generating a version tarball. We’ll define a single “test” channel which will contain a single device “mako” (nexus4). That being done, now let’s grab the server code, generate some keys and run the testsuite: bzr branch lp:~ubuntu-system-image/ubuntu-system-image/server system-image Then setup the web server: sudo adduser $USER www-data If you are doing this for testing only and don’t care much about getting strong keys, you may want to install “haveged” too. You’ll need a fair amount of available entropy to generate all the keys used by the test suite and production server. Python-gnupg fakeroot pxz pep8 pyflakes python-mock apache2 Install some required packages: sudo apt-get install -y bzr abootimg android-tools-fsutils ![]() ![]() Those instructions have been tried on a clean Ubuntu 13.10 cloud instance, it assumes that you are running them as an “ubuntu” user with “/home/ubuntu” as its home directory. ![]() We plan on having this resolved in the system-image client soon. This may be a problem to some porters who don’t have a separate IP for their server or can’t afford an SSL certificate. It’s now reasonably easy to setup your own server, have it mirror some bits from the main public server, swap GPG keys and include your local tarballs.īefore I start with step by step instructions, please note that due to bug 1278589, you need a valid SSL certificate (https) on your server. This was finally resolved on Friday when I landed the code for a few new file generators in the main system-image server branch. Up until now, doing this was pretty tricky as there wasn’t an easy way to import files from the public system-image server into a local one nor was there a simple way to replace the official GPG keys by your own (which would result in your updates to be considered invalid). Using it as an internal buffer/mirror for your devices.QA infrastructure for Ubuntu Touch images.Publishing your own customized version of an official image.Supporting your own Ubuntu Touch port with over-the-air updates.There are a lot of reasons why you may want to run your own system-image server but the main ones seem to be: custom: Customization tarball (applied on top of the root filesystem in /custom)įor more details on how this all works, I’d recommend reading our wiki pages which act as the go-to specification for the server, clients and upgrader.device: Device specific data (partition images and Android image).ubuntu: Ubuntu root filesystem (common to all devices).The current list of tarballs we tend to use for the official images are: Partition images are stored in binary format in a partitions/ directory which the upgrader checks and flashes automatically. It has a list of files to remove and the rest of the files are simply unpacked on top of the existing system.ĭelta images only contain the files that are different from the previous image, full images contain them all. At the end of the line, the upgrader simply mounts the partitions and unpacks the tarball in the order it’s given them. We build new images on our build infrastructure, generate diffs between images and publish the result on the public server.Įach image is made of a bunch of xz compreseed tarballs, the actual number of tarballs may vary, so can their name. The default update mechanism is therefore image based. For those not yet familiar with this, Ubuntu Touch systems are setup using a read-only root filesystem on top of which writable paths are mounted using bind-mounts from persistent or ephemeral storage.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |