1. IPXE setup¶ If you will be using iPXE to boot instead of PXE, iPXE needs to be set up on the Bare Metal service node(s) where ironic-conductor is running. Make sure these directories exist and can be written to by the user the ironic-conductor is running as.
2. Hello, Currently in trying to boot PXE on the Imac and Macbook PRO. Thanks to the method contained in IPXE image Clonezilla it works for Macbook PRO, but we have a problem with the Imac blocking the message 'initialising devices 'that would be linked to t.

1. Ipxe Image For Mac Windows 7
2. Ipxe Image For Mac Os

Grumblings About MAAS

My last post was all about getting Metal-as-a-Service running. I must have spent a month of free time trying to get that to work. Once I understood all the moving parts, I was so incredibly disappointed that it was made so complicated by MAAS, and is so poorly explained in so many places online. I naturally wanted to do more with less. MAAS requires a lot of active resources (3GB of RAM + some fraction of a CPU) for something that is largely passive, and creating new images to remote boot is only supported with paid subscription. While slick looking and kind of cool for what little it really does, it really pushes you hard towards using Juju. Juju is quite heavy and runs continuously, eating another 3GB of RAM and a CPU or two on your master server. I didn't use it, because my impression is it tries to be both the orchestration of Kubernetes and application bundling of Docker at once. I literally only want to play with K8s and Docker, not find a substitute for it. So I dumped MAAS. I came away with some key learnings:

• IPMI is great for controlling the power state of remote machines.
• PXE booting is how you deliver OS upgrades, or indeed all OS images if you can.
• You have to tweak your DHCP server to hand out the correct TFTP server address for PXE booters to pick up their boot image.
• iPXE is tiny but awesome. It is a little bootloader that speaks HTTP so you can pick up a larger OS payload from a normal website (internal or external).

My Clarified Objective

I want to use a single master server to control a small set of slave servers that do have some storage, but essentially run ephemeral microservices in Docker via Kubernetes and can be shut down gracefully (ideally) at any time. I'd like the slaves to check in with the master when they boot up so they can be added to the control plane easily without manual configuration.

### Netbooting into iPXE from a MacOS X Netboot Server I spent the last few days trying to figure out how NetBooting works on a Mac which is different from traditional PXE netbooting. The goal was, to be able to boot from a number of recovery boot images like acronis, clonezilla etc.

Enter RancherOS

There is a pile of dead technologies out there. Finding live projects with a future is like picking through a civil war battlefield searching for your best friend, hoping he's still alive among the corpses. As far as I could tell, the Rancher is one of the few companies that has a number of very interesting projects going on, and are moving in the right direction. K3OS is one I wish were ready for my needs, but it's a little early and maybe too lightweight, as a Kubernetes-enabled operating system meant for Raspberry Pi style 'edge computing'. It appears to be an even slimmer version of its big brother, RancherOS, which is a Docker-first operating system that clocks in at ~100mb. That's it. The whole thing. Why? Because it runs almost every process in the entire Linux operating system, except the kernel, in a Docker container. I'm not certain if the first thing it does is download a bunch of Docker images or if they're baked in. In a nutshell, the OS is super-lean and runs all the normal system applications inside a Docker context called System Docker. There is another one called User Docker where microservices and non-OS applications run. It makes me terribly happy to know someone thought to do this, and that it appears to still be in development. There's something wonderful about being able to inspect every process uniformly, detect how it interacts with other processes, and launch or shut down everything in the operating system with the same commands. Amazing!

How about some useful stuff?

Enough jabbering. So it makes sense, 10.0.0.200 is the master server, and 10.0.0.250 is the bare metal box we'll be provisioning. The master has docker installed. That's pretty much it. Well, this isn't a tech post unless there's some bash going on, so let's get to it!

iPXE

Some prerequisite BIOS tweaks are requried here to get a server working with this config. First, make sure you set your server to boot BIOS not UEFI (it changes what images the bootloader will accept), and make sure the server's regular network card (not the IPMI one) has PXE boot enabled and DHCP enabled, and that NIC is the first natural boot device. You might want a USB thumbdrive or DVD to be the first boot, in case you might need to boot a linux rescue .iso for some reason. Finally, remember to configure your router's DHCP server to have PXE parameters as shown here. This is in my Ubiquiti Security Gateway, so your DHCP server will probably look different, but the features that matter are TFTP server IP, enabling network boot, and setting the filename PXE booters use to be /undionly.kpxe. While mucking about in there, you probably want to assign static IP addresses to your slaves based on their MAC addresses, so they don't move around on you.

