Southfox66

1. How To Share Netboot Image For Mac Windows 10
2. How To Share Netboot Image For Macbook Pro
3. Mac Netboot Image
4. Cached
5. How To Share Netboot Image For Mac Os
6. How To Share Netboot Image For Macbook Air

In our last episode we created two images: A NetBoot image to start an entire operating system over a network and a NetRestore image to restore a block-for-block image of an existing Mac. System Image Utility creates three types of network disk images: A standard NetBoot image provides a typical computing experience, albeit one that is hosted from a NetBoot server. When started from a NetBoot image the Mac operates nearly identically to a locally booted Mac OS X client or server. NetBoot was a technology from Apple which enabled Macs with capable firmware (i.e. New World ROM) to boot from a network, rather than a local hard disk or optical disc drive.NetBoot is a derived work from the Bootstrap Protocol (BOOTP), and is similar in concept to the Preboot Execution Environment.The technology was announced as a part of the original version of Mac OS X Server at Macworld. Next, depending on what you will be doing with NetBoot, like repairing clients with Disk Utility or DiskWarrior or if you are going to use Diskless NetBoot, you may or may not need to setup File Sharing with Apple Filing Protocol AFP. It is Needed for NetBoot network shadow files. Mac OS X 10.6 Client limited to 10 Concurrent AFP connections.

How To Share Netboot Image For Mac Windows 10

The ability to perform an ESXi Scripted Installation over the network has been a basic capability for non-Apple hardware customers since the initial release of classic ESX. However, for customers who run ESXi on Apple Mac Hardware (first introduced in vSphere 5.0), being able to remotely boot and install ESXi over the network has not been possible and customers could only dream of this capability which many of us have probably taken for granted.

Unlike traditional scripted network installations which commonly uses Preboot eXecution Environment (PXE), Apple Mac Hardware actually uses its own developed Boot Service Discover Protocol (BSDP) which ESXi and other OSses do not support. In addition, there are very few DHCP servers that even support BSDP (at least this may have been true 4 years ago when I had initially inquired about this topic). It was expected that if you were going to Netboot (equivalent of PXE/Kickstart in the Apple world) a server that you would be running a Mac OS X system. Even if you had set this up, a Netboot installation was wildly different from a traditional PXE installation and it would be pretty difficult to near impossible to get it working with an ESXi image. With no real viable solution over the years, it was believed that a Netboot installation of ESXi onto Mac Hardware just may not be possible.

tl;dr - If you are interested in the background to the eventual solution, continue reading. If not and you just want the goods, jump down a bit further. Though, I do think it is pretty interesting and worth getting the full context 🙂

It was only earlier this week in preparing for a customer call next week that I decided to re-open an email thread that I had with our Engineering folks which dates back almost 3 years ago. Although nothing had changed from the VMware side, this then lead me to check whether something had changed in the IT community via a Google search. To my surprise, I came across the following article where the author claimed they were successful in Netbooting a Mac system using Linux. The biggest breakthrough for me in that article which also built upon the work from another individual here (sadly the link recently died) was the fact that they were able to get BSDP working with a standard ISC DHCP server. This was the first challenge in just getting a basic response from a Mac system, which the solution indeed provided.

My first attempt of booting ESXi onto my Mac Mini used the traditional PXE/TFTP combo and it was partially successful. It was a success in the fact that the ESXi bootloader (bootx64.efi) was actually loading, but it would consistently fail at downloading the 11th file with a Fatal 33 (Inconsistent Error). I had tried various TFTP boot options including the per_source option which supposedly lifted the default 11 file limitation, but there no change in behavior. The theory that I concluded with was that the TFTP client on the Mac system might have just been limited as I was able to successfully download the file from a Linux-based TFTP client. However, this basic test in itself was also a break through as it proved for the first time, that it might actually be possible to Netboot ESXi onto Mac hardware.

While sharing the updated news with a few of our Engineers, Tim Mann, one of our Sr. Staff Engineers at VMware provided a great pointer to the next step that I could try. Given the fact that we were able to serve the initial files via TFTP, what we could try is to boot up iPXE and then chain load that to the ESXi bootloader. A very useful resource for general PXE/UEFI installation of ESX is this whitepaper here which is also authored by Tim. This is definitely worth having around when working with scripted installs of ESXi. With a few additional tweaks to the DHCP configuration file, I was able to fully boot the ESXi installer over the network to my Mac Mini! I was literally jumping up and down in front of my wife when this happened 😀 I believe this might actually be the first time this has ever been done before! Very cool if you ask me.

