Unix is a very flexible operating system if you know what you're doing, and linux is no exception. Since this is a class in operating systems and not in system administration, I wrote up this little guide for ways to connect to and interact with the skiff boards. This isn't a series of instructions to be followed in order, but an overview of the techniques you can use to get things done.

Contents

(Not so) Frequently Asked Questions/Encountered Problems

Changing your ramdisk

You may have noticed that nothing you do on your skiff board is saved across reboots. This is because the board copies its root filesystem into memory from flash RAM at boot time and never accesses the flash again unless explicitly told to do so (using the 'fw' command or the bootloader's load command).

So if you want to change the ramdisk used by the skiff board, you'll need to change the ramdisk image on your host system before you flash it to the skiff board. Since it's a raw filesystem image in a file, you need to find a way to mount it from the host machine. This is done with the linux loopback device. Fortunately, the mount command knows how to do this without you having to mess with the details: 

my_host:~# mount -o loop skiff-ramdisk-1.7-gt0 /mnt
This means to mount the filesystem contained in the file skiff-ramdisk-1.7-gt0 on the directory /mnt. The biggest problem with this is that it requires root permissions to do, so you'll have to do it at home. The machines in the skiff lab won't allow you to mount anything.

Once you get the filesystem mounted, though, you can make whatever changes you like. I've made an updated ramdisk that fixes some minor problems in the skiff lab (also available in /net/hl1/j/skiff-ramdisk-1.7-gt0.gz). It fixes the resolver so you can nfs-mount using "mustang" instead of having to type its IP, and it removes the automatic nfs mount from /etc/fstab that was causing delays for some of you. It also provides the command 'mount-lab' that will mount mustang:/net/hl1 on /net. It might save you some typing. I recommend starting with this image for any modifications you want to make. (I haven't tested it yet, though. Let me know if you run into any problems with it).

Note that a filesystem image needs to be uncompressed to mount but compressed to flash with fw. You can compress and uncompress it with gzip/gunzip.

Using the serial cable

This is the most basic way of doing things. New kernels, bootloaders, and ramdisks can be tranferred across the cable at low speed (kernels take 2 or 3 minutes, and a new ramdisk is closer to 20 minutes). However, the stock linux xmodem program, sx, won't work with the skiff boards. There is a version that works, though. Compile it, install it with "minicom -s", and you should be able to do xmodem uploads under linux. This working version of xmodem should be installed in the skiff lab.

Using NFS

A much quicker method of transferring data is through the ethernet interface. In the skiff lab, you can only connect to your assigned port with your assigned IP. Any other IP/port combination is restricted at the hub. You can check that you have connectivity by pinging your skiff board from a cluster machine (while the board is booted, of course).This is done by exporting files on your host machine with NFS (Network FileSystem, similar to "Windows shares"). You'll need to run an nfs server on the host machine to make that happen. The way you do this will vary depending on your linux distribution and whether you want to run the kernel or userspace NFS server. So the best I can do is point you to the NFS HOWTO and try to help if you run into any problems. When reading the howto, pay particular attention to the warnings about security. Running an NFS server can easily leave your system open to security vulnaribilities if it is not properly configured.

Once nfs is running, you can mount an exported directory from the skiff board using a command similar to: 

skiff60:~# mount -t nfs 130.207.98.11:/hl1/j /mnt
This means that I want to connect to the directory /hl1/j on the machine at IP 130.207.98.11, and make that directory appear as /mnt on my skiff board. The mount point /mnt must exist before you do this.

When mounting, you may get some portmapper errors. Don't worry, this is normal. You should find the directory successfully mounted anyway. In the skiff lab, you can use "mustang" instead of its IP if you've booted from the updated ramdisk mentioned in the ramdisk section

You can see what filesystems are mounted (locally and remotely) using 'mount' with no arguments: 

skiff60:~# mount
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,mode=0622)
130.207.98.11:/var/nfs on / type nfs (rw,addr=192.168.10.1)
In the skiff lab, the nfs server is already set up for you, and you should be able to nfs mount your group's shared directory. From any coc machine (like lennon or felix), these directories should be visible in /net/hl1, and should be nfs-mountable from the skiff boards at 130.207.98.11/hl1/<your_dir_name>.

Using fw instead of xmodem

Until now, we've updated the flash ram of the skiff boards by asking the bootloader to flash the memory and uploading the data via xmodem. The alternative is to use the 'fw' utility to flash the memory while the skiff board is booted into linux. The problem is that the version of fw on your skiff board is buggy and needs to be updated. To do this, you'll need to update your skiff board's ramdisk the old xmodem way. In the bootloader, do: 
boot> load ramdisk
and send a ramdisk image via xmodem. You can either make your own ramdisk as covered in the ramdisk section, or use the skiff lab customized ramdisk.