The setup for this is really quite simple. I started with the rancheros-pxe-bootstrap repository and cloned it, then tweaked it a bit. It comes with some unnecessary complications, but the gist of it is you need a TFTP server and a Web server, because the TFTP server hands your bare metal box a tiny, custom-configured iPXE boot image that has instructions burned into it on how to reach your Web server once it wakes up. The Web server contains whatever OS image you actually want to boot.

The instructions for iPXE are stored in a file called installer.pxe. My version looks like this:

The base-url is just a convenience variable, but makes it easy to switch between the current latest-and-greatest RancherOS image or whatever I have sitting on my local server on port 83. The instructions here tell iPXE to wait for an IP address from DHCP, then load the kernel over http with a specific set of command line args, and a cloud-config yaml file from a different URL, also hosted on my internal network, finally load the initrd over http and begin the boot process.

Be aware that changing the file alone does not make an iPXE image. You still need to compile it into the image you want to host on TFTP with this clever little docker image command:

This command will read the installer.pxe file in the current folder and compile it into undionly.kpxe. Move the compiled .kpxe file to the host folder you bind to the TFTP server, as that's the file each PXE boot will fetch and run.

docker-compose.yaml

My simplified version uses an off-the-shelf microhttp server that simply needs to host a few files. Important note: the TFTP server requires exposing port 69, which cannot be changed, because it's built into the ROM of the PXE hardware. Remember to run docker-compose build once to generate the ipxe docker image. You only need to do this once, as the other files are mounted into the images via host folders.

To run RancherOS, go to https://github.com/rancher/os/releases/ and download initrd and vmlinuz from github and plop them into your ./www folder. The final file is the installer-init.yaml file, also known as a cloud-config. You will spend a LOT of time figuring out what to put in here, and probably customize it to do many many things, but a simple one that gets you basically running looks like this:

Note, the very first line must absolutely be #cloud-config or it changes how the file is parsed. And virtually every space and dash is crucial, because it's a yaml file.

Also worth noting is that you can certainly treat your servers more like cattle and less like pets. In my specific circumstance, I fully expect to be digging into screwed up machines and rebooting them often, so I want to set their hostname based on a convention. The easiest and cleanest way to do that is to set a DHCP option called host-name that lets you set the hostname based on the MAC address of the server when it requests an IP address. In my case, the trouble to set this up makes it untenable, so I threw together a quick script that fires at boot time to detect and automatically set the hostname locally before anything else really gets going, and naturally being Linux, you have to do it in three places. Just delete the runcmd block entirely if you don't need it.

IPMI

IPMI has been around a long while and lots of servers you're likely to pick up have it. There are similar systems on different platforms with different interfaces, such as ILO and Redfish. The idea is the same... it's like a miniature computer that is always available even when the server is off, and has its own ethernet jack just to report on the health of the machine. It can also turn on and off the power supplies, completely ignorant of the operating system status. So be careful!

There's an open source tool called ipmitool that gives you complete control over the machine remotely. I don't like there being built packages littered on my servers, so I found there is a great docker image that lets you launch ipmitool directly and execute a single command with it. I count that as an early Christmas gift.

Since IPMI only responds to requests, it does not require any special networking privileges or setup. I split out the IPMI_PASSWORD as a proper environment variable here because it's good practice, but if you're lazy, you can supply it on the command line as -e IPMI_PASSWORD=youripmipw. Just don't tell anyone I said so. Note, you will want to substitute the IP address for the IPMI address of the box you want to control, not its normal IP address... you know, the one that goes dark when the box is turned off? Some amount of digging through the BIOS is required to set up a server initially, such as setting the IPMI IP address, the username and password that can be used to control the machine remotely. Make sure the IP address is blocked out as reserved in your router's DHCP configuration, or you may cause trouble when something else gets a conflicting address by mistake.

Login to your brand new RancherOS box!

