[PATCH 0/3] Add a script to manage parallel Baserock versions.
by Pedro Alvarez
Repo: ssh://git@git.baserock.org/baserock/baserock/tbdiff.git
Ref: baserock/pedroalvarez/system-version-manager
Sha1: 64e06939bfa2f75208e8a22e6c50c98e5afbef4c
Card: S10393
New script needed for the upgrades to handle parallel versions
and allow the user to choose a system to boot.
With this script the user will be able to boot the old system
with the old kernel if the new system doesn't boot.
Pedro Alvarez (3):
Fix error in the baserock-system-config-sync behaviour table
Add script to modify the bootloader and manage different paralell OS.
Use system-version-manager in bserock-system-config-sync.
Makefile.am | 3 +-
.../baserock-system-config-sync | 9 +-
configure.ac | 3 +-
system-version-manager/Makefile.am | 20 ++
system-version-manager/system-version-manager | 280 ++++++++++++++++++++
5 files changed, 309 insertions(+), 6 deletions(-)
create mode 100644 system-version-manager/Makefile.am
create mode 100755 system-version-manager/system-version-manager
--
1.7.10.4
9 years, 2 months
[PATCH 0/7] Baserock chroot tool for Ubuntu/Debian
by Daniel Silverstone
Repo: baserock:baserock/baserock-chroot
Ref: master
SHA1: 3afd811f205cdf25d8de595624f3a8ad8dc3522f
Note, this is not a patch series *against* master but rather what is currently
on master.
This is a new project to support running Baserock chroots on Debian/Ubuntu
hosts. I believe it should work on Fedora hosts as well but I've not done
packaging for that.
If you've not done Debian packaging before, you can ignore that entry entirely.
If you're not familiar with schroot then some of the behaviours of
br-ct-sync-chroots might seem odd.
I have tested this on Debian/Wheezy/amd64 and on Xubuntu/12.04/i386
Thanks,
Daniel.
Daniel Silverstone (7):
Add chroot sync tool
Add tool to simplify entering baserock chroots
Add tool to simplify managing baserock chroots
Add GPLv2 headers to top of scripts
Add a makefile
Add Debian-style packaging rules
Add packaging rule to Makefile
Makefile | 17 +++++
br-ct-sync-chroots | 121 ++++++++++++++++++++++++++++++++++
debian/baserock-chroot.postinst | 5 ++
debian/baserock-chroot.prerm | 5 ++
debian/changelog | 6 ++
debian/compat | 1 +
debian/control | 13 ++++
debian/rules | 4 ++
enter-baserock | 41 ++++++++++++
manage-baserock | 136 +++++++++++++++++++++++++++++++++++++++
10 files changed, 349 insertions(+)
create mode 100644 Makefile
create mode 100755 br-ct-sync-chroots
create mode 100644 debian/baserock-chroot.postinst
create mode 100644 debian/baserock-chroot.prerm
create mode 100644 debian/changelog
create mode 100644 debian/compat
create mode 100644 debian/control
create mode 100755 debian/rules
create mode 100755 enter-baserock
create mode 100755 manage-baserock
--
1.7.10.4
9 years, 2 months
[PATCH 00/13] V3: Changes to Morph required for upgrades
by Sam Thursfield
Repo: git://git.baserock.org/baserock/baserock/morph.git
Ref: upgrades-v3
Sha1: ba722fc08d0a3a59a169a4e3a125ab416b94363b
The major change in V3 is that configure extensions now run when
deploying upgrades. If you need an extension to behave differently when
deploying an upgrade (this is the case for trove.configure for example,
as we only want trove-early-setup to run once within the lifetime of a
Trove) you can check `if [ "$UPGRADE" == "yes" ]` or similar in the
extension.
Note that the upgrades are deployed client-side using the
system-version-manager tool, so any system you are deploying as an
upgrade needs to contain that tool.
The following two changes I did not have time to do, but would like to do in
the future:
- report progress and status from 'system-version-manager' and
'baserock-system-config-sync' when deploying an upgrade.
- move the checks that we are deploying to a valid target into .check
extensions, so that a bad `morph deploy` will fail earlier.
- split .upgrade extensions out from .write
- tidy up yarns/deployment.yarn
As before, branch was tested using the system tests in
git://git.baserock.org/baserock/baserock/system-tests, which build the
baserock/sam/trove-upgrades system branch right now. (Next step is to merge the
contents of that system branch).
Pedro Alvarez (1):
Adding syslinux 'menu.c32' file during the deployment.
Sam Thursfield (12):
deploy: Add new --upgrade option
deploy: Finish off the Btrfs system layout implementation
Don't create a blank /etc/fstab
deploy: Depend on client OS version manager to deploy upgrades
deploy: Honour AUTOSTART in ssh-rsync extension
Make parse_autostart() into more general get_environment_boolean()
deploy: Add optional 'check' extensions
deploy: Check the --upgrade flag has been used correctly.
deploy: Fix double exception in rawdisk.write
deploy: Add upgrading to deployment.yarn
yarns: Set PYTHONPATH when running Morph
morphlib/builder2.py | 25 ---
morphlib/cachekeycomputer.py | 2 +-
morphlib/exts/kvm.check | 35 ++++
morphlib/exts/kvm.write | 4 +-
morphlib/exts/nfsboot.check | 34 ++++
morphlib/exts/openstack.check | 35 ++++
morphlib/exts/rawdisk.write | 7 +-
morphlib/exts/ssh-rsync.check | 36 ++++
morphlib/exts/ssh-rsync.write | 142 ++++++----------
morphlib/exts/tar.check | 24 +++
morphlib/exts/virtualbox-ssh.check | 35 ++++
morphlib/exts/virtualbox-ssh.write | 2 +-
morphlib/plugins/deploy_plugin.py | 29 +++-
morphlib/writeexts.py | 204 +++++++++++++++++------
tests.as-root/tarball-image-is-sensible.stdout | 1 -
tests.build/bootstrap-mode.stdout | 1 -
tests.build/build-stratum-with-submodules.stdout | 1 -
tests.build/build-system.stdout | 1 -
yarns/deployment.yarn | 30 +++-
yarns/implementations.yarn | 10 ++
yarns/morph.shell-lib | 2 +-
21 files changed, 480 insertions(+), 180 deletions(-)
create mode 100755 morphlib/exts/kvm.check
create mode 100755 morphlib/exts/nfsboot.check
create mode 100755 morphlib/exts/openstack.check
create mode 100755 morphlib/exts/ssh-rsync.check
create mode 100755 morphlib/exts/tar.check
create mode 100755 morphlib/exts/virtualbox-ssh.check
--
1.8.5.3
9 years, 2 months
[PATCH] Proof of concept cross compiling system morphology
by Richard Maw
Repo: git://git.baserock.org/baserock/baserock/definitions.git
Ref: baserock/richardmaw/S10442/cross-toolchain
SHA1: f8a37cd9aab241e3bba872a7da5ee35867ce4e4a
Land: origin/master
This is a system that contains a cross compiler to build for armv7lhf.
It currently works, though there's a couple of changes I'd like to try
to make the morphologies simpler.
It has a few architectural pit-falls, that I'd like to fix some day:
* The sysroot requires the version of eglibc to be exactly the same as
the one we aim to build binaries for, so until there's some way of
pinning the two to the same thing, it's a social problem to keep them
at the same version.
* A bunch of other software needs to be cross-compiled to usefully target
the final system for full application development. These also need to
be pinned to exactly the same version, or include a development variant
of the target system at /usr/armv7lhf-baserock-linux-gnueabi/sys-root,
so the included gcc can find all the libraries and headers.
If it were possible to include this system at build-time, then the
cross-compiler stratum would trivially be just the gcc and binutils
targetting that sysroot and compiled to have the right --host and
--target set.
* It's a bunch of repeated work to cross-compile to various architectures,
some form of parameterised stratum morphologies would make this easier.
Richard Maw (1):
Add morphologies for armv7lhf cross system
...lhf-cross-toolchain-system-x86_64-generic.morph | 15 +++++++++
armv7lhf-cross-toolchain.morph | 37 ++++++++++++++++++++++
2 files changed, 52 insertions(+)
create mode 100644 armv7lhf-cross-toolchain-system-x86_64-generic.morph
create mode 100644 armv7lhf-cross-toolchain.morph
--
1.8.5.rc2
9 years, 2 months
[PATCH 0/3] Prevent baserock-system-config-sync of doing reverse patching.
by Pedro Alvarez
Repo: ssh://git@git.baserock.org/baserock/baserock/tbdiff.git
Branch: baserock/pedroalvarez/bscs-wrong-merge2
Sha1: baserock/pedroalvarez/bscs-wrong-merge2
Card: S10472
baserock-system-config-sync was doing a reverse patching
when v1 exists, and vu == v2.
With this patch series we solve the problem, and also we add a test.
run_test.sh:
Fixed the test, the shell code was doing something weird.
Pedro Alvarez (3):
Add test case for vu == v2 in 'baserock-system-config-sync'
Fix baserock-system-config-sync tests. Wasn't working as expected.
Prevent patching when 'vu == v2' in 'baserock-system-config-sync'.
.../baserock-system-config-sync | 21 ++++++++++++++------
.../upgrades.in/systems/factory/orig/etc/file8 | 2 ++
.../upgrades.in/systems/factory/run/etc/file8 | 2 ++
.../upgrades.in/systems/version2/orig/etc/file8 | 2 ++
.../upgrades.in/systems/version2/run/etc/file8 | 2 ++
.../upgrades.out/systems/factory/orig/etc/file8 | 2 ++
.../upgrades.out/systems/factory/run/etc/file8 | 2 ++
.../upgrades.out/systems/version2/orig/etc/file8 | 2 ++
.../upgrades.out/systems/version2/run/etc/file8 | 2 ++
tests/run_tests.sh | 7 ++-----
10 files changed, 33 insertions(+), 11 deletions(-)
create mode 100644 tests/bscs-merge.pass/upgrades.in/systems/factory/orig/etc/file8
create mode 100644 tests/bscs-merge.pass/upgrades.in/systems/factory/run/etc/file8
create mode 100644 tests/bscs-merge.pass/upgrades.in/systems/version2/orig/etc/file8
create mode 100644 tests/bscs-merge.pass/upgrades.in/systems/version2/run/etc/file8
create mode 100644 tests/bscs-merge.pass/upgrades.out/systems/factory/orig/etc/file8
create mode 100644 tests/bscs-merge.pass/upgrades.out/systems/factory/run/etc/file8
create mode 100644 tests/bscs-merge.pass/upgrades.out/systems/version2/orig/etc/file8
create mode 100644 tests/bscs-merge.pass/upgrades.out/systems/version2/run/etc/file8
--
1.7.10.4
9 years, 3 months
IPMItool version at git.baserock.org
by Paul Sherwood
Hi folks
I notice that the latest IPMItool source at sourceforge is 1.8.13, but
g.b.o has various tags around 1.8.11 - are we missing something?
br
Paul
9 years, 3 months
Couple of questions about stratum splitting...
by Paul Sherwood
Hi
I decided to try splitting and building a system with runtime strata
(my system morph file and some log info attached), and have a couple of
questions...
- is be possible to bring default rules all the way up to the system,
to save having to specify
artifacts:
- foo-runtime
for every stratum?
- in my genivi example, the build still seems to create devel versions
of most of the strata:
[build-essential-runtime]
[build-essential-devel]
[core-runtime]
[core-devel]
[foundation-runtime]
[foundation-devel]
[genivi-foundation-runtime]
[bsp-x86_64-generic-runtime]
[genivi-foundation-devel]
[connectivity-runtime]
[audio-bluetooth-runtime]
[x-common-runtime]
[x-common-devel]
[x-x86_64-generic-runtime]
[audio-bluetooth-devel]
[multimedia-runtime]
[genivi-runtime]
is that just unavoidably because higher strata require the lower ones
for building? in other words, they are built, but not included in the
image?
- in my example the comparative sizes are
1730314240 system.genivi-baseline-system-x86_64-generic-rootfs (normal
version)
1332971520 system.genivi-baseline-system-x86_64-generic-rootfs (split
runtime version)
Does this seem right? I was hoping for a more dramatic reduction :)
br
Paul
9 years, 3 months
[PATCH] Don't set a default /etc/hostname
by Sam Thursfield
Repo: git://git.baserock.org/baserock/baserock/fhs-dirs
Ref: baserock/sam/no-default-hostname
Sha1: 442e2a6453ec380bf9d64f6be50e57d54ddf93d3
I have tested that both trove-system and base-system build
successfully. I also deployed the base system with no /etc/hostname
and verified that networking (ping) and general socket communication
(DBus) work when there's no /etc/hostname. I'm happy to run other tests
if anyone thinks this might break something.
Sam Thursfield (1):
Don't set a default /etc/hostname
fhs-dirs.morph | 1 -
stage2-fhs-dirs.morph | 1 -
2 files changed, 2 deletions(-)
--
1.8.5.3
9 years, 3 months
[PATCH 00/12] Changes to Morph required for upgrades
by Sam Thursfield
Repo: git://git.baserock.org/baserock/baserock/morph
Ref: upgrades
Sha1: 65ed6ba337b5d08d1e1b9b213912e9fc92bea5dc
Here are the changes to Morph required to build an upgradable Trove system.
There are some changes to the system required too which are in the
system-branch 'baserock/sam/trove-upgrades'. I'll send that for review
separately, but it's pushed already if you want to use it to test this branch.
Upgrades are deployed using a cluster morph, as with initial deployments.
Additionally there is a new '--upgrade' flag to `morph deploy`. Morph cannot
otherwise differentiate between an upgrade and an initial deployment because
this is write extensions specific, and write extensions are 'black boxes' from
Morph's point of view. Requiring the user to be explicit is more predictable
and robust in any case.
Configuration extensions are not run when upgrading an existing system. It
seems silly to require the user to provide information on every upgrade that is
already installed on the system they are upgrading. It would be very, very
difficult allow varying the configuration on upgrade using configure
extensions, as some configuration extensions defer work to first-boot.
This does mean that changes made to the base OS by config extensions will be
lost after the first upgrade. We should prevent config extensions from writing
inside directories that do not hold system state or user data, because it seems
to me that the base OS should be built from chunks and chunks only. Configuring
a Baserock system should never require writing to files in /lib, /bin or /usr.
We have introduced a new tool to manage multiple base OS versions inside a
Baserock system. It's in git://git.baserock.org/baserock/baserock/tbdiff.git
right now and named 'snapshot-mgr'. This should change. Myself & Pedro think
'baserock-version' would be a good name for the tool, so you run
'baserock-version set-default', 'baserock-version deploy', etc. What do you
think?
We are working on whole-system integration tests for this functionality at
git://git.baserock.org/baserock/baserock/system-tests.git.
Pedro Alvarez (1):
Adding syslinux 'menu.c32' file during the deployment.
Sam Thursfield (11):
deploy: Add new --upgrade option
deploy: Don't run configuration extensions for upgrades
deploy: Finish off the Btrfs system layout implementation
Don't create a blank /etc/fstab
deploy: Depend on client OS version manager to deploy upgrades
deploy: Honour AUTOSTART in ssh-rsync extension
Make parse_autostart() into more general get_environment_boolean()
deploy: Add optional 'check' extensions
deploy: Check the --upgrade flag has been used correctly.
deploy: Fix double exception in rawdisk.write
deploy: Add upgrading to deployment.yarn
morphlib/app.py | 7 +
morphlib/builder2.py | 25 ----
morphlib/cachekeycomputer.py | 2 +-
morphlib/exts/kvm.check | 35 +++++
morphlib/exts/kvm.write | 4 +-
morphlib/exts/nfsboot.check | 34 +++++
morphlib/exts/openstack.check | 35 +++++
morphlib/exts/rawdisk.write | 5 +-
morphlib/exts/ssh-rsync.check | 36 +++++
morphlib/exts/ssh-rsync.write | 122 +++++-----------
morphlib/exts/tar.check | 24 ++++
morphlib/exts/virtualbox-ssh.check | 35 +++++
morphlib/exts/virtualbox-ssh.write | 2 +-
morphlib/plugins/deploy_plugin.py | 43 ++++--
morphlib/writeexts.py | 172 ++++++++++++++++-------
tests.as-root/tarball-image-is-sensible.stdout | 1 -
tests.build/bootstrap-mode.stdout | 1 -
tests.build/build-stratum-with-submodules.stdout | 1 -
tests.build/build-system.stdout | 1 -
yarns/deployment.yarn | 30 +++-
yarns/implementations.yarn | 10 ++
21 files changed, 437 insertions(+), 188 deletions(-)
create mode 100755 morphlib/exts/kvm.check
create mode 100755 morphlib/exts/nfsboot.check
create mode 100755 morphlib/exts/openstack.check
create mode 100755 morphlib/exts/ssh-rsync.check
create mode 100755 morphlib/exts/tar.check
create mode 100755 morphlib/exts/virtualbox-ssh.check
--
1.8.5.3
9 years, 3 months
[PATCHv2 0/2] Improving test an behaviour of baserock-system-config-sync
by Pedro Alvarez
Repo: ssh://git@git.baserock.org/baserock/baserock/tbdiff.git
Branch: baserock/pedroalvarez/bscs-upgrade-tests
Sha1: 80272bdb18dcc2531db2553665adb97c436706c7
Card: S10264
GNU patch seems to have a bug when it's used on the way we used it.
This patch is to check in the test suite of baserock-system-config-sync
if the bug is happening. And also to change the way we are using the
'patch' command to make the bug not happen.
This patch series is totally different to the previous one, that is
why I decided to not link it to the previous thread.
Pedro Alvarez (2):
Update 'baserock-system-config-sync' tests to check permissions
Modify the way to use 'patch' in 'baserock-system-config-sync'.
.../baserock-system-config-sync | 6 +++--
.../systems/version2/run/etc/file7.orig | 2 ++
tests/run_tests.sh | 23 ++++++++++++++++++--
3 files changed, 27 insertions(+), 4 deletions(-)
create mode 100644 tests/bscs-merge.pass/upgrades.out/systems/version2/run/etc/file7.orig
--
1.7.10.4
9 years, 3 months