The Diskless Terminal running from NT server Mini-HOWTOPavel Tkatchouk, ptkatcho@portal.cav0.1, June 19th 1999Table of Contents1. Introduction.   1.1 What is it for?   1.2 Do we need this HOWTO?   1.3 A bit of History.2. Project description.   2.1 Packaging.   2.2 Image.      2.2.1 Kernel.      2.2.2 MRFS.      2.2.3 Building MRFS.   2.3 Remotefs.   2.4 Booting sequence.      2.4.1 BOOTP, TFTP.   2.5 Bootprom.3. Resources.4. Copyright.5. Feedback and credits.1. Introduction.1.1. What is it for?This document describes how to build software distribution to run Java client on diskless terminal booted from Microsoft Windows 95/98/NT workstation. Package can also be easily modified to be used as Linux terminal or X Windows terminal's software. I found it also convenient for setup over the Ethernet of floppyless PS's, hard disk of which for some reason can not be accessed (sealed case under warranty, etc.).1.2. Do we need this HOWTO?To be honest, I'm not sure. There are few excellent HOWTO's (see 3. Recources) that up until recently I considered quite sufficient to build what I've done two years ago. But since my project uses MS Windows as a file server vs. traditional NFS there were some know-how's involved which number of people wanted to see in some formal document.1.3. A bit of history.My project at that time (1996) was to find OS/JVM that will allow to run Java application on hardware we manufacture. Hardware is practically generic x86 PC except it has no keyboard, hard drive, floppy drive, mouse, but touchscreen over LCD, plus some POS specific peripherals (badge reader, credit card reader, etc.). Due to cost consideration it had no any significant storage, so OS and Java client along with support binaries, libraries etc. had to be loaded remotely. Because our clients are exclusively Windows shops, Server had to be Windows as well. During evaluation of different commercial OS'es along with JVM's available it become apparent to my surprise that most promising solution was GPL one - Linux.2. Project description.2.1. Packaging.The whole distribution consists of remote file system (RemoteFS) residing on MS Windowsserver (NT Workstation, NT Server or Windows9x) and tagged bootable image. 2.2. Image.Image (~1.5MB) is generated by mknbi utility that comes with Etherboot package<http://etherboot.sourceforge.net>. It can include minimal root file system (MRFS) like in my case (since I had to boot client from MS Windows server and Linux kernel doesn't support SMBFS-Root, only NFS-Root. So I had to keep rootfs in the ramdisk). To generate image the following script can be used.#!/bin/sh# mkrootnet: makes tagged netbootable image# This image includes kernel and minimal root filesystem# to do initial boot.## Copyright (c) Pavel Tkatchouk 1996. All rights reserved.# Permission is granted for this material to be freely# used and distributed, provided the source is acknowledged.# No warranty of any kind is provided. You use this material# at your own risk.#DEVICEFILENAME="/tmp/file"		# temporary file to be used as deviceFSBLOCKS=4096   				# uncompressed filesystem size in KBOOTDISKDIR="/usr/BOOT/ROOTFS"	# root filesystem modelMOUNT="/mnt2"				# temporary mount pointROOTFS="/tmp/rootfs"			# root filesystem imageROOTFSGZ="/tmp/rootfs.gz"		# compressed root filesystem imageKERNEL="/usr/KERNELS/vmlinuz-nt"	# kernel imageKERNELTMP="/tmp/vmlinuz"		# temporary copy of kernel imageBOOTIMAGE="/tmp/img"			# tagged image to be booted by client# if you want ramisk more than default 4096 set CMDLINE, don't forget to# adjust $FSBLOCKS # CMDLINE="ramdisk_size=8192"		# parameters to pass to the kernel# echo "check:"echo "- if tftp server's download dir mounted to /mnt"echo "- loopback device is built-in or loaded"echo "\n press Enter when done"read tmp UPLOAD="/mnt/tmp"				# tftp server's dir to upload bootimageecho -e "\nZeroing $DEVICEFILENAME of $FSBLOCKS k"echo "to be used as device for root filesystem model"dd if=/dev/zero of=$DEVICEFILENAME bs=1k count=$FSBLOCKSecho -e "\nMaking file system on $DEVICEFILENAME"mke2fs -m 0 $DEVICEFILENAMEecho "Mounting $DEVICEFILENAME as a loopback device"mount -o loop -t ext2 $DEVICEFILENAME $MOUNTcurdir=`pwd`cd $BOOTDISKDIRecho -e "Copying files from $BOOTDISKDIR to $DEVICEFILENAME, please wait"find . -print|cpio -pmd $MOUNTecho "Unmounting $MOUNT"umount $MOUNTcd $curdirecho "Copying $DEVICEFILENAME to $ROOTFS"dd if=$DEVICEFILENAME of=$ROOTFS bs=1kecho "Compressing $ROOTFS, it may take a while"echo "Please wait..."if [ -f $ROOTFSGZ ];then	rm -f $ROOTFSGZfigzip -c $ROOTFS>$ROOTFSGZrm -f $ROOTFSecho -e "\nCreating netbootable image"cp $KERNEL $KERNELTMPmknbi -d ram -i rom -r $ROOTFSGZ -k $KERNELTMP -a $CMDLINE -o $BOOTIMAGEecho "Uploading $BOOTIMAGE to $UPLOAD"cp $BOOTIMAGE $UPLOADecho "Cleaning after ourselves"rm -f $KERNELTMP $DEVICEFILENAME $BOOTIMAGEecho "All done"In the above script actual image is generated by the following comand#mknbi -d ram -i rom -r rootfs.gz -k vmlinuz-nt -o imgwhere:	rootfs.gz - minimal root file system (MRFS);	vmlinuz-nt   - kernel;	img       - resulting image.Note:Default ramdisk size is 4096. It was enough for RedHat4.1 based minimal file system, but apparently not enough for 5.2 based. When this happens "end request:I/O error, dev 01:00 ..." error shows up. To fix that either use "mknbi -a ramdisk_size=8192" to pass parameter to the kernel (doesn't require kernel recompilation), or change /usr/src/linux/drivers/block/rd.c: int rd_size= from 4096 to 8192 or whatever and rebuild the kernel.                                                    2.2.1. Kernel.Kernels 2.0.30 and 2.0.36 have been used by author, although nothing is preventing you fromexperimenting with others. Kernel should include ramdisk support. The following <link to .config> configuration has been used to build <link to binary (kernel 2.0.30)>. You may find some components unnecessary, just exclude them and rebuild. Don't forget to change root device after you built the kernel (rdev vmlinuz /dev/rd).Gotcha's: apparently smbfs is broken in 2.2.x kernels. Symptoms: remote share is mountedjust fine but after a while fails with "smb_request: result = -32" errmsg. I've heardSuSe has fix for that.2.2.2. MRFS.Minimal root file system is required to get Linux up and running along with networking until it can mount remote file system to run X/Java from there. After image gets loaded from the server MRFS is decompressed into ramdisk. If you can afford a lot of ram on your terminal the entire remote file system can be moved to rootfs.gz. That will make your terminal more responsive.2.2.3. Building MRFS.  Some folks found it easier to start from scratch, others use known "minimal" Linux distributions(Linux Router, tomsrtbt, etc.), yet others prefer to start from "big" Linuces like I did. Everypath has it's pro and contras.Pruning standard distribution (RedHat, Debian, etc.) to your needs might be very time consuming.To ease that painful process I have used remotely booted diskless client with NFS-Root (see Etherboot's Readme, NFS-Root and NFS-Root-Client mini-HOWTO's, Diskless-HOWTO):- setup minimal RedHat4.1 install (networked workstation, X, no development, mail, etc., ~117MB);- find . -print|cpio -pmd /usr/NFS/ROOTFS - copy entire fs tree to NFS exported dir;- mknod /usr/NFS/ROOTFS/dev/nfsroot b 0 255;- build vmlinuz-nfs kernel according to NFS-Howto (built-in bootp,rarp,NFS,NFS root,NIC   driver,RAM disk);- rdev vmlinuz-nfs /dev/nfsroot - to set NFS root device; - build image for NFS-Root fs:  #mknbi -d rom -i rom -k vmlinuz-nfs -o nfsImage;- boot client while monitoring NFS file requests (by Solaris snoop);- copy files from /usr/NFS/ROOTFS to /usr/BOOT/ROOTFS (MRFS model) according to snoop's  filelist;- generate image by mkrootnet script (don't forget to point to the right kernel vmlinuz-nt).The above trick not only allows to determine the sought files set but also debug boot process analyzing NFS messages. I found it convenient to put "read tmp" statements into init scriptsfor debugging. Tracking files up until issuing login gives you <link to rootfs.gz> MRFS (~1MB) that can be used to boot Linux from ROM (flash, eprom, DiskOnChip, SanDisk, etc.) as well. All the other files requested by client (during starting X, Java, Java client) were put into (link to remotefs.zip, ~9MB).To restore MRFS model on your PC from the above rootfs.gz:- #cd /tmp- #gunzip rootfs.gz- #mount -o loop -t ext2 /tmp/rootfs /mnt- #cd /mnt- #find . -print|cpio -pmd /usr/BOOT/ROOTFS- #umount /mntNote: You will have to change attributes of some dirs, files (/etc/mtab, /etc/mtab~, /var/lock/subsys/*, /var/run/*, /dev/tty*, etc.) against standard. This is because with standard attribs diskless client refused to work. For example I had to change /dev/tty* ownerships to 99:99 from original 0:0 or 0:5, to get rid of errmsg "INIT: Id "1" respawning too fast: disabled for 5 minutes". Being admin illiterate I just chmod them to 777 and chown to 99:99 to make life easier. THIS IS SERIOUS SECURITY VIOLATION!!! Using keyboardless terminal with no daemons running in my case reduces the risk, yet I would appreciate very much those more experienced who will help to restore the right attribs while keeping the distribution working.Some "gotcha's" to watch for during MRFS building:- standard attributes/ownership of some files don't work;- rdev must be set (non-tagged image didn't work, so couldn't use config file to pass parrs   to the kernel);- diskless client writes 99:99 ownership on generated files;- "password incorrect" for root, but any other OK and su OK too.2.3. RemoteFS.Remotefs.zip file includes everything required by the system that can be located onremote file system, i.e after booting has been complete and remote file system mounted.In my case it is X Windows System and Java binaries, libraries etc. To use that file onMS Windows NT:- unzip remotefs.zip to some directory;- share this directory read-only as "usr" (or share as some other name and pass this name to  the client through bootptab configuration file for BOOTP server;- create an account username=root, password=linux on NT (can be set in bootptab).Note:There's no symbolic links on NTFS, so UNIX links must be replaced by copies on NTFS. To determine potential troublmakers one could use the following:- first copy required subset (according to snoop's intercept) from /usr/NFS/ROOTFS to   /usr/BOOT/REMOTEFS;- mount some share from NTFS to /mnt;- /usr/BOOT/REMOTEFS#find . -print|cpio -pmd /mnt 2>links;In the links file you will find names to work with.2.4. Booting sequence.Boot occurs in the following sequence:- bootprom sends bootp request,- bootp server responds with subnet mask, client's name, client's IP, TFTP server's IP,   bootfile name and some optional parameters (like NT's username/password to use it's share,  you could pass some other share name here as say T104="somedir");- bootprom downloads image from TFTP server;- kernel starts;- kernel decompresses MRFS in RAM;- system starts init using ramdisk root,- mounts remote file system from NT via SMBFS;- automatically logins;- starts xstart script located on remotefs (/usr/sbin) where you can start any of your  programs, change parameters, etc. without rebuilding the image.Below are some config/init sample files from <rootfs.gz>, <remotefs.zip>:<bootptab, change to link>t1:sm=255.255.255.0:sa=192.168.33.150:bf=img:T100="pavelnt4":T101="root":T102="linux"