Once you've got an updated fw, you can use it to write new kernels and ramdisks to flash memory. Just put the kernel or ramdisk image you want to flash in an nfs-exported directory on your host machine, mount that export on your skiff board, then use 'fw' on the skiff board: 

skiff60:~# fw kernel /nfsmount/skiffzImage
skiff60:~# fw altkernel /nfsmount/skiffzImage
skiff60:~# fw ramdisk /nfsmount/new_ramdisk.gz

Using an nfs-root system

To take the use of nfs as far as it can go, you can mount ALL of your filesystem across NFS. This means you need to export the image of a skiff linux root filesystem on the host machine, and then tell the skiff board's kernel at boot time to mount that image as root rather than the one stored in flash. The first step is to unpack the root filesystem you'll be using and export it via nfs. You have several choices in doing this:

  1. Use your existing ramdisk. You could mount some directory on your host machine and use 'cp -a' to copy everything from the skiff board's ramdisk to the host machine. While this would give you a usable root filesystem on the host, the ramdisks on the boards we distributed are outdated. So you should:
  2. Use a ramdisk from CRL. The updated ramdisk is mentioned in the "using fw instead of xmodem" section above. You can either send it to the skiff board via xmodem, boot it, and copy it over nfs to the host, or you can mount the filesystem image directly via loopback. Either way, you need to get the filesystem image exported via NFS.
  3. Use the full root filesystem in FIXME. There are two tarballs: The smaller one is a root filesystem that should be mounted read-write, and the other is an image of /usr/FIXME that can be mounted read-only. Since these are tarballs, you only need to untar them where they can be mounted via nfs.

    This is probably the best option, because these filesystems are much more full-featured than the minimal ramdisks on the skiff boards.

Once you've got a root filesystem image exported, you need to tell the skiff board to mount it at boot time rather than the root filesystem in flash. You do this with the bootloaders "nfs_server_address" and "nfsroot" parameters: 
boot> set nfs_server_address 192.168.10.1
    setting param=nfs_server_address to value=192.168.10.1
boot> set nfsroot /var/nfs
    setting param=nfsroot to value=/var/nfs
boot> boot
If all goes well, the skiff board will mount its root filesystem across the network. Before trying this, you may want to change some files in the root filesystem. In particular, my /etc/fstab looks like: 
abraxas:/var/nfs	/		nfs	defaults	0 0
none			/proc		proc	defaults	0 0
none			/dev/pts	devpts	mode=0622	0 0
You don't want to leave the old ramdisk entry in there: 
#/dev/ram		/		ext2	defaults	1 1
Other things you may want to modify are /etc/resolv.conf, and whatever else you'd like to play with.

I know this is a lot of material, and I haven't treated it in the depth it deserves. Keep in mind that you don't have to do all of these things, and don't hesitate to ask for help if something won't work right.

Under linux, I'm getting garbage on the screen when I connect with minicom. How do I fix this?

You're running multiple copies of minicom on the same port. See what processes you're running: 
$ ps ax | grep minicom
 5120 pts/0    S      0:00 sh /usr/bin/minicom
 5121 pts/0    S      0:00 /usr/lib/minicom.real
 5160 pts/1    S      0:00 sh /usr/bin/minicom -o
 5162 pts/1    S      0:00 /usr/lib/minicom.real -o
If there is more than one minicom/minicom.real pair, you should kill the extras: 
$ kill 5120 5121 5160 5162

I have my program ready, but when I try to run it, I get 
bash: myprog: command not found

You don't have the current directory in your $PATH. Either add "." to your path, or run "/path/to/myprog" (or "./myprog if it's in the current directory) instead of "myprog".

NFS mounts and other network activity just hang and don't do anything in the skiff lab

You've probably connected your skiff board to the wrong port on the hub. Your ethernet connection will only work in the skiff lab if your board is configured with the proper IP and connected to the right port on the hub. Here are the port assignments.

You can test that your board is properly connected by booting it and pinging it from a cluster machine: 

[tamaulipas-lnx][\@](127) $ ping skiff112
PING skiff112.cc.gatech.edu (130.207.98.112) from 130.207.11.223 : 56
data bytes64 bytes from 130.207.98.112: icmp_seq=0 ttl=254 time=4.2 ms
64 bytes from 130.207.98.112: icmp_seq=1 ttl=254 time=1.0 ms

--- skiff112.cc.gatech.edu ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1.0/2.6/4.2 ms