...
LinuxRT is installed on our system using the Preboot Execution Environment (PXE) method of network booting.
We enable the PXE/network-booting method in the BIOS.
In order to use PXE we need to setup there is a boot-server which that will allow our client system to :
(a) Request an IP address (via DHCP)
(b) Download a kernel (via TFTP)
With both of these services in place any system which supports PXE/network-booting
should be able to gain an IP address, fetch a kernel, and boot without an installed operating system.
PXE uses three distinct network protocols that map to three server processes to perform the installation.
In our case, all three some of the processes run on lcls-dev1 (LCLSDEV daemon)
PXE and DHCP server runs on host ....... maintained by SCCS in LCLSDEV.
(a) Dynamic Host Configuration Protocol (DHCP)
PXE uses DHCP to deliver initial network configuration options to client nodes.
The DHCP server supplies the PXE boot plug-in with
(i) IP address
(ii) TFTP server address
(iii) Stage 1 image boot-loader name from which to download and execute the image.
As the supplied PXE installation environments are non-interactive and will unconditionally reinstall a client machine,
we have the client associate its MAC address with a specific OS installation before starting the PXE boot.
The configuration information, in our case, in addition to IP/MAC address, includes a hostname and a pointer to the Master Starupt script in afs for our IOC.
It has an optional root-path variable pointing to the afs area which hosts the boot image that is served via TFTP.
This can be over-ridden as will be seen later.
When the Linux server is rebooted or power-cycled, PXE will attempt the network booting method first
and as a first step it will contact the DHCP server to retrieve the network configuration information.
Hence, every new linuxRT ioc (host) needs to be added to the DHCP server configuration file in afs.
This file is in /afs/slac/service/dhcp-pxe/dhcpd.conf
The IP/MAC address of the primary ethernet that will fetch the linuxRT boot image is defined here.
To add a new host to the DHCP configuration, contact Thuy.
Here's is an example - ioc-b34-bd32:
host ioc-b34-bd32 {
# SuperMicro (INTELx86)
#
hardware ethernet 00:25:90:D1:95:1E;
fixed-address 134.79.218.190;
option host-name "ioc-b34-bd32";
if ( substring( option vendor-class-identifier, 0, 5 ) = "udhcp" ) {
filename "/afs/slac/g/lcls/epics/iocCommon/ioc-b34-bd32/startup.cmd";
option root-path "afsnfs1:/afs/slac:/afs/slac";
}
}
(b) Trivial File Transfer Protocol (TFTP)
This on lcls-dev1.
PXE uses TFTP that defines a simple UDP protocol for delivering files over a network.
PXE delivers kernels and initial bootstrap software to client nodes using TFTP.
In our case, we retrieve the linuxRT boot image from lcls-dev1 (LCLSDEV TFTP Server) from the following location:
/afs/slac/g/lcls/tftpboot/linuxRT/boot
In this location, there are several linuxRT-x86 bootimages.
These were custom-built by T.Straumann for the various Linux Servers/IPCs that we currently have setup to boot with linuxRT OS.
Of these images, '3.14.12-rt9' is the latest and it has in-built support for the
Broadcom networking ethernet chipset that are used in our dev Poweredge Dell Servers.
(c) Network File System (NFS)
The NFS service is used by the installation kernel to read all of the packages necessary to the installation process.
The NFS server therefore needs to provide access to the directory structure containing the PXE images.
This boot directory is available to all machines running NFS.
8. How do I start my IOC? Where is my ioc's statrup.cmd?
...
set vers 3.14.12-rt9
This is also the place to over-ride the 'root-path' option specified in the DHCP configuration file dhcpd.conf.
For example, I may decide to over-ride the afsnfs1 server and instead choose to get my boot image from afsnfs2 server:
set extra-args ROOTPATH=afsnfs2:/afs/slac:/afs/slac BOOTFILE=/afs/slac/g/lcls/epics/iocCommon/ioc-b34-bd32/startup.cmd
A few more extra arguments are specified in ioc-b34-bd32. Leave them as they are.
The 'ipxe.ini' script loads and run the linuxRT kernel via the TFTP protocol:
kernel --name linux tftp://${next-server}/linuxRT/boot/${vers}/bzImage && initrd tftp://${next-server}/linuxRT/boot/${vers}/rootfs.ext2 || shell
imgargs linux debug idle=halt root=/dev/ram0 console=ttyS0,115200 BOOTIF_MAC=${net0/mac:hex} ${extra-args} || boot || shell
After linuxRT boot image is downloaded to the target and linuxRT starts to run, additional nfs mounts can will be done.
The afs to nfs translator service makes available the directory structure, to all clients that have mounted this nfs space.
NFS File Servers for LCLSDEV are afsnfs1 and afsnfs2
One of the arguments to the kernel process is the location of the BOOTFILE that does the mounting.
The 'filename' argument (which can be over-ridden by the BOOTFILE argument for linuxRT) is as follows:
"/afs/slac/g/lcls/epics/iocCommon/ioc-b34-bd32/startup.cmd"
This script is similar to and modelled after RTEMS startup.cmd.
When linuxRT loads and start, the kernel process is run as "root" user.
Hence it has permissions to setup the nfs mounts which is done by the following line in startup.cmd:
/afs/slac/g/lcls/epics/iocCommon/All/Dev/linuxRT_nfs.cmd
There is already an NFS mount point in AFS space to enable the the remote linuxRT target to access the control system central file server.
Additional NFS Mount Points for linuxRT pertaining to the ioc data directory $IOC_DATA are mounted as well
9. How do I monitor the server remotely as it boots up - after a power-cycle or after a 'reboot' command?
...
