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.
This is a poor man's version of "only build a container when
the continuous build is green." Travis would be better, but
we can't yet trigger once per commit, only once per build
in the build matrix, so that doesn't work.
Travis doesn't support post-all-builds hooks, so a single commit
would trigger 3 builds on quay.io. Travis have plans for fancier
pipelines, until then we'll just build directly.
Some DHCP messages are broadcast to 255.255.255.255, and binding to a
specific address filters those packets out. Instead, we have to translate
the "listen on ip:port" intent to "listen on interface:port", and filter
based on the interface that received the packet.
Fixes#27.
The UI is optional and need to be explicitly activated, since I
don't want existing users to suddenly have an information-spewing
thing show up on their network.
iPXE appears to have *really* poor performance (orders of magnitude worse) if
it doesn't know the length of the kernel/initrds that it's downloading. Without
this change, booting CoreOS takes longer than I've had patience to wait. With
this change, the bottleneck becomes the network transfer speed.
Fixes#10.
pixiecore: Plumb NewSnooperConn into Server as an advanced option.
pixiecore/cli: Plumb DHCPNoBind to the CLI.
Now, by default, Pixiecore will bind() to the DHCP server port in a way
that shows up in `netstat` by default. If you want to enable the "coexist
with my existing DHCP server" mode, you need to explicitly pass
--dhcp-no-bind.
The way docker hub and quay.io work, you can't easily pass a custom
context to a Dockerfile. So, effectively, if you want multiple dockerfiles
per repository, you need to re-check out the whole repository by hand,
without help from the environment.
This sucks a little bit because it doesn't guarantee that the build happens
at the trigger revision ID, but for my purposes of "just have a recent build up",
it's sufficient.
