It looks like stages *combine* with the top-level stage, rather than
replacing it. So, the first stage will be "test", and will run the
top-level commands no matter what. Based on that, let's try to have
our old script as the top-level thing, but have it only run tests
when GOARCH=amd64. Other architectures will just build and vet/lint.
There's a lot of stdlib surgery in flight to make x/net capable of
doing its thing without having to use reflection to grab a file
descriptor. Until that work is done, anything using control messages
in x/net cannot work properly.
Responding with an error makes iPXE print a misleading error message (misleading because it doesn't break the boot in any way, it just makes humans uncomfortable).
The quick commands are just aliases for the `boot` command with
various pre-cooked kernel/initrds/cmdline combinations. Currently
supported are Debian, Ubuntu, Fedora and Centos. There's also code
for Arch, but it's currently disabled as I'm failing to get the
HTTP rootfs to work.
The service file is added as documentation, rather than in the system
services directory, because it will almost certainly require customization
before it can be used.
So why bother including one at all? Because I've gone through the trouble of
figuring out the various systemd-exec security flags to lock down pixiecore
as much as possible with chroots, capabilties, syscall filters, etc. Having
that as a baseline will encourage people to run Pixiecore with maximum constraints,
even if they have to write their own ExecStart for it.
Turns out, each repository has a *different* public key for encrypting
content, so copying encrypted blobs over from tlsrouter plain doesn't work.
Completely obvious in retrospect, derp.
By supporting Type 9 ( „EFI x86-64“ ), pixiecore can boot VMware (Fusion) EFI-Type Machines.
The const for FirmwareEFI64 has been renamed to FirmwareEFIBC ( see RFC-4578, Section 2.1 ) and FirmwareEFI64 is assign to type 9 and uses the same ipxe blob as FirmwareEFIBC.
Signed-off-by: Mathias Kaufmann <me@stei.gr>
* dockerfiles: Drop duplicate mkdir
The mkdir gets executed if "Building from local dev copy", whereas if built from
upstream git, go get will take care of it.
* dockerfiles: Drop extra community repo
No longer needed with current edge or stable tags of alpine linux.
* dockerfiles: Drop gcc as an explicit dep; go pulls it
Current edge and 3.5 declare gcc as a dep for go.
* dockerfiles: Install glide from package repo
Both edge and 3.5 provide a packaged glide. By using the provided package,
we reduce the build time a little.
* dockerfiles: Set GLIDE_HOME to prevent glide to pollute /root
glide promptly ignores HOME (it checks /etc/passwd), but honours GLIDE_HOME.
So, by pointing GLIDE_HOME to a ephemeral dir, ~/.glide will be created there
instead of /root/.glide, simplifying the cleanup process.
* dockerfiles: Use --purge to ensure clean package uninstalls
This way, /usr/lib/go gets purged, and we don't have to remove it manually.
* dockerfiles: Move netboot tree instead of copying it
Less space used and slightly faster build.
* dockerfiles: Simplify build steps
go build will honour GOBIN and leave the executable there.
* dockerfiles: Move the installation of packages to the top
* dockerfiles: Upgrade first, then install new stuff
* dockerfiles: Tie build deps with a virtual package for easier removal
By deleting the virtual .build-deps package, one ensures the
no-package-left-behind policy :-)
* dockerfiles: Split package list in multiple lines
It's a good practice for enhancing the readability of pull requests,
since addition or removal of packages from the list will result in single line
changes.
* dockerfiles: Drop changing dir to /
No need to change directory in order do the cleanup.
* dockerfiles: Test the existence of the go package, instead of .git
This way we can add .git to .dockerignore, thus preventing copying it over when
building the image.
* dockerfiles: Add .dockerfile files to minimize the files that are copied over
* dockerfiles: Place build logic in the Dockerfile
Makes it easier to understand the build process if the whole sequence is stored
in a single place.
OTOH, editing the shell script inside the Dockerfile is a bit harder.
* dockerfiles: Create a sandbox where to put all transient files
* dockerfiles: Set GLIDE_HOME to the sandbox
* dockerfiles: Set GOPATH to a dir under the sandbox
* dockerfiles: Simplify cleanup
* dockerfiles: Rename 'stuff' to 'context', to use Dockerfile lore
* dockerfiles: Install entrypoint onto /usr/local/bin
This is the default location for locally managed binaries, and as such, PATH
includes it. This way, it is easier to run it interactively.
* dockerfiles: Extract sandbox and context paths into variables
* dockerfiles: Move vars up to help define other vars before they are used
* dockerfiles: Add the required vars to eliminate duplicated paths
* dockerfiles: Replace hardcoded paths with references to vars
* dockerfiles: Fix wording for clarity
* dockerfiles: Add emtpy line to improve readability
* dockerfiles: Tell the go linker to strip debugging symbols
This produces a sensibly smaller binary.
* dockerfiles: Drop the --rm to docker build, as it is the default behaviour
* dockerfiles: Use long flags for readability
* dockerfiles: Base image onto alpine:3.5
Now that 3.5 has been released, we can use it instead of edge, since it
provides go 1.7.3. We get a more stable environment, plus a smaller image.
