| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|\
| |
| |
| | |
Reviewed-by: Sam Thursfield
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This is needed because now pxeboot.check doesn't fail if the options
specified in the environment match more than one mode.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code was assuming that if there are more than one complete_match
we were setting more options that needed and this is not always true.
For example when setting 'PXEBOOT_DEPLOYER_INTERFACE' and 'PXEBOOT_VLAN',
there will be more than one complete_matches, given that these options match
the spawn-vlan and the spawn-novlan modes.
My workaround consists on report warning messages instead of failing when
this happens.
The reason that I haven't removed the code is that I think that it could
be fixable. For now this code will report "warnings" instead of failing.
|
| | |
|
|/
|
|
|
|
| |
Add ipmitool to strata/tools.morph
Ipmitool is needed to use pxeboot.write extension
|
|\
| |
| |
| |
| | |
Reviewed-by:
- Pedro Alvarez
|
|/
|
|
|
| |
The tool is now run at build-time (to generate a 'man' page) so its
runtime dependencies need to be available in the staging area.
|
|\
| |
| |
| |
| | |
Reviewed-By: Richard Dale <richard.dale@codethink.co.uk>
Reviewed-By: Paul Sherwood <paul.sherwood@codethink.co.uk>
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Reviewed-By: Richard Dale <richard.dale@codethink.co.uk>
Reviewed-By: Paul Sherwood <paul.sherwood@codethink.co.uk>
|
|\ \
| | |
| | |
| | |
| | | |
Reviewed-By: Jim MacArthur <jim.macarthur@codethink.co.uk>
Reviewed-By: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
|
| | | |
|
| | |
| | |
| | |
| | | |
SysV script to accomodate this
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reviewed by:
Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Sam Thursfield <sam.thursfield@codehink.co.uk>
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Java is sourced from the binary Java release from Oracle. This
chunk was originally written by Francisco Marchena.
ANT is a Java build system and is needed by ZooKeeper.
ZooKeeper itself is documented at http://zookeeper.apache.org/
This patch also brings in a zookeeper test program in a seperate strata
that can be safely discarded if not required. this test program
was written by me, <mike.smith@codethink.co.uk> and is not designed to
be used in any practical way, but to showcase the functionality
of zookeeper within baserock
The ZooKeeper demonstration server and client are currently hosted
on baserock/test.
The Java binary chunk only works for x86_64. As such, these
systems are limited to that architecture.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Reviewed-by: Sam Thursfield <sam.thursfield@codethink.co.uk>
Reviewed-by: Richard Maw <richard.maw@codethink.co.uk>
|
| | | |
| | | |
| | | |
| | | |
| | | | |
systemd doesnt depend on them anymore since
commit 796b06c21b62d13c9021e2fbd9c58a5c6edb2764
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Reviewed-by:
- Sam Thursfield
- Francisco Redondo Marchena
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We assumed that the ethernet interfaces always were going to be
called en* (e.g. ens3) when using the new version of systemd (v217),
but sometimes these interfaces can be called eth* (e.g. eth0). If
this happens the current configuration is not enough.
This patch is to enable DHCP also in eth* interfaces.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Reviewed-By: Emmet Hikory <emmet.hikory@codethink.co.uk>
Reviewed-By: Javier Jardón <javier.jardon@codethink.co.uk>
Reviewed-By: James Thomas <james.thomas@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | | |
Reviewed-by:
- Richard Maw
- Sam Thursfield
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The installer-x86_64 system is a system that can be used to install other
systems in an storage device. This system is intended to be booted by usb,
pxeboot... to install a Baserock system in your local disk.
The installer system requires the installer.configure extension to generate
a configuration file located in /etc/install.conf. With this extension
you can specify the following variables in a cluster morphology:
- INSTALLER_TARGET_STORAGE_DEVICE: Target storage device to install the
Baserock system.
- INSTALLER_ROOTFS_TO_INSTALL: The location of the root filesystem that
is going to be installed.
- INSTALLER_POST_INSTALL_COMMAND: Commands that will be run after the
installation finishes. It defaults to `reboot -f`.
The installer-utils stratum is required to contain the installer-scripts
chunk. This chunk contains the installer script that is going to be
installed in /usr/lib/installer/installer.py
The clusters/installer-build-system-x86_64.morph file defines the deployment
of a installer system as a rawdisk image. This installer system will
install a build-system-x86_64 located in /rootfs into the /dev/sda device.
Also this cluster defines a subsystem which is the build-system that
is going to end up in /rootfs on the installer system.
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Reviewed by: Sam Thursfield <sam.thursfield@codethink.co.uk>
Reviewed-by: James Thomas <james.thomas@codethink.co.uk>
|
| | | | | |
|
| | |_|/
| |/| | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
Reviewed by: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed by: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
|/ / /
| | |
| | |
| | |
| | | |
We don't need anything from the tools, prevents needing to rebuild the
kernel when we change u-boot
|
|/ / |
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed-By: Francisco Redondo Marchena <francisco.marchena@codethink.co.uk>
|