GitLab

to go from PXEBOOTING (pxewakeup) to actually booting, but we do not
know that for a really long time cause we send a BOOTING event from
bootinfo right after PXEBOOTING, since that was the only place to hook
it in. Well Mike discovered the "on commit" support in dhcpd, and so
that is what we are going to use now. Note that uboot nodes have been
using on commit, now all nodes will when BOOTINFO_EVENTS=0.

Mike's reportboot program is now a daemon, renamed to report_daemon.
The original reportboot program is a little script that writes the
arguments from dhcpd to a unix socket to be picked up by the daemon,
which does the original work of mapping the IP/Mac to a node id and
sending an event. The code has also been modified to run on a subboss
using the same node mapping given to to dhcpd, reconstituted as DBM
file by subboss_dhcpd_makeconf.

The reason for using a daemon this way is so that we do not hang up
dhcpd in case we cannot get to the event system. The unix domain
socket will give us some amount of buffering, but I suspect that any
event problem will eat that space up quickly, and I will be back to
revisit this (probably want reportboot to not block on its write
to the socket).

pxeboot changed to not send PXEBOOTING or BOOTING when
BOOTINFO_EVENTS=0.

from boss libtestbed,pm into clientside version of same file.

about nobwshaping from Kirk.

Added skipping first step of wizard when instantiate button is clicked from profile

Merge request for issue #159

See merge request !17

(We all build out of the clientside configure dir for actual client
installs, but somebody has a comment in here implying it's good to keep
the file lists in synch, so...)

The problem is that nvme block devs on Linux have a radically different
naming convention (nvmeXnYpZ).  So, I just supported that.  I was going
to try to understand all the naming conventions, but I couldn't quickly
find a document that claimed to describe them all.  Oh well.

(I also added a fallback autodetect the rootdev on Linux that uses
newer methodologies, back when I hadn't understood the problem.)

to set the order we try the available architectures.

all nodes are untyped.

	Usage: createimagealias [-r] <image> target1,target2,...
		-h   This message
	        -r   Delete alias

The prepare script now supports pre and post hooks.  It runs all hooks
in rc order, from the DYNRUNDIR/prepare.pre.d and BINDIR/prepare.pre.d
dirs (rc order in this case is the BSD order, or my version of it ---
any file prefixed with a number is run in numeric order; other files are
run sorted alphabetically following numeric files).  Post hooks are in
prepare.post.d, and are run at the end of prepare.

(DYNRUNDIR is always /var/run/emulab .  STATICRUNDIR is usually
/etc/emulab/run but could be /etc/testbed/run, depending on the
clientside installation.)

We now allow users to override our default interface configuration --
and if they do, and tell us about it by writing a file in either
$DYNRUNDIR or $STATICRUNDIR named interface-done-$mac , we will not
attempt to configure it, and will assume they have done it!  If they are
nice to us and write
  $iface $ipaddr $mac
into the file, we will parse that and put it into the @ifacemap and
%mac2iface structures in doboot().  We do *not* attempt to provide them
the ifconfig info in env vars or anything; they have to grok our
ifconfig file format, in all its potential glory.

We read the hosts.head file(s) from /etc, DYNRUNDIR, and STATICRUNDIR,
and prepend them to our Emulab hosts content.  Then, we append the
content of the hosts.tail file(s) from /etc, DYNRUNDIR, and STATICDIR
--- and that file becomes the new /etc/hosts file.

getmanifest() has become getrcmanifest() to avoid confusion with the
GENI manifest.  Also, it now supports local manifests embedded in the
filesystem from $DYNRUNDIR and $STATICRUNDIR (priority is manifest from
exp, then DYNRUNDIR, then STATICRUNDIR).  All manifests read and
applied.  Local manifests may also reference local files instead of blob
ids, of course.  It is important to support local manifests so that
experimenters can hook our services by default in the disk image.

This mostly involves handling GPT GUID types.  Oh, we *do* use sfdisk to
set the part type for GPT disks.  We stopped doing it for MBR disks
because there was an observed behavior that sfdisk would whack the BSD
disklabel when setting the partition type.  But, I assume we'll never
have a BSD-partitioned disk in a GPT table, given our current partition
style.

(I also added a few optional (off by default) partprobes to deal with
some funny behavior when testing (i.e., setting part types from 0 to X
to 0, over and over).  The kernel is currently kind of funny.  It
creates /dev entries for block devices that have part type 0 at boot; it
creates /dev entries for block devs that you haven't edited when you
simply runs partprobe (or leaves them intact); but if you make a type
change from 0 to X and back to 0, partprobe /dev/foo does *not* create
the device.  I'm sure this behavior has to do with the limits the kernel
will accept for making changes to a disk with mounted partitions; but it
is nonetheless strange.  Anyway, this is optional because on some
kernels, at least, a forced partprobe will result in any 0-typed
partitions not showing up in /dev, which is not very helpful.  So it's
there if it's helpful during testing, I guess.)

1. Changes to gentopofile to not put in linktest info for links and lan
   with only one member.

2. Fix to the CM for deletenode of a node that has tagged links.

3. Fixes to the status web page for deletenode; we were installing the
   linktest event handlers multiple times.

4. Pass through -N argument to linktest from the CM, when the experiment
   has NFS mounts turned off, so that we use loghole to gather the data
   files (instead of via NFS).

This closes issues #160.

from the same random seed. This is quite possible the cause of stitching
failures. From the File::Temp man page:

"If you are forking many processes in parallel that are all creating
 temporary files, you may need to reset the random number seed using
 srand(EXPR) in each child else all the children will attempt to walk
 through the same set of random file names and may well cause
 themselves to give up if they exceed the number of retry attempts."

OSinfo and Image into a single object for the benefit of the perl
code. The database tables have not changed though.

can go in before the client side.

discussion in issue #134. Only studly user see this for now, so
that we can play with phony reservations.

Grey circles when cluster status is not found

Merge request for issue #167

See merge request !16