Baserock 15.19 is released
The Baserock reference systems are defined using version 3 of the definitions format. In 15.10, version 0 was used.
The Baserock project is still discussing how to handle introducing incompatible changes to the Baserock definitions format.
The baserock-15.19 tag of definitions.git cannot be built with Morph from baserock-15.10. You will need to use the 'baserock-definitions-v3' tag of Morph, or a newer version. In order to upgrade, you can update Morph to tag 'baserock-definitions-v3' manually in your 'build' systems. See: http://wiki.baserock.org/using-latest-morph/. Alternately, x86 users can download one of the reference systems from the 15.17-rc release and use that to build 15.19.
The version of Morph in Baserock 15.19 can build definitions versions 0, 1, 2 and 3.
Read more about the definitions format here: http://wiki.baserock.org/definitions.
The 15.17-rc release announcement can be found here: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-April/012978.html
User interface changes
morph distbuild and
morph distbuild-morphology commands no
longer cancel the running build when they exit. You must use the new
distbuild-cancel command to stop the builds now. You can use
distbuild-list-jobs to find out what builds are running on a distbuild
There are many other new commands Morph commands available in this release, see below for details.
Morph in Baserock 15.19 can only be used with distbuild networks that use Morph from Baserock 15.19.
NOTE: There are critical distbuild bugs in the version of Morph used in the 15.19 reference systems. If you want use 'distbuild', you must update to the baserock-15.19.2 tag, which contains an updated version of Morph.
Switching virtual terminals doesn't work correctly in some cases when
vga=xx is passed to Linux to set up a framebuffer device at boot time.
We are not sure why this is broken yet.
The systemd unit 'systemd-sysctl.service' fails at boot time, causing
systemctl status to mark the system as degraded. This failure can be
ignored, there is no sysctl config specified in the reference systems in
any case. We have not fully investigated why the unit fails yet.
We tested out GCC 5.1 during this release cycle and discovered that it causes SYSLINUX to break: x86 systems deployed from a system built with GCC 5.1 hang in the bootloader. Updating SYSLINUX doesn't seem to fix this. We recommend that you stick with GCC 4.9.2 right now.
All changes since 15.10
openstack-system-x86_64system which allows building an OpenStack cloud using Baserock tooling. Many OpenStack services from the Juno release (tag 2014.2.1) are supported: Ceilometer, Cinder, Glance, Horizon, Ironic, Neutron, Nova, Keystone, and Swift. There are several example deployment .morph files as well. See http://wiki.baserock.org/guides/openstack-on-baserock/ for documentation.
Improvements to bare-metal (non-virtualised) deployments of Baserock on x86 and ARM. In particular, the released x86_64 images now have an initramfs, which should make it possible to run them from a USB stick.
System and BSP definitions for big-endian ARMv8 architecture (armv8b64), and support for deploying these to a HP Moonshot server.
Updates to NVIDIA Jetson specific components. There is a new documented method for flashing Baserock images to the built-in eMMC on a Jetson: http://wiki.baserock.org/guides/baserock-jetson/
Jetson systems now use Mesa 10.5.4. x86 systems still use a patched version of 10.3.7, so that gallium-egl is available: that driver is needed to use Weston in a VM.
PAM is now configured to use SHA512 instead of DES for password hashes. This fixes a security issue as DES truncates passwords, so only the first part of a password would be checked.
Component additions, including:
- bash-completion (command autocompletion for GNU Bash)
- Django (web framework)
- Erlang (compiler and runtime)
- git-review (helper tool for working with Gerrit)
- GNU Parted (partition management tool)
- OCAML (compiler)
- OpenStack Ansible modules
- OSTree (operating system binary storage)
- pylint (Python style checker)
- RabbitMQ (messaging system)
- tcpdump (network traffic inspection tool)
- unionfs-fuse (FUSE-based union file system)
Component updates, including:
- ATK 2.16.0
- Busybox 1.23.1
- Ceph 0.94
- CMake 3.2.1
- D-Bus 1.8.16
- GLib 2.44.0
- GNU GLIBC 2.21
- GNU Nano
- GObject Introspectrion 1.44.0
- GTK+ 2.24.27 and 3.16.0
- libdrm 2.4.60 (plus patches for NVIDIA Jetson)
- libpng 1.4.16
- libxslt commit 73e08bf7c36a (v1.1.28-36-g73e08bf)
- Linux 4.0
- ntpd 4.2.8p2
- OpenSSL 1.0.1m
- Qt 5.4.0
- systemd commit 163ab2961268232e1c (v219-729-g163ab29)
- util-linux 2.16.1
- Vala 0.28.0
- X.Org X server 1.17.1
Changes to the default Linux kernel config to allow LVM snapshots, overlayfs, XFS and many networking features required by OpenStack and KVM.
install-essential-files.configureextension for providing configuration files required for all systems. The
essential-files/directory of definitions.git contains some important files already, which should fix some annoyances in GNU Bash among other things.
systemd user sessions are now supported.
Linux is downgraded to 3.15.10 for Calxeda Highbank systems, as a workaround for a hang in later kernels (probably due to the old version of U-Boot in use on such servers).
GNU Tar is now in the 'coreutils-common' stratum (was in 'webtools').
rsync is now in the 'foundation' stratum (was in 'tools'). This allows the reference upgrade mechanism to be used in more systems. See http://wiki.baserock.org/guides/upgrades/ for more information about the reference upgrade mechanism.
Several chunks have been moved into their own strata. This makes the Baserock reference system definitions more granular. New strata include: libsoup, python-cliapp, python-pygobject, python-wsgi
The Gerrit and Gitlab systems have been removed from definitions.git. Gitlab is no longer supported in Baserock (it was not maintained for a long time already). Gerrit is fully supported and now lives in infrastructure.git.
Updates to Morph, the tool used to build Baserock systems. Improvements include:
Support for new architectures: armv5l, mips32b, mips32l, mips64l, mips64b (Baserock definitions format version 3)
morph anchorcommand, which creates tags in each chunk repo to ensure that the commits used in a built system will not be deleted by
git gc, even if the branch containing them is deleted or force-updated.
morph certifycommand, which checks that a build will be fully reproducible. See
morph help certifyfor details.
morph generate-manifest-csvcommand, which attempts to work out the license, version number and upstream source URL of each component in a given system. The existing
morph generate-manifestcommand, which was GENIVI-specific, is now called
morph get-chunk-detailscommand to show remote URL and ref for a given chunk in a system, and
morph get-repocommand to clone a chunk repo from Morph's local cache.
morph show-build-logcommand to fetch a build-log of a chunk from the configured Trove, or other shared artifact cache.
--verboseoption now shows the build logs on stdout, instead of detailed Morph log info. A new
--debugoption behaves like the old
New distbuild-trove-nfsboot.write extension, which replaces the deprecated nfsboot.write extension for the specific case of deploying distbuild networks using NFS.
New hosts.configure extension, for adding entries into /etc/hosts at deploy time.
New ssh-keys.configure extension, for adding an SSH public key to
/root/.ssh/authorized_keysin a deployed system.
Support for 'partial building': building only up to a specific chunk, without building the full system that contains it.
morph upgradecommand will now honour the 'upgrade-location' and 'upgrade-type' fields from a cluster .morph file, if present. This means you can use the same .morph file for both initial deployments and upgrades.
Morph will now raise an error if a stratum points to a non-existant .morph file for a chunk. Previously it would silently ignore these. This change marks Baserock definitions format version 2.
New commands for working with Morph 'distbuild' networks:
morph distbuild-start: runs a build and detaches straight away.
morph distbuild-cancel: cancels a running build.
morph distbuild-status: shows if a build is running, or has succeeded or failed.
morph distbuild-list-jobs: shows all builds in progress on a distbuild network.
morph distbuild-morphologycommands now longer cancel the build when they exit. This means that builds do not stop if your network connection to the distbuild network breaks, or you hit Ctrl+C. You must always use
morph distbuild-cancelto cancel builds now.
Updates to Morph's 'distbuild' plugin, which allows distributing builds across multiple machines. Lots of performance and stability improvements, including:
Builds no longer get 'stuck' in the 'transferring artifacts' stage.
Speedups to the 'Computing build graph' stage of distbuild (best case is now about 10 seconds, down from 30-60), and to stratum building (best case is now about 5 seconds, down from 35)
Cancelled builds should now actually stop when cancelled.
Build logs are now stored in subfolders of the current directory named build-00, build-01, build-02, etc. by default. Previously they were put in the current directory. The log files also now note when a build was cancelled by the user.
Lorry Controller, the mirroring tool used in Trove, now supports mirroring into the Gerrit git server, in additition to the Gitano git server.
Thanks to everyone who has provided code, documentation, sponsorship or feedback for this Baserock release!
How do I get started?
Start with the following page: http://wiki.baserock.org/quick-start/
Those who are up to speed with Baserock already can make use of the
'cache.baserock.org' cache server, with the
http://cache.baserock.org:8080/ option. All artifacts necessary to
upgrade a 'build' system for x86_32, x86_64 or armv7lhf (Jetson) are
present in this cache.
How do I get in contact?
- IRC: freenode #baserock
- Public mailing list: email@example.com
- See also: http://wiki.baserock.org/mailinglist/
If you find a bug in Baserock, we'd like to hear from you using one of the above methods.
The Baserock project welcomes new participants! We hope you enjoy experimenting with Baserock and look forward to hearing about any cool things you do with Baserock.