| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It has 4 modes.
1. Specify PXEBOOT_DEPLOYER_INTERFACE and PXEBOOT_VLAN to
configure the target to pxeboot on a vlan and spawn a dhcp, nfs and
tftp server. This is potentially the fastest, since it doesn't need
to copy data to other servers.
2. Specify PXEBOOT_DEPLOYER_INTERFACE without PXEBOOT_VLAN to
configure do 1, but without creating the vlan interface. This
assumes that you have exclusive access to the interface, such as if
you're plugged in to the device directly, or your interface is
vlanned by your infrastructure team.
This is required if you are serving from a VM and bridging it to the
correct network via macvtap. For this to work, you need to macvtap
bridge to a pre-vlanned interface on your host machine.
3. Specify PXEBOOT_DEPLOYER_INTERFACE and PXEBOOT_CONFIG_TFTP_ADDRESS
to put config on an existing tftp server, already configured by the
dhcp server.
This spawns a tftp server and configures the local nfs server, but
doesn't do a dhcp server. This is useful if you have already got a
dhcp server that serves PXE images.
4. Specify at least PXEBOOT_CONFIG_TFTP_ADDRESS and
PXEBOOT_ROOTFS_RSYNC_ADDRESS to specify existing servers to copy
config, kernels and the rootfs to.
The mode detection can be overridden by specifying PXEBOOT_MODE.
Mode 1 is `spawn-vlan`. Mode 2 is `spawn-novlan`, Mode 3 is
`existing-dhcp` and Mode 4 is `existing-server`.
|
|
|
|
|
|
| |
With VLANs it's possible to PXE boot hardware without needing to fiddle
with the DHCP server, by starting your own PXE server on a VLAN, and
configure the NIC of the target to start in that VLAN.
|
| |
|
| |
|
|
|
|
| |
It's handy to be able to start an NFS server when you want to.
|
|
|
|
|
|
|
|
| |
So libdrm_freedreno.pc gets generated and the mesa driver can be build
Reviewed-By: Emmet Hikory <emmet.hikory@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
|
|\
| |
| |
| |
| |
| | |
Reviewed-by:
- Sam Thursfield
- Pedro Alvarez
|
|/ |
|
|\
| |
| |
| |
| | |
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed-By: Paul Sherwood <paul.sherwood@codethink.co.uk>
|
|/
|
|
|
|
|
| |
Node.js doesn't build on PPC64 at this time.
It also doesn't build on big-endian ARM, but was already not in those
systems.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
|/
|
|
|
|
|
| |
Upstream have not released a new version since April 1997.
Additionally, newer daemons and applications are inconsistent in their
support for libwrap, leading to confusion as to whether an application
supports the library.
|
|\
| |
| |
| |
| | |
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Try to be as generic as possible and only make a few exceptions:
- Only build ARM-related drivers if we are in ARM, this is:
nouveau,freedreno,vc4 (and svga,swrast as fallbacks)
- enable-gallium-egl only in ARM (needed by freedreno, nouveau)
- For the rest of the arquitectures, the drivers to build will be the
default ones, this is:
- DRI: i915 i965 nouveau r200 radeon swrast
- Gallium: r300 r600 svga swrast
- enable GLES2 (disabled by default)
- disable GLX (enabled by default) to not pull x11 deps
The rest all the configure parameters will be automatically configured
by the mesa's configure.ac
|
| | |
|
|\ \
| |/
|/|
| | |
Reviewed-By: Paul Sherwood <paul.sherwood@codethink.co.uk>
|
| | |
|
| |
| |
| |
| |
| |
| | |
It only contains genivi layer_management component, but this component
seems to be replaced by wayland-ivi-extension present in
weston-genivi
|
|/
|
|
| |
Its not a dependency of any stratum or system
|
|\
| |
| |
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: James Thomas <james.thomas@codethink.co.uk>
|
| | |
|
| |
| |
| |
| | |
This version adds GL support
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
At this point we already have all the graphic libraries in the
system, so we can run 'gdk-pixbuf-query-loaders' here instead
in every boot of the system
|
| | |
|
| |
| |
| |
| |
| | |
This is needed by modern versions of xserver and GTK+
Put it in here until we upgrade the xserver to avoid rebuilds
|
|\ \
| | |
| | |
| | |
| | | |
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed-By: Richard Dale <richard.dale@codethink.co.uk>
|
|/ /
| |
| |
| | |
This means we use the out-of-tree module located in extra/
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Paul Sherwood <paul.sherwood@codethink.co.uk>
|
| | |
| | |
| | |
| | |
| | |
| | | |
If none of the MASON_ options are set then mason.configure will now do
nothing, instead of raising an error. This is needed because
mason.configure is enabled by default in the build-system.
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
Previously if you enabled distbuild.configure but didn't set all of the
required variables, your deployment would fail. This has become much
more annoying with the introduction of the build-system family of
systems, which are indented to be suitable either as a local builder or
part of a distbuild network.
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| | |
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk>
|
| |
| |
| |
| |
| |
| | |
This could be improved in future by combining the cluster morphology
with the existing one, and mason/mason-generator.sh being improved to
allow choice between OpenStack and KVM.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This adds TEST_INFRASTRUCTURE_TYPE and OPENSTACK_NETWORK_ID to
mason.conf, as well as ending the confusion of using both
MASON_TEST_HOST and TEST_VM_HOST_SSH_URL to mean the same thing
in different places.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Testing currently involves building a Baserock devel system,
deploying it as a VM and testing that that deployed VM can
build Baserock successfully.
Originally Mason used scripts/release-test to do testing on
a kvm host. In this patch the bits needed to do testing on
an OpenStack host are provided.
The new scripts/release-test-os script is based on the old
scripts/release-test, and it uses `nova` to boot/delete/etc
images and instances on OpenStack.
The mason script, `mason.sh` is updated to optionally run
either scripts/release-test-os or scripts/release-test,
depending on whether TEST_INFRASTRUCTURE_TYPE is set to
'openstack' or 'kvmhost' in the Mason's mason.conf.
The `os.conf` file is sourced by `mason.sh`, and should
be updated to contain the relevant credentials and details
for the OpenStack tenancy to be used for test deployments.
When Mason creates a test OpenStack instance, there is
potential for a race condition depending on whether ssh
comes up before the cloud-init has finished resizing the
instance's disc. If morph running on the test instance
tries to build before the disc size is increased, it will
fail complaining of insufficient free space.
To eliminate this race, the cloud init script
`os-init-script` is passed to `nova boot`. This touches
a file after the disc is resized, which Mason checks for
before it runs a `morph build`.
The `os.conf` and `os-init-script` files must both be
placed in the Mason system's `/root/` directory before
the system is deployed. This should happen in the
`mason.configure` configuration extension.
The `mason.configure` configuration extension should also
be updated to handle adding two extra variables to the
`mason.conf` file. These are the aforementioned
TEST_INFRASTRUCTURE_TYPE and OPENSTACK_NETWORK_ID, which is
the ID for the configured OpenStack network that test
instances should use.
|
| |
|