I have verified that this solution works for ESXi 6.5 and ESXi 6.0 out of the box. This solution also does work for ESXi 5.5, but you will need to use a newer ESXi bootloader (bootx64.efi) from ESXi 6.0 or newer as it contains some additional fixes. I have also verified that this works with scripted installs (Kickstart) as you would expect. I think and hopefully you will agree with me that this is HUGE news for the Apple/VMware community. Historically, it has been very challenging to manage Apple Hardware as installations of ESXi were mostly done manually or at least requiring someone to physically plug in the media to the system. Not only will this benefit customers of all sizes whether you manage several dozen Mac machines to several hundred which we have quite a few customers doing, but it will actually enable customers to scale even higher and faster now. No longer is this an operational burden which is something that I hear quite frequently from customers in terms of ESXi lifecycle.

OK, so now that you have some background on how we arrived at the solution, below are the steps to set this up in your own environment.

Pre-requisite:

• Ubuntu 16.0.4.1 already deployed
• ESXi 6.5, 6.0 or 5.5 ISO
• Apple Mac Hardware to test with. Although it didn't make difference, its worth checking that you are running latest EFI firmware on your Mac hardware.

Step 1 - Install the following packages by running the following command:

apt-get update && apt-get -y install isc-dhcp-server tftpd-hpa grub2-common grub-imageboot grub-pc-bin grub-efi wget net-tools build-essential liblzma-dev git apache2

Note: The initial reference article included several Docker Containers which I had started with to perform the initial test, but due to issues with journald not working within a Docker Container which made troubleshooting nearly impossible. I opted to just build this myself as it was pretty simple and allowed for easier debugging. I may consider building a specific Docker Container targeting the ESXi use case that folks can pull down and just use.

Step 2 - SCP the ESXi ISO to the Ubuntu system and run the following commands to extract the contents and place them in the webserver root directory:

mount -o loop VMware-VMvisor-Installer-6.5.0-4564106.x86_64.iso /mnt/
cp -rf /mnt /var/www/html/esxi65
umount /mnt
cp /var/www/html/esxi65/efi/boot/bootx64.efi /var/www/html/esxi65/mboot.efi

This will allow us to serve the ESXi bootloader from our webserver using http://[IP-OF-WEBSERVER]/esxi65/mboot.efi which will in turn load the ESXi installation files.

Step 3 - We need remove '/' (forward slash) character from ESXi's boot.cfg file by running the following command:

sed -i 's////g' /var/www/html/esxi65/boot.cfg

Step 4 - We need to add a prefix to the ESXi's boot.cfg to tell the Mac client where to download the ESXi installation files. To do so, add the following (replace with the IP Address of your Ubuntu system):

prefix=http://192.168.1.16/esxi65