Your bare metal machine should boot up, load the iPXE stub, turn around and load the vmlinuz/initrd, and boot RancherOS. All of this will work once configured.

Problems I Ran Into

It wouldn't be right if things went according to plan. The most challenging part of all this wasn't setting up the servers and building the docker images. It was figuring out how to understand the RancherOS documentation for how it was going to interpret the cloud-init file. The turnaround time is about 5 minutes to reboot a server, so it took hours and hours to get results back from my tests. It turns out that two dumb things happened to conspire against me.

1. Don't start off using '--' in your kernel parameters. Do that later, once things are working. If you put your cloud-init file after the double-dash, it won't bother looking at it, and none of your SSH keys will get loaded in... or any other configuration changes you make.
2. Don't put 'tls: true' under a Docker tag in the YAML file unless you know how to configure it properly. That's not sufficient to set up TLS, and it will kill both your system-docker and docker instances, leaving you with an empty operating system running nothing.
3. The firmware for the Broadcom NIC that is in one of my servers was removed from the RancherOS distro earlier this year. It wasn't a huge problem to unpack and repack the initrd to contain my firmware, but it was a stumbling block, and a couple more hours to learn how to do it right.
4. ....likely a ton more things I blocked out already..

Happy Ranching!

• 1Netbooting Apple Mac
  • 1.1Using stones (aka startup keys)
    • 1.1.1ISC DHCP Server
  • 1.2Using bless

Netbooting Apple Mac

Intel Macintoshs all use (U)EFI - where common PCs have a BIOS - to bootstrap and to some extent talk to hardware. Several different ways exist to make those Macs boot from network. Depending on your preference and setup choose whichever suites you.

Untested hint: Verbose Mac OS boot: sudo /usr/sbin/nvram boot-args='-v' (https://groups.google.com/forum/#!topic/macenterprise/y1RnrjpvSr4)

Using stones (aka startup keys)

On startup (when you hear the sound, before Apple sign comes up) you can hold down different keys to make the Mac boot from network. Apple uses a kind of special protocol called BSDP which is partly similar to the well known DHCP protocol. But there is more to it. Find a detailed explanation here if you want to dig into it. This method is called 'Using stones' as people use stones or other similar objects to boot a whole lab of Mac clients by putting a stone on the keyboard to hold down the 'n' key - but there are other ways to achieve this too!

ISC DHCP Server

To make a Mac client boot from network you need to extend your DHCP server configuration. Add the following option to your subnet section:

To issue special answers to Mac clients you also need to define a class:

Important note: This simple config might only work with older Mac OS clients like MacBook1,1, MacBook6.2 and others. For newer models you need the advanced config

Restart the DHCP server after saving the configuration. Then booting up your Mac client hold down the 'n' key and you will see a globe spinning instead of the usual apple sign. The Mac requests an IP from the DHCP server which advises it to load iPXE via TFTP and boot that up.

architecture

That was easy. So now we can go into the details of delivering different iPXE binaries for varying Mac platforms:

Important note: This simple config might only work with older Mac OS clients like MacBook1,1, MacBook6.2 and others. For newer models you need the advanced config

To lookup Mac models and their architecture/CPU this website comes in very handy!

fancy

Newer Macs also have a fancy version of network booting. Hold down the 'alt' key and you will see different disks and network images to boot from. To make this work you need to modify the class definition:

Important note: This advanced config is proved to work with Macmini5,2, Macmini6,2, Macbook1,1, Macbook6,1, iMac12,1 and Macbookpro9,2

For more information about the rows of hex numbers see this excellent example. And here you can find a even more advanced example configuration.

Startup Disk

When using a proper Mac OS X server one can configure a NetBoot device/server in System Preferences -> Startup Disk. See here:

Unfortunatelly our previously configured NetBoot ISC DHCP server is not showing up in that dialog. It's just one simple thing preventing that. Mac OS sends a DHCPINFORM broadcast message to enumerate NetBoot images on the network. Usually DHCP messages are sent from UDP source port 68. But not in this case - Startup Disk enumeration sends DHCPINFORM with a random source port smaller 1024 (don't ask me why!). Here you can find a patch to make ICS DHCP server answer those messages properly.

DNSmasq

