tritondatacenter / sdcboot

SDC FDUM environment

sdcboot

This repository is now retired, as we deliver (only) iPXE straight from the ipxe repository. The below is of historical interest only.

This repository is part of the Joyent SmartDataCenter project (SDC). For contribution guidelines, issues, and general documentation, visit the main SDC project page.

Note that most of the contents of this repository are covered by their own separate licenses and copyright statements.

Development

This repository contains the following:

• FreeDOS 1.1 with all source and tools
• GNU Textutils compiled for FreeDOS, with all source and tools
• A submodule containing the syslinux repository, for memdisk
• A submodule containing a program for retrieving arguments to memdisk
• A submodule for iPXE, for non-DOS network booting
• A replacement for the BIOS int 0x14 service that actually works
• Glue for building the FreeDOS-related portions of the SDC boot system

The repository serves three main purposes: first, it contains the original sources for all DOS-related binaries. Since we don't have any ability to build them, they aren't really useful, but we still need them due to licensing requirements. Second, this repository assembles a FreeDOS boot environment usable on a USB key for Firmware Diagnostics and Upgrade Mode. This is not (currently) used by the SmartOS distribution. Finally, it builds an iPXE binary for use when netbooting compute nodes.

Note that there are a number of places where we use binaries checked in rather than building them ourselves. These are:

• memdisk (could be built from the syslinux repo)
• getargs.com (could be built from the memdisk_getargs repo)
• most of FreeDOS (could be built from the sources)
• the boot sector (could be built from FreeDOS sources, with effort)
• the GNU utilities for DOS (could be built from their sources)

In most cases, we do this because building these would require tools we do not have or that would be difficult or time-consuming to port, notably OpenWatcom. In the case of syslinux, we avoid building because the single tool we want is tied up within a giant hairball that has deeply embedded assumptions that it is building on GNU/Linux. We avoid building small assembly programs like the boot block because most DOS assembly programs tend to be written for NASM rather than the AT&T or GNU assemblers that are available to us. Each and every one of these could be fixed simply by doing work, but it's unlikely that most or any of these will need to be modified, and so it seems not worth the effort. If we do later need to change any of these before we finally rid ourselves of the need for them, we can revisit then. In any case, for those who so desire, all of the source is included here or in submodules. Changes to build from source would generally be welcome.

Testing

No tests are available.

sdcboot's Issues

ipxe error 0x040ee119 when netbooting compute nodes connected only to LAG ports

When attempting to boot a compute node using nics aggregated on the switch side (Cisco EtherChannel w. LACP), the configuration stage of ipxe will time out with error 0x040ee119.

The reason appears to be the time it takes an etherchannel-enabled port to move from the "waiting to be aggregated" state to the "Independent" state, during the ipxe part of the boot process. Usually, this means the server will attempt and fail multiple times to boot - randomly managing to boot, but most of the time giving up.

A quick/tested resolution is:

• add at the end of src/default.ipxe:

:retry 
autoboot || goto retry

• add in the GNUmakefile a line with:

EMBED=../../../src/default.ipxe \

Without the makefile change, the compiler seems to ignore default.ipxe

With the changes above, the compute node will attempt to boot from the first nic indefinitely. As a side effect, it will have to be configured with the correct PXE-enabled NIC(s) placed first in the boot sequence, or it will never boot.

Please advise if a PR is in order.

Inaccurate Contributing Guidelines

I want to fix this. I'm not annoyed, just concerned that contributions to this project are getting lost and interested in collaborating toward a solution :)

Problem

There is no Gerrit Code Review project, but the contributor guidelines linked in README.md suggest that it is required. As a hopeful contributor here, I feel discouraged and confused, but I'm motivated to resolve this.

Motivation

My Pull Requests (#1, #3 have gotten little to no attention). I thought that I must be doing something wrong, so I reviewed the contributor's guide linked in the README.md and immediately realized my error: I need to create CRs through Gerrit Code Review at https://cr.joyent.us/.

So, I created a cr.joyent.us account and added a remote to my working copy for CRs and went to push my changes there. I discovered that the joyent/sdcboot project doesn't exist in Gerrit.

I was back to square one. I have pull requests that probably won't be accepted, and a standard contribution process that can't be satisfied without changes to Gerrit.

Suggested Fix

Add CONTRIBUTING.md with either:

• a clear, concise description along the lines of GitHub's own recommendations:
  https://github.com/blog/1184-contributing-guidelines
• OR a link to the Triton contributing guidelines and the addition of a Gerrit project for joyent/sdcboot