Step 5 - When the ESXi bootloader runs, it will be looking for the boot.cfg in one of two locations. The first is in the root of your webserver /boot.cfg and the other is /[MAC-ADDRESS-OF-CLIENT/boot.cfg. The latter option allows you to control which version of ESXi is served to a particular Mac system. Assuming you would like that level of control, you will need to get the MAC Address of your Mac system prior to performing this step.

Create the following directory (replace the MAC Address with the Mac system):

mkdir -p /var/www/html/01-3c-07-54-77-af-54

Copy the boot.cfg from the specific version of ESXi that you wish to boot off of to directory you just created:

cp /var/www/html/esxi65/boot.cfg /var/www/html/01-3c-07-54-77-af-54/boot.cfg

Note: If you are lazy like me, you can skip this step and then just watch the apache logs for the failed request which will then give you the MAC Address of the system that you are trying to boot 😉

Step 6 - Next, we need to download and build iPXE from source. Run the following command to clone the ipxe Github repository:

git clone git://git.ipxe.org/ipxe.git

Step 7 - Change into the ipxe/src directory and then build the snponly.efi binary by running the following commands:

cd ipxe/src
make bin-x86_64-efi/snponly.efi

Step 8 - If you have successfully built iPXE, the following file should exists bin-x86_64-efi/snponly.efi and you will need to copy that over to your TFTP directory which by default is /var/lib/tftpboot, unless you have changed it.

cp bin-x86_64-efi/snponly.efi /var/lib/tftpboot/

Step 9 - We now need to edit our dhcpd.conf which is basically where all the magic happens. I have a fully functional version that you can use and modify or adjust your own DHCP server. To use the one I have, please run the following command to clone the repository:

git clone https://github.com/lamw/netboot-esxi

Step 10 - Copy the working sample-dhcpd.conf to DHCP configuration directory.

cp netboot-esxi/sample-dhcpd.conf /etc/dhcp/dhcpd.conf

You will still need to edit the file to adjust the networking to fit your environment starting with Line 1-2, 64-69. Line 106, 115 & 118 will also need to be updated to reflect the IP Address of your Ubuntu system. In the sample dhcpd.conf, the netboot class is what serves the initial iPXE image and then afterwards, the pxeclients class is what loads the ESXi bootloader.

Step 11 - Finally, the last step is to start both the DHCP and TFTP services by running the following commands. It is recommended that you run the status command to ensure there are no errors in your DHCP configuration file before proceeding to the TFTP service.

/etc/init.d/isc-dhcp-server start
/etc/init.d/isc-dhcp-server status
/etc/init.d/tftpd-hpa start

At this point, you are now ready to boot your Mac system! You will need a keyboard connected to your Mac as you will need to hold down the 'n' character to perform a Netboot (not sure if this is the default behavior or a way to configure it to do this on-boot?). You should see a globe icon for a few seconds and then see iPXE getting booted if everything was configured correctly. This process will be quite fast, but if you look carefully, you should see iPXE now chain loading the ESXi bootloader as you can see from this semi-blurry screenshot (took me several attempts to capture this).

Once the ESXi bootloader is loaded, it will then look for the boot.cfg file that we had configured in Step 8. Once it successfully locates this file, it will know where to download the ESXi installation files which will now happen over HTTP, rather than the traditional TFTP.

This part of the boot was blazingly fast compared to a traditional PXE installation where the files were being downloaded and serve via TFTP. This definitely will speed up deployments and something to consider in general whether you are doing Netboot or PXE Boot of ESXi.

I never thought I would be so happy to see our ESXi installation screen on the Mac 😀 There you have it, a successful Netboot of ESXi onto Apple Mac Hardware! The icing on the cake for me is that you do not need to have Mac OS X system to run the Netboot Server. This means for customers who are already doing PXE Installation of ESXi and other *nix OSes, they should be able to easily incorporate this into their existing infrastructure. One other thing I would like to try once I get some additional time is to see if this also works with vSphere Auto Deploy, which would also open another door for customers looking to leverage Auto Deploy and Host Profiles to easily manage and lifecycle their ESXi hosts running on both Apple and non-Apple hardware.

Scripted Installation via Kickstart

The instructions above only demonstrates how to boot an ESXi installer over the network to your Mac system. If you want to perform a scripted installation using Kickstart, you just need to simply place the Kickstart file on your webserver (I generally place them in the same path of the ESXi installation files) and replace the kernelopts line in the boot.cfg with the path to the Kickstart file as shown below:

kernelopts=ks=http://192.168.1.16/esxi65/ks.cfg

How To Share Netboot Image For Macbook Pro

I also have a very basic Kickstart script included in the Github repo that you had downloaded in Step 9 under netboot-esxi/sample-ks.cfg that you can use as a test.

vSphere Auto Deploy

If you wish to use vSphere Auto Deploy with Apple Mac Hardware, have a look at this article for more information.

Troubleshooting

There was quite a bit of trial/error during my experiments and so the following were useful for troubleshooting.

Here is the path to the webserver logs, this can be useful to quickly identify the MAC Address of the Mac system you are booting from as well as seeing what HTTP request are made when to retrieve the ESXi bootloader or installation files.

/var/log/apache2/access.log

For general DHCP and TFTP debugging, you can tail the system logs.

/var/log/syslog

During the validation of serving up iPXE via TFTP and trying to chain load to the ESXi bootloader, I found that the iPXE shell was not working (e.g. CTRL+B). This would actually allow me to confirm that I could in fact chain load the ESXi bootloader before spending more time in the DHCP configuration file. Due to it not working on the Mac hardware, I needed to compile an additional iPXE binary to include an iPXE script which would then retrieve DHCP address and then automatically start the iPXE shell.

To do so, you need to create a new file called ipxe.efi which contains the following code:

#!ipxe
dhcp
shell

Create the new iPXE image and embedding the ipxe.efi file by running the following command:

make bin-x86_64-efi/snponly.efi EMBED=ipxe.efi

Make sure to copy snponly.efi to your TFTP root, restart the services and the iPXE shell should now automatically load. From here, you can now see if you can chain load to the ESXi bootloader by running the following command on the iPXE shell:

chain http://192.168.1.16/esxi65/mboot.efi

This is really useful to see if there are any connectivity issues (especially pesky firewalls or selinux) that might be blocking the connection.

Home > Articles > Apple > Operating Systems

1. Understanding System Image Creation

For many deployments, the best solution is a unified system disk image, which involves creating an ideal system, saving it to a disk image, and then deploying that system to all your computers. A unified system image requires a significant time investment up front, but it saves a great deal of time in the long run. Computers with identical configurations are much easier to manage; the fewer the differences between your deployed systems, the more uniform their performance and the less time spent diagnosing problems, updating software, and reconfiguring hardware.

A unified system image also greatly accelerates the deployment process for any deployment larger than a dozen computers. Once you have fully configured, tested, and created a custom system image on one computer, it can take as little as five minutes to copy it to another machine. Compare this with the time needed to deploy the system individually on every computer, and it’s easy to see the benefit of a deployable system disk image. In this chapter you will learn two general methods for creating deployable system disk images: cloning from a model system and building a modular system.

Understanding System Image Creation

Before starting the process of creating a system image, you must consider your deployment requirements: what software and configuration settings will be part of your system image? Consider your users, your systems, and the limitations of identical-system deployment on multiple computers. You also need to consider which of the two image creation methodologies will best suit your needs and abilities. The choices you make while planning your system image will affect every computer on which this system is deployed.

Defining System Image Requirements

When identifying all the specific items and configuration settings that you want to include in your system image, you must take into consideration the requirements of your users, the technical requirements of your systems, and the limitations of deploying an identical system on multiple computers.

User Requirements

Your primary focus when developing system image requirements should be on maximizing system usability, for both users and administrators. In some cases your target audience or usage policies may require tighter system control. This is often the case when users are inexperienced or cannot be trusted to manage any part of their systems. In this scenario you would limit application access and lock down as many system configuration settings as possible. You would also want to make things easy for the user by preconfiguring any system setting you can. In scenarios where you will be performing a significant amount of client management, you should incorporate directory services–based managed preferences.

In professional or creative environments, you may not need to be as restrictive in the application or settings, but you should still make sure to prepare the system based on the users’ needs; for instance, install third-party applications and peripheral drivers for inclusion with your system image.

No matter the level of your users, your system image should be as fully configured as possible, with both Apple and third-party software installed and updated, any necessary support files such as third-party drivers and fonts installed, and any systemwide configuration settings implemented. Note, though, that many settings are not well suited to deployment via a unified system image—more on this topic later in this section.

Computer-Specific System Requirements

Before you create your system image, you must determine which version of Mac OS X you intend to use. A major administrative advantage of using Mac OS X v10.6 and Mac OS X Server v10.6 is that they include all the hardware drivers necessary to work with any Mac that meets the minimum system requirements, allowing you to build a single system image that can work on any Mac.

Although creating a unified system image for computers that support Mac OS X v10.6 is simple, creating a system image for brand-new Macs can present a significant problem. In many cases, because the release of new Mac computers is not in sync with the release of the retail version of Mac OS X, a custom intermediate version of Mac OS X is created just to support the new hardware. However, new Macs cannot run versions of Mac OS X released prior to their introduction—that is, the oldest version of Mac OS X supported by a new Mac computer is the version that it ships with from the factory.

Thus, a previously created system image will not work on new Mac computers, and you will have to create a new system image based on the version of Mac OS X that shipped with the new Macs. Further, these custom intermediate versions of Mac OS X may technically work with older Mac computers, but they are not officially supported by Apple to do so, presenting a problem when you are trying to build a single unified system image.

Fortunately, every general Mac OS X version update includes support for all Mac computers introduced prior to the update. For example, if you were to acquire new Macs that were introduced this week, the next general update of Mac OS X will include support for those new Macs and will support older hardware as well. Therefore, if you can wait to build your system image until you can base it on the next general update for Mac OS X, you can create a single system image for all your Macs. If you can’t wait that long, you will need to create a separate system image just for your new Macs.

It’s important to note that custom intermediate versions of Mac OS X for new computers do not use different version numbers from the general releases. They do, however, have different build numbers, which can be identified by clicking once on the version number from the About This Mac window.

Software Update Requirements

You should strive to build your system image using the latest versions of your selected software. To do this, you’ll need to collect and keep track of all the necessary software update installers that you’ll apply when building your system image.

First you need to determine and acquire the latest version updates for Apple software. Apple’s downloads website, www.apple.com/downloads/, lists all the latest updates and can be searched and browsed so you can locate and then download specific Apple software updates. However, it may not seem obvious which Apple updates are needed; for this reason you can open Software Update from the Apple menu.

Apple Software Update will compare your Mac’s current installed software with the latest versions available from Apple. Obviously, you should run this on one of your test deployment systems to verify exactly which updates are necessary. The Mac OS X v10.6 version of Software Update no longer allows you to download updates without installing them. Thus, if you want to acquire the updates for later installation or deployment, you will have to do so from Apple’s downloads website.

Mac Netboot Image

You should also verify that you are using the latest versions of third-party applications and drivers. Many third-party products feature a built-in automatic update system that will check online for updates. However, few of these third-party update systems will allow you to download the individual update installer so that you can later use it to build your system image. Again, in this case, visit the software developer’s website to download the individual update installers.

Limitations of a Unified System Image

You should include as many configured settings as possible with your system image so you don’t have to spend time setting these items on each individual computer. However, there are many settings that you should not, or cannot, deploy with the same configuration to every computer.

Cached

For example, in most cases, user-specific settings should not be included with your system image. Computer-specific settings also should not be configured on the system image. For instance, a unique IP address and network name needs to be set for every Mac. Both user- and computer-specific settings are best handled using dedicated client management tools and techniques.

In deploying a Mac OS X Server system image, your primary goal will be to strike a balance between what you can safely configure as part of the generic server system image and what settings you must leave for after deployment.

Choosing a System Image Methodology

When using the tools built into Mac OS X to create a deployable system disk image, you have a choice between two different methodologies: cloned system images and modular system images.

With a cloned system image, you first set up a model computer that is configured with all the software and settings you intend to deploy. Then you create a duplicate copy of the system volume saved to a disk image that has been specially prepared for deployment.

The modular system image methodology, a newer method, requires a bit more work up front, but it has several advantages over the older method and is the Apple-recommended best practice. With this method you build a fresh system by installing a series of installation packages to a sparse disk image. The installations include the full Mac OS X system, any software updates, any additional Apple software, any third-party software, and any custom installation packages that you have created to set up your system image. This sparse image is then converted to a disk image that has been prepared for deployment.

Cloned System Image Pros and Cons

• Pro—Easier workflow for novice administrators

• Pro—Less time spent creating initial system images

• Con—Requires that the model computer be purged of any unnecessary or troublesome files

• Con—Prone to issues if model not properly “cleaned”

• Con—Prone to more issues when deploying to different models

• Con—Increased workload when creating multiple system images

• Con—Increased workload when it’s time to update system images

• Con—New system images are never consistent with prior images

• Con—Difficult to document and audit system image configurations

• Con—Increased workload to test system image modifications

How To Share Netboot Image For Mac Os

Modular System Image Pros and Cons

• Pro—System images are clean because they have never been booted.

• Pro—System images have no model-specific settings.

• Pro—Apple updates won’t interfere with your customizations because they are always applied before your customizations.

• Pro—Your workload is lighter when creating multiple system images that require unique software and configurations.

• Pro—Your workload is decreased when it’s time to update system images.

• Pro—Multiple and updated system images are perfectly consistent for similar items every single time.

• Pro—All configurations are easily documented and easily audited.

• Pro—Testing of updates and image modifications are simpler.

• Pro—System image creation process is automated.

• Pro—It’s easy to integrate modular system images with system maintenance workflows and third-party deployment tools.

• Con—Workflow is more difficult for novice administrators.

• Con—You must create custom installation packages for some third-party items and any configuration settings.

• Con—You will spend more time creating an initial system image.

The cloned system image methodology requires less effort up front, and you can get your first image set up quickly. However, in the long run you’ll have to spend much more time fixing bugs, updating software, and adding modifications than with a modular system image. The modular system image methodology requires more initial effort to properly configure your first system image, but maintaining your systems will be much easier because you’ll be able to build new modular images with additional items and updated software.

Related Resources

• Book $55.99

How To Share Netboot Image For Macbook Air

• eBook (Watermarked) $55.99

• Web Edition $55.99