As well as ISC DHCP also dnsmasq can be configured to serve as netboot server for Mac clients:

Note: Only works with old Macs like Macbook1,1 and Macbook6,1...

Add those five lines to your configuration, save and restart the service. Try booting one of your Macintoshs holding down the 'n' key while it comes up. You should see a globe - instead of the apple - on the screen!

The more advanced config for dnsmasq looks like this:

This still does not address the issue of selecting the correct iPXE binary for 32 or 64 bit.

Using bless

An Apple Mac can be 'blessed' to boot from whichever source you want via commandline. This setting is saved in NVRAM and not changed by cloning your Macs via FOG. I'd suggest activating SSH on your Macs and use clusterssh to bless all of them without having walk to and login to each and every client.

To 'bless' your Mac turn it on and let it boot up as usual. Login and open the Terminal App and run the following command (use a proper IP instead of x.x.x.x):

According to this website the bless command is part of Mac OS X since 10.4.5. Earlier versions probably don't work that way!

No special DHCP configuration is needed for this! BUT if your server ip changes for example you'd have to run this command on all your clients again.

Culprits

Newer Mac OS X releases do not allow blessing as is. You need to allow using the address with a tool called csrutil. See here for more details: https://support.apple.com/en-us/HT205054

iPXE for Macintosh

As noted earlier there is a fundamental difference between Mac-EFI and PC-BIOS. Not just with configuring network boot but also when it comes to the binary being loaded via TFTP and executed on the client. To make iPXE work on Macs a lot of work has been done in 2014. Check out this thread if you are interested in the details: http://forum.ipxe.org/showthread.php?tid=7323

The mentioned DHCP class should point the client to the correct iPXE binary (ipxe.efi). FOG includes this binary in current SVN development tree or you can download a binary from the repository if you are still using an older version of FOG: https://svn.code.sf.net/p/freeghost/code/trunk/packages/tftp/

Depending on the hardware you have this might work for you straight away. If not, please get in contact with us on the forums so we can work on it to find a solution!!

Working devices

Macbook1,1 ...

Macbook6,1 (W89452MK8PX), nVidia NForce MCP79 (PCI ID 10de:0ab0) - http://www.everymac.com/systems/apple/macbook/specs/macbook-core-2-duo-2.26-white-13-polycarbonate-unibody-late-2009-specs.html

Macmini5,2 (C07G3W4ADJD1), Broadcom NetXtreme BCM57765 (PCI ID 14e4:16b4) - http://www.everymac.com/systems/apple/mac_mini/specs/mac-mini-core-i5-2.5-mid-2011-specs.html

Macmini6,2 (C07LR0UQDY3H), Broadcom NetXtreme BCM57766 (PCI ID 14e4:1686) - http://www.everymac.com/systems/apple/mac_mini/specs/mac-mini-core-i7-2.6-late-2012-specs.html

Ipxe Image For Mac Windows 7

Notes from developers

Apple and its proprietary way of doing things. Simple explanation, netboot is not pxe boot. OS X is very picky about netboot. The efi iPxe file first must be named boot.efi as well as match the architecture of the machine that is booting (for you thats 64 bit) secondly not all ethernet or wifi adapters will be visible to iPxe after handoff. DHCP must point to that file as well as the boot file also.

Basically you have a few options but I will line out what we do. When I create an image, on the “master” machine I create the smallest partition possible. In that partition I add the folders:/System/Library/CoreServices/

After that I add the 64 or 32 bit ipxe file naming it boot.efi. Again for you thats a 64 bit file

Ipxe Image For Mac Os

Now on reboot, hold down option and select that partition. If it is able to find your nics and boot to FOG then you are in good shape!!. If it works copy the partition you just created to a usb disk. Now use that to boot your machines. Realize that you can simply select the usb disk in the boot manager and once iPxe loads up pull it out, and use it on another machine (if you are doing multiple machines). Because of limitations in iPxe do not expect a pretty FOG Menu. No background picture and such.

If your nics are not visible to the efi iPXE then you will need to use the undionly.kpxe file.

Reference: https://forums.fogproject.org/topic/7358/cannot-boot-macbook-7-1-from-pxe/9

Related articles

Articles related to ISC-DHCP