danderson/netboot

Packages and utilities for network booting

Netboot, packages and utilities for network booting

This repository contains Go implementations of network protocols used in booting machines over the network, as well as utilites built on top of these libraries.

This project is no longer actively developed. I'm glad if you find it useful, but don't expect any significant changes.

Programs

• Pixiecore: Command line all-in-one tool for easy netbooting

Libraries

The canonical import path for Go packages in this repository is go.universe.tf/netboot.

• pcap: Pure Go implementation of reading and writing pcap files.
• dhcp4: DHCPv4 library providing the low-level bits of a DHCP client/server (packet marshaling, RFC-compliant packet transmission semantics).
• tftp: Read-only TFTP server implementation.
• pixiecore: Go library for Pixiecore tool functionality. Every stability warning in this repository applies double for this package.

netboot's Issues

Support for Arch Linux

When booting Arch Linux via PXE [1], besides the kernel and initramfs,
an additional the root filesystem image (airootfs.sfs) has to be transferred.
If the location of airootfs.sfs is specified from the kernel command line then
a boot hook will download it from the specified location [2][3][4][5].

It would be great if pixiecore could support:

1. Serving additional static files (#73), so there is no need for running an additional HTTP/NFS/NBD server
2. {{ ServerHost }} on the --cmdline flag (#74), so the address of the server does not have to be manually specified [6]

References/Notes:

[1] https://wiki.archlinux.org/index.php/PXE
[2] https://git.archlinux.org/archiso.git/tree/configs/releng/syslinux/archiso_pxe.cfg?h=v39#n33
[3] https://git.archlinux.org/archiso.git/tree/docs/README.bootparams?h=v39#n92
[4] https://git.archlinux.org/archiso.git/tree/archiso/initcpio/hooks/archiso_pxe_http?h=v39#n4
[5] The fs image can be served from either HTTP/NFS/NBD, but as pixiecore already
runs HTTP, I'd like it to be served from pixiecore
[6] The archiso understands ${pxeserver}, but it resolves to the address of the DHCP server offering the IP address instead of the address of pixiecore

Consider supporting an optional builtin full DHCP server

Pixiecore currently plays nice with existing DHCP servers, which is great... but that means you have to do more work if you don't have an existing DHCP server, e.g. when booting a machine over an ad-hoc crossover cable connected to your laptop.

I'm a bit wary of implementing a full DHCP server, because it gets horribly complicated horribly quickly... But if we define very clear rules of engagement (basically, minimal address management, and no options beyond router+DNS), I think we can make it work.

Support for Apple Netboot

Didn't find any references or closed issues here. Is is feasible to add support for apple computers?

https://en.wikipedia.org/wiki/NetBoot

Boot fails confusingly when Pixiecore is competing with another PXE-enabled DHCP server

When using waitron and pixiecore in API mode in docker, I am able to see that waitron is able to place a machine in build mode, and then pixiecore talks to waitron and receives info, but the PXE boot process fails, and I receive a "Could not start download: Operation Not Supported" IPXE Error.

Waitron is returning:

{
  "kernel": "http://192.168.1.1/image/ubuntu-installer/amd64/linux",
  "initrd": [
    "http://192.168.1.1/image/ubuntu-installer/amd64/initrd.gz"
  ],
  "cmdline": "interface=auto url=http://127.0.0.1:9090/test.example.com/preseed/7ab940c8-8cb8-4f9b-8758-8aa25b2fa512 ramdisk_size=10800 root=/dev/rd/0 rw auto hostname=test.example.com console-setup/ask_detect=false console-setup/layout=USA console-setup/variant=USA keyboard-configuration/layoutcode=us localechooser/translation/warn-light=true localechooser/translation/warn-severe=true locale=en_US"
}

Which appears to be valid responses via the API.md, and the URLs for both the kernel and initird are valid working URLs.

pixiecore: UI is deprecated?

I tried running the Docker image for pixiecore but couldn't get the UI to show up. I am under the impression that it is deprecated considering netboot/pixiecore/ui/ does not exist on master. Is that really the case?

Add `pxe` flag to repo so that it is easier to find

Booting Windows PE fails

Trying to use wimboot with netboot, but without success.

ref.: http://ipxe.org/wimboot

my cmd:

sudo go/bin/pixiecore boot ipxeboot/wimboot ipxeboot/macrium/Boot/BCD ipxeboot/macrium/Boot/boot.sdi ..

Result in VMware Workstation:
.
.
.

wimboot v.2.6.0 --....
command line: "initrd=initrd0 initrd=initrd1"
Unrecognized argument "initrd=initrd1"

Press a key to reboot

pixiecore doesn't cooperate with running dnsmasq on the same server

pixiecore doesn't cooperate with running dnsmasq like said here:

https://github.com/google/netboot/blob/792915a85f22dd96794e94c7732170c8e7620a2b/pixiecore/README.md#L18

$ sudo pixiecore quick ubuntu zesty
listen udp4 :67: bind: address already in use
$ sudo netstat -aunp | grep 67
udp        0      0 0.0.0.0:67              0.0.0.0:*                           11605/dnsmasq   
udp        0      0 0.0.0.0:67              0.0.0.0:*                           10754/dnsmasq   

Cannot Get it Running

I tried using Ubuntu 16.04 and 14.04, it failed to run. When I run the command it will just stop and do nothing, empty line. I open the browser it displayed: 404 page not found.

Then I went on to try docker, which also out of luck.

Commands that I have tried:

sudo pixiecore boot \
  https://alpha.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz \
  https://alpha.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz \
  --cmdline='coreos.autologin'

wget https://alpha.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz
wget https://alpha.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz
sudo pixiecore boot \
  coreos_production_pxe.vmlinuz \
  coreos_production_pxe_image.cpio.gz \
  --cmdline='coreos.autologin'

sudo docker run \
  --net=host \
  -v /var/images:/image \
  danderson/pixiecore \
    boot /image/coreos_production_pxe.vmlinuz /image/coreos_production_pxe_image.cpio.gz

None of them work properly.

I do not think I have done something wrong unless there are dependencies/other stuff that I have missed. Thanks for the help.

pixiecore: panic: runtime error: invalid memory address or nil pointer dereference

Hi!

I am running pixiecore in api mode, along with waitron as the api server.

Starting with pixiecore v2, I get this:

pixiecore_1  | panic: runtime error: invalid memory address or nil pointer dereference
pixiecore_1  | [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x7f2aaf7629cf]
pixiecore_1  | goroutine 38 [running]:
pixiecore_1  | panic(0x7f2aaff83ec0, 0xc420014050)
pixiecore_1  |  /usr/lib/go/src/runtime/panic.go:500 +0x1a5
pixiecore_1  | go.universe.tf/netboot/pixiecore.(*apibooter).BootSpec(0xc420042500, 0xc420152c38, 0x6, 0x5a4, 0x0, 0x0, 0x0, 0x0)
pixiecore_1  |  /tmp/go/src/go.universe.tf/netboot/pixiecore/booters.go:157 +0xcf
pixiecore_1  | go.universe.tf/netboot/pixiecore.(*Server).serveDHCP(0xc4200780e0, 0xc420015a00, 0x0, 0x0)
pixiecore_1  |  /tmp/go/src/go.universe.tf/netboot/pixiecore/dhcp.go:45 +0x3a1
pixiecore_1  | go.universe.tf/netboot/pixiecore.(*Server).Serve.func1(0xc4200780e0, 0xc420015a00)
pixiecore_1  |  /tmp/go/src/go.universe.tf/netboot/pixiecore/pixiecore.go:217 +0x37
pixiecore_1  | created by go.universe.tf/netboot/pixiecore.(*Server).Serve
pixiecore_1  |  /tmp/go/src/go.universe.tf/netboot/pixiecore/pixiecore.go:217 +0x6fc

whenever a box fires up its PXE firware and tries to obtain the boot files, when the box in question is not in build mode.
This event prompts pixiecore to query waitron about the mac address of the box requesting boot (simulated here with curl):

curl -v http://localhost:9090/v1/boot/70:10:9f:42:de:ad
* About to connect() to localhost port 9090 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 9090 (#0)
> GET /v1/boot/70:10:6f:43:d3:08 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:9090
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Fri, 02 Sep 2016 10:33:27 GMT
< Content-Length: 18
< 
Not in build mode
* Connection #0 to host localhost left intact

According to pixiecore's API specification:

Any non-200 response from the server will cause Pixieboot to ignore the requesting machine.

And yet, pixicore dies as shown in the previous dump.

Please note that when the box is in "build mode", pixiecore works as expected.

Here's the relevant section of the docker-compose.yml.

  pixiecore:
    image: danderson/pixiecore
    volumes:
      - ./pixiecore:/image
    command:
      - api
      - http://localhost:9090
      - --debug
      - --log-timestamps
      - --dhcp-no-bind
      - --port
      - "80"
    network_mode: host
    privileged: true
    restart: always

I work around this issue for now by setting restart: always, so pixiecore gets resucitated when it dies.

Also, kudos to the --dhcp-no-bind option, that allows running pixiecore alongside the dhcp server, yay!

N.B.: I'll probably transition from waitron to coreos' bootcfg soon.

If I manage to fix it, I'll do you a PR.

Cheers, and thanks again for pixiecore!

Document import path

The canonical import for this project is package dhcp4 // import "go.universe.tf/netboot/dhcp4"
Is this still true? If so, could you add in the README that this is a mirror?

For anyone else that runs into the issue:
https://golang.org/doc/go1.4#canonicalimports

[DHCP] unsupported client firmware type '16'

pixiecore_1  | [DHCP] Unusable packet from xx:xx:xx:xx:xx:xx: unsupported client firmware type '16' (please file a bug!)

The server is a baremetal in UEFI

Does anyone have the same firmware issue ?

Quick boot into netboot.xyz

https://github.com/antonym/netboot.xyz is able to provide menu with user friendly choices. Could be more convenient than specifying command line flags.

Fix the image builder

The image builder still depends on Glide, but I switched to Go modules. Oops. Need to fix that.

pixicore: UEFI boot faild with '"ready": no such image

Hi.
When booting a Supermicro Server in UEFI mode, the boot stops after transferring boot script, kernel and initrd with:

http://172.17.0.2:80/_/booting?mac=0c%3AC4%3A7a%3Ad2%3A89.. Input/Output error (http://ipxe.org/1d0c6598)
"ready": no such image

dhcp4: Packet.TransactionID as slice or array of bytes

Hello! From what I can tell, it's not uncommon for transaction IDs to end up as unfriendly strings: TransactionID:_�37

Is there a reason that transaction ID can't be either [4]byte or just []byte instead? As of now, I'm doing hex.EncodeToString([]byte(req.TransactionID)) to get a printable transaction ID.

Thanks again for the package!

Support native file names in ID template function

Some distros may depend on the filenames, eg. alpine have an option to download and apply apkvol file during the boot.

Problem it that file should have the name like client.apkvol.tar.gz otherwise it will fails to boot, trying to decrypt it according to it's extension.

Currently, in this command:

pixiecore boot vmlinuz-vanilla initramfs-vanilla \
  --cmdline='ip=dhcp modules=loop,squashfs,sd-mod,usb-storage modloop={{ID "modloop-vanilla"}} apkovl={{ID "client.apkvol.tar.gz"}}'

client.apkvol.tar.gz file name will be translated to other-1, that's exactly problem.

Regression in commits from dec 24

Packet capture: (can filter by bootp and open in wireshark) (see packets 50 and 51)
wireshark.zip

Pixiecore log:

[DHCP] Offering to boot 08:00:27:4e:15:86
[DHCP] Offering to boot 08:00:27:4e:15:86
[DHCP] Offering to boot 08:00:27:4e:15:86
^[[24~[DHCP] Offering to boot 08:00:27:4e:15:86
[DHCP] Offering to boot 08:00:27:4e:15:86
[DHCP] Offering to boot 08:00:27:4e:15:86
[DHCP] Offering to boot 08:00:27:4e:15:86
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[TFTP] Sent "4c:cc:6a:ce:90:8c/7" to 192.168.1.199:1821
[TFTP] Sent "4c:cc:6a:ce:90:8c/7" to 192.168.1.199:1822
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c
[TFTP] Sent "4c:cc:6a:ce:90:8c/7" to 192.168.1.199:1823
[TFTP] Sent "4c:cc:6a:ce:90:8c/7" to 192.168.1.199:1824
[DHCP] Offering to boot 4c:cc:6a:ce:90:8c

Machine boot log: note: I think that this is unrelated to #51 because it happens on physical and virtual hardware alike.

We were able to solve this by moving back to a pixiecore built on December 17. Next I'm going to build the bug-51 branch. Thanks for your help, @danderson !

Debugging DHCP relay with netboot

I've got a problem - Hiawei HG8245H router that doesn't forward DHCP packets. https://forums.whirlpool.net.au/archive/2281094 explains it well.

My network card doesn't event get IP from switch's DHCP server and I want to understand why. Is it because Huawei drops DHCPDISCOVERY with Option 60 set. Or is it because my network card expects something different. I would like to debug it with netboot utility.

Even it DHCP Relay option in my switch does not work, there is still a menu with DHCP options and I'd like to try setting them as if the router supports PXE.

Checking router.

• send standard DHCPDISCOVERY request and check that standard DHCPDISCOVERY reply is received (no option set)
• send DHCPDISCOVERY+PXE request and check what kind of DHCPDISCOVERY reply is returned
• add Options 60 to router (no idea what the value should be) and repeat DHCPDISCOVERY and DHCPDISCOVERY+PXE to heck what kind of DHCPDISCOVERY reply is returned see if there is any difference from expected packets. For these tests it would be nice to automate what is expected.

Checking client.

• wait for DHCPDISCOVERY+PXE request and check the differences from standard DHCPDISCOVERY reply - show if there any anomalies like options and show their numbers and values in hex and human readable form
• reconstruct reply from DHCPDISCOVERY+PXE and send it again

It is just a start, and maybe I will be able to trick the router into booting it further.

Build ACIs for Pixiecore

rkt is excellent, and we should have ACIs. Probably setting up image builds on quay.io is the way to go?

Pixiecore: Looking for example of URL signing for API mode

Would like to see a JSON example of URL signing, e.g. {{ ID "http://my.url:8080/something.json" }} , for API mode. Thoughts?

Deploy an ARMv6 Build

I'm using a raspberrypi to run pixiecore and everything compiles great, but it would be nice if installing from .deb was possible so that I don't also need go. The travis-ci runners support cross architecture compilation, so it should be possible to specify arch in the build matrix there with little extra effort.

API --dhcp-no-bind flag seems invalid

Perhaps a silly question here but when attempting to run:

pixiecore api http://127.0.0.1:6000/ --dhcp-no-bind

The following error is produced:

listen ipv4:17: lookup : invalid domain name

Note: I am attempting to run this inside a Docker container with an OS base of Ubuntu 16.04
I have also tried placing the --dhcp-no-bind flag infront of the api URL and the result is the same.

Am I missing something obvious with the --dhcp-no-bind flag? I am needing this as I am running a dhcp server inside the same container.

dhcp4: test doesn't compile on non-Linux platforms

Not so important, just FYI.

cd /src/go.universe.tf/netboot/dhcp4 && go test
# go.universe.tf/netboot/dhcp4
./conn_test.go:150:12: undefined: newLinuxConn
FAIL	go.universe.tf/netboot/dhcp4 [build failed]

flag error: -l is required but that's not documented

When pixiecore is started with the coreos example from README.md, it prints

Error reading flag: invalid string being converted to IP address: <nil>

probably due to a nil default at https://github.com/google/netboot/blob/master/pixiecore/cli/cli.go#L73

The flag should be documented as required and the README fixed or it should default to something that does not crash.

Detect and log when we're EFI-booting a non-EFI-capable binary

EFI iPXE can only boot EFI binaries. This generally works because linux has CONFIG_EFI_STUB, a cool hack that makes bzImage kernels multi-format, executable as either bzImage or EFI applications.

If you try booting a kernel that doesn't have CONFIG_EFI_STUB, at best iPXE will fail because of a format error. At worst, it will chainload anyway and hang the machine.

It's possible to detect whether an image is a proper EFI application by inspecting the first few dozen bytes of the kernel. Pixiecore should do an on-the-fly inspection of the kernel as it's serving the image, and log a loud warning if it's serving a non-EFI image to an EFI client.

Request: Option to local boot

If not already possible, it'd be nice to have an option to boot the local disk, i.e. if the API returns 404, send the PXE arg "LOCALBOOT 0" to bypass waiting until the client PXE ROM times out. Happy to try and work on it but thought I'd add a feature request.

Example pixiecore.service should include AF_NETLINK in RestrictAddressFamilies

I had to add the AF_NETLINK family to RestrictAddressFamilies to make the example service file work

HPDL380 Gen 9 can't boot in UEFI mode

I've been trying to boot some HP DL380 Gen9's which default to UEFI PXE boot mode. Pixiecore sees the request just fine and sends a ProxyDHCP packet, but the machines don't seem to respond to it (in that they fail to boot, and instead send another DHCP request).

Anyone had any experience with these units? It does occur to me that I am using the dhcp-no-bind mode of pixiecore due to resource constraints, and they might be picky about where the responses come from, but if I shunt them into Legacy PXE mode they boot immediately and properly.

As an attempted work around I tried enabling pixiecore via a hack to send Option 43, but it made no difference. Wireshark captures of the traffic look correct - though I need to go back and check for anything on other ports (I should confirm the port 4011 request is absent - I certainly haven't seen any traffic that way.)

This is all taking place on a single layer 2 network.

dhcp4: data race in TestPortableConn and TestLinuxConn

Just tried dhcp4 with go tip (equivalent to go1.9, sorry for the inconvenience of golang/go#19209) and saw it.

=== RUN   TestPortableConn
==================
WARNING: DATA RACE
Write at 0x00c42000c620 by goroutine 6:
  go.universe.tf/netboot/dhcp4.testConn()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:73 +0x750
  go.universe.tf/netboot/dhcp4.TestPortableConn()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:133 +0x1ca
  testing.tRunner()
      /usr/lib/golang/src/testing/testing.go:610 +0xc9

Previous read at 0x00c42000c620 by goroutine 7:
  go.universe.tf/netboot/dhcp4.testConn.func1()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:57 +0x3b

Goroutine 6 (running) created at:
  testing.(*T).Run()
      /usr/lib/golang/src/testing/testing.go:646 +0x52f
  testing.RunTests.func1()
      /usr/lib/golang/src/testing/testing.go:793 +0xb9
  testing.tRunner()
      /usr/lib/golang/src/testing/testing.go:610 +0xc9
  testing.RunTests()
      /usr/lib/golang/src/testing/testing.go:799 +0x4ea
  testing.(*M).Run()
      /usr/lib/golang/src/testing/testing.go:743 +0x12f
  main.main()
      go.universe.tf/netboot/dhcp4/_test/_testmain.go:76 +0x1b8

Goroutine 7 (finished) created at:
  go.universe.tf/netboot/dhcp4.testConn()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:58 +0x3c7
  go.universe.tf/netboot/dhcp4.TestPortableConn()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:133 +0x1ca
  testing.tRunner()
      /usr/lib/golang/src/testing/testing.go:610 +0xc9
==================

=== RUN   TestLinuxConn
==================
WARNING: DATA RACE
Write at 0x00c42000ca20 by goroutine 10:
  go.universe.tf/netboot/dhcp4.testConn()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:73 +0x750
  go.universe.tf/netboot/dhcp4.TestLinuxConn()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:155 +0x1a7
  testing.tRunner()
      /usr/lib/golang/src/testing/testing.go:610 +0xc9

Previous read at 0x00c42000ca20 by goroutine 11:
  go.universe.tf/netboot/dhcp4.testConn.func1()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:57 +0x3b

Goroutine 10 (running) created at:
  testing.(*T).Run()
      /usr/lib/golang/src/testing/testing.go:646 +0x52f
  testing.RunTests.func1()
      /usr/lib/golang/src/testing/testing.go:793 +0xb9
  testing.tRunner()
      /usr/lib/golang/src/testing/testing.go:610 +0xc9
  testing.RunTests()
      /usr/lib/golang/src/testing/testing.go:799 +0x4ea
  testing.(*M).Run()
      /usr/lib/golang/src/testing/testing.go:743 +0x12f
  main.main()
      go.universe.tf/netboot/dhcp4/_test/_testmain.go:76 +0x1b8

Goroutine 11 (finished) created at:
  go.universe.tf/netboot/dhcp4.testConn()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:58 +0x3c7
  go.universe.tf/netboot/dhcp4.TestLinuxConn()
      /home/mikioh/NFS/src/go.universe.tf/netboot/dhcp4/conn_test.go:155 +0x1a7
  testing.tRunner()
      /usr/lib/golang/src/testing/testing.go:610 +0xc9
==================

TFTP connection timed out results in Boot Failure?

It would seem that if there is a problem during the TFTP download in the boot.ipxe script, the end result is a Failed Boot and the machine gets stuck in BIOS.

 ...
 No ProxyDHCP responce, retrying (attempt 5/10)
 Configuring (net0 00:02:00:00:00) ...... ok
 nodes/.../boot.0......... Connection timed out (http://ipxe.org/....)
 FATAL: INT18: BOOT FAILURE

Perhaps the pixiecore/boot.ipxe's "chain ${filename}" also needs a "|| goto fail" added to it ?

Physical machines can't boot from new kernel

Recently, the ipxe kernel pixiecore serves was changed from undionly.kpxe to ipxe.pxe (in 029be8d). This has caused physical servers I'm working with (HP DL380P G8) to stop booting correctly, both in boot mode and api mode. I'm using the coreos boot example straight from the docs to test:

sudo pixiecore boot \
  https://alpha.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz \
  https://alpha.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz \
  --cmdline='coreos.autologin'

While this will boot ESXi VMs on the network correctly, a physical server never manages to boot. Pixiecore's ipxe image loads and starts configuring the network, the single plugged in ethernet port gets past "waiting for link up", but then fails on the "configuring" step with "no configuration steps succeeded". It does this 10 times, then exits, causing the hardware's PXE to kick in again and retry.

I tried using dhcpdump to monitor the dhcp traffic on the network, but the machine's MAC never appears in the observed DHCP messages. This suggests the machine only thinks it's trying to configure itself over dhcp, in reality no traffic ever leaves the network card.

If I build from the codebase prior to the mentioned commit, (which uses undionly.kpxe), the physical server boots correctly. I have a very tenuous grasp of how any of this works, but I suspect it is because UNDI relies on firmware available on the network card, whereas the ipxe kernel image relies on drivers (which it may be missing for the particular hardware I'm working with).

Pixiecore should implement some kind of fallback scheme where it tries various ipxe kernels against the target, or let the user configure this (and basically leave it at "proxydhcp as a cli" functionality).

[dhcp4] support client side broadcast

DHCP discover message is the kind of message client broadcast to servers.

But, dhcp4 hardcode the destination port to ":68", so that we are not able to complete discover step.

Pixiecore doesn't work on Windows due to missing x/net/ipv4 support

Fails to run on Windows:

>pixiecore.exe api -d 127.0.0.1:1111
not supported by windows

Why it is not supported? I couldn't find the source of that error.

Building pixiecore

Hello Dave, Thanks for your nice code. I managed to use "pixiecore boot" up to iPXE and it was not easy struggling against the corporate DHCP server with unwanted and imposed DHCP options like wrong boot file. Then... it fails. So I want to print out some debugging info and find out what boot file needs to be loaded next... and why it is not, etc.... But I am new to golang and I do not know how to build pixiecore bin from your sources, that I would have slightly modified to print out chosen data. It would be very kind if you could provide with a instruction text file INSTALL.md or a Makefile-like stuff or even a small clue ?
Sincerely yours. François.

Boot fails in VirtualBox

I was successfully using pixiecore previously in the same setup. This began to happen, and I don't know why. Now, I have reinstalled my test environment (pixiecore and virtualbox) and am still getting it. Anyone have any idea why this is happening?

Ubuntu 17.10 desktop running virtualbox with a bridged network adapter.

Thanks!

Investigate direct serving/booting of ISO images

It would be nice to be able to magically boot directly from ISOs. This is very hard/impossible to achieve in the general case, but it might be feasible to make it work for certain specific cases.

The closest we can easily get is with MEMDISK, which adds a chainloading step that works with linux kernels/distros that are built with MEMDISK support. I have no experience with running such a setup, but the first step would be to create a Booter that constructs memdisk-based Specs, and start experimenting with that.

Alternatively, the "quick" booting templates might just replace this, in terms of ease of use.

Pixiecore API - Providing Ignition Config Files For CoreOS via cmdline cloud-config-url

I can successfully point Pixiecore to a URL specifying a cloud-config.yml file and PXE boot CoreOS machines fine.

I am wanting to point Pixiecore to a URL specifying an Ignition file.

So far I have tried returning a valid URL in the cloud-config-url JSON field within a "cmdline" JSON object but the machines boot and respond with "Failed to start Load cloud-config from URL defined in /proc.cmdline" and my config is not used.

As Ignition is run very early in the boot cycle I have also attempted to pass Pixiecore a first boot parameter as per the "When is Ignition Executed" section of:

https://coreos.com/ignition/docs/latest/what-is-ignition.html.

I have included this argument in my "cmdline" JSON object as a JSON entry consisting of "coreos.first_boot": "1".

This has had no effect.

I am wondering if there is anything specific that needs to be done to provide Ignition config files or is this not currently possible with Pixiecore?

IPv6 PXE support

UEFI firmwares know how to netboot over IPv6. The process is similar to IPv4, but different. Some braindumped notes at https://github.com/google/netboot/blob/master/pixiecore/README.ipv6.md .

go.universe.tf is dead

go.universe.tf is down, and so pixiecore doesn't build.

Unable to boot EFI machine (seems to loop through iPXE)

I've got Pixiecore working great for BIOS hosts, however when I try and boot the same machine (tested on physical Dell host and a VMWare machine) in EFI mode, I seem to get past the chainloading into iPXE phase of the boot process, but then the boot seems to fail with an "Operation not supported" error:

At this point, the machine has booted from its' own EFI firmware, made a first DHCP request (configuring it to boot iPXE next), the machine has then booted iPXE, so I'd expect the next filename to come back to be the actual kernel that the machine is configured to boot (that PixieCore has gathered via the API). The PixieCore log at this point is here:

2018/09/18 14:59:57 [DHCP] Got valid request to boot 24:6e:96:78:44:40 (X64)
2018/09/18 14:59:57 [DHCP] Offering to boot 24:6e:96:78:44:40
2018/09/18 15:00:01 [DHCP] Ignoring packet from 24:6e:96:78:44:40: packet is DHCPREQUEST, not DHCPDISCOVER
2018/09/18 15:00:01 [PXE] Ignoring packet from 24:6e:96:78:44:40 (172.16.4.35:4011): packet is DHCPREQUEST, not DHCPDISCOVER
2018/09/18 15:00:02 [TFTP] clamping blocksize to "172.16.4.35:1295": 1468 -> 1450
2018/09/18 15:00:02 [TFTP] Sent "24:6e:96:78:44:40/7" to 172.16.4.35:1295
2018/09/18 15:00:02 [TFTP] clamping blocksize to "172.16.4.35:1296": 1468 -> 1450
2018/09/18 15:00:02 [TFTP] Sent "24:6e:96:78:44:40/7" to 172.16.4.35:1296
2018/09/18 15:00:13 [DHCP] Got valid request to boot 24:6e:96:78:44:40 (X64)
2018/09/18 15:00:13 [DHCP] Offering to boot 24:6e:96:78:44:40
2018/09/18 15:00:13 [DHCP] Ignoring packet from 24:6e:96:78:44:40: packet is DHCPREQUEST, not DHCPDISCOVER

It seems like it's trying to chainload into iPXE again at this point though (from iPXE) - the DHCPOFFER packet that comes back has the boot filename set to "24:6e:96:78:44:40/7". The user-class identifier of the associated DHCPDISCOVER packet is however set to "pixiecore", so I don't understand why Pixiecore is sending back a basic TFTP response.

I've attached a zipped pcap of the packets that I think are related to this - these are the DHCPDISCOVER sent by iPXE (containing user-class=pixiecore), then a DHCP offer from the Pixiecore container (172.16.4.225) with the boot filename set to "24:6e:96:78:44:40/7".

UEFI boot fails due to missing bzImage feature code

Report pulled from #52 , by @cdata :

---

Hi, I'm new to both Pixiecore and PXE booting in general. As a minor anecdote that I think might be related, I was having trouble booting a small device yesterday and happened upon your conversation as it was unfolding. I tried using several of the "quick" options just to rule out any mistakes I might have made invoking Pixiecore, but the results were the same. Sure enough, rolling back to October 17th in pixiecore enabled my device to load everything and boot.

This may be a completely different issue, but given the title of the issue I figured I would post it in here first since i-dont-know-what-im-doing.jpg.

Attached is a pcap I took using the debug command I found in pixiecore. The device would reboot immediately upon failure to boot, but I was able to glean a reference to this error in the output: http://ipxe.org/3c092083

boot.pcap.zip

I'm not sure how else to be most helpful, but here is a basic description of my setup:

My host machine is a Macbook Pro with VirtualBox. On my host there is a VM with a bridged network adapter, and this VM runs Pixiecore. On my local network there is a small device capable of booting over the network.

Normalize BootServerName/BootFileName and DHCP opts 66/67

When DHCP option 52 is present, either of the sname or file fields in the BOOTP packet can be overloaded to contain DHCP options. In those situations, DHCP options 66/67 can be used to provide the boot server and filename as regular DHCP options.

Currently, netboot/dhcp4 understands option 52 and handles the server and file fields either as themselves, or as DHCP options - but does not extract options 66/67 back into the appropriate fields of the Packet - which would be more sensible from the API user's perspective.

Marshal and Unmarshal need some tweaking to handle a situation where both option 52 and BootFilename/BootServerName are specified, and encode/decode appropriately

pixiecore: deprecated in CoreOS' bootcfg

Hi.

Just to raise awareness of it, I'll mention that CoreOS has recently deprecated Pixiecore support in their bootcfg tool, see the commit.

The commit message says:

Documentation: Deprecate Pixiecore support
* Focus on real-world, varied network environments
and flexibility, and bare-metal Tectonic
* iPXE provides better hardware introspection than being
limited to MAC
* ISC DHCP and dnsmasq provides production DHCP service
* Drop Pixiecore from the setups we can support or recommend

Note that the code is still there, but deprecated.

I'm currently using jhaals/waitron, which has no commits for over a year, but works good enough.

Cheers,

No ProxyDHCP response, retrying...

I'm running pixiecore in a docker container and when I start a new device from pxe, it first seems to boot correctly, as it is able to enter iPXE 1.0.0+, but then it is stuck in the "Configuring" step, with the "No configuration methods succeeded" "No ProxyDHCP response, retrying (attempt X/10)" error messages.

Here is the log from pixiecore:

sudo docker run --rm --net=host -v $(pwd):/pxe bbinet/pixiecore boot -d /pxe/linux /pxe/initrd.gz --cmdline 'auto=true url={{ ID "/pxe/debian_preseed.cfg" }}'
[Init] Starting Pixiecore goroutines
[DHCP] Got valid request to boot 00:22:15:45:dd:e3 (IA32)
[DHCP] Offering to boot 00:22:15:45:dd:e3
[DHCP] Ignoring packet from 00:22:15:45:dd:e3: packet is DHCPREQUEST, not DHCPDISCOVER
[TFTP] Sent "00:22:15:45:dd:e3/0" to 192.168.0.13:2070
[TFTP] clamping blocksize to "192.168.0.13:2071": 1456 -> 1450
[TFTP] Sent "00:22:15:45:dd:e3/0" to 192.168.0.13:2071
[DHCP] Got valid request to boot 00:22:15:45:dd:e3 (IA32)
[DHCP] Offering to boot 00:22:15:45:dd:e3
[DHCP] Got valid request to boot 00:22:15:45:dd:e3 (IA32)
[DHCP] Offering to boot 00:22:15:45:dd:e3
[DHCP] Got valid request to boot 00:22:15:45:dd:e3 (IA32)
[DHCP] Offering to boot 00:22:15:45:dd:e3
[DHCP] Got valid request to boot 00:22:15:45:dd:e3 (IA32)
[...]

Any idea what I'm doing wrong?

timeouts preventing pxe booting?

Hi, we're seeing some weirdness with pixiecore in API mode on proxmox hosts and we think it's related to the time it takes to provide the ipxe boot script which we can test like so:

time curl 'http://10.10.20.100:9090/_/ipxe?arch=0&mac=72:b7:ee:c8:01:01'
...
real	0m10.018s
user	0m0.001s
sys	0m0.006s

if we run the curl again it will be very fast (<<1s).

What's happening is our VM comes up and attempts to pxe boot from net0, fails, attempts to boot net1, fails, and the reboots. This will continue to happen with not much success. We can drop into the pxe command line and force things to work:

imgfetch -n pxe http://10.10.20.100:9090/_/ipxe?arch=0&mac=72:b7:ee:c8:01:01
...
boot pxe

This will run through our expected kickstart install and all is well, so I believe we can assume that pixiecore and the API are working OK. Is there some way to debug what we're seeing? Can the ProxyDHCP bits be affected by slowness to receive the boot image/script?

Also, I should say if we use pixiecore's static mode it works every time, but we lose the ability to provide a dynamic kickstart or control which MAC addresses we care about dynamically.

pixiecore: [not an issue] Pointer to a demo

Hi!

We demoed pixiecore + waitron usage at the OpenStack Summit that took place on October 2016 in Barcelona.

Here's a pointer to it, in case anybody is interested:

https://www.openstack.org/videos/video/innovation-at-bbva-next-generation-overlay-for-kubernetes-and-openstack

or, directly to the point where the pixiecore demo starts:

https://youtu.be/QyGHZ2HCwqY?t=440

Hope that it helps.

Cheers!

initrd-0 hanging at 99%

Hello.

New to using Pixiecore, but seeing some odd behavior in my experiments and I thought you might be interested. Hosting CoreOS images inside Pixiecore. PXE booting a QEMU machine against Pixiecore and the kernel transfers ok but the initrd hangs at 99% the whole time.

My research suggests Pixiecore may not provide a content-length header for the images which is why iPXE skips to 99% . Chances are my network config is just slow but I found the 99% part worth mentioning.

https://groups.google.com/d/msg/puppet-razor/wgzQzU8fzDY/BLUG4AdnZwsJ

Thoughts?

Thanks!

Running pixiecore on a specific NIC

I was unable to run pixiecore on any listen-addr other than 0.0.0.0, it seems to be the problem from raw socket, this patch works for me:

https://github.com/hangxie/netboot/commit/c8c1e91c96c06cfaa404de113b0d5b3820a49284

The patch forces raw socket listens on all NICs, but filter out those requests from IPs other than listen-addr, I believe there should be a solution better than this, but I don't know too much about bpf.

Allow passing an iPXE script through the API

As discussed in #4, Pixiecore doesn't expose the internals of the boot process by design. Specifically, you're not supposed to know that ipxe is being used to boot things.

... With that said, there are some advanced use cases that benefit from an API mode, but can't be shoehorned into a kernel+initrd. Those use cases really want to just pass a custom ipxe script.

I'm willing to add support for that, with the caveat that it will be explicitly documented as: it may break at any time if we stop using ipxe in the boot chain, it might not work everywhere, and it's the responsibility of the author to provide an ipxe script that does the right things.