CSB Laptop for Synchrotron Use -- Installation Notes

Disclaimer!

This describes the procedure I used on a particular laptop, with particular hardware, with apparent success. I do not claim, or even imply, that I or anyone else can successfully repeat this procedure even under identical conditions, let alone with inevitable variations.

Table of Contents

Linux Distribution

We used the standard RedHat 7.2 distribution, containing the 2.4.7 kernel. The docs for IEEE1394 (firewire) say that 2.4.7 thru 2.4.11 are unstable for IEEE1394 support. Initial testing with our 2.4.7 kernel has been OK. It may be that the stability probelms were with IEEE1394 devices ofther than disks -- most of the references I have found deal with video I/O devices.

At the time of this writing (2002.01.22) reports are good for 2.4.12, and for 2.4.14 thru 2.4.17. If I was installing the system now, I would check the extra effort to get the 2.4.12 kernel. linux/IEEE1394 docs, and maybe other linux sources, to get the most recent stable kernel.

Note that SBP2 driver support (necessary to support disk drives on IEEE1394) was only included starting with 2.4.7.

Top of Page

Partitioning the Disk

This is our partition layout:

/boot	hda1	24M
/usr	hda5	2000M	(shared by both)
	hda6	1000M	(used by both)
/	hda7	512M	(default (synchrotron) root)
/rootcore	hda8	512M	(core system)
/tmp	hda9	400M	(shared by both)
/home	hda10	3337M	(home for both)

If I was doing it again, I'd probably make /home smaller. It isn't big enough to store a significant amount of raw data. I'd make /usr larger. But it doesn't really matter.

Top of Page

Basic Linux Install and Configure

For the unedited logs of this phase, see http://www.csb.yale.edu/synchrotron/xanthippe-2.txt. But first, read the section above on linux distributions.

Top of Page

Install and Configure IEEE1394(firewire) Disk Support

For the unedited logs of this phase, see http://www.csb.yale.edu/synchrotron/xanthippe-3.txt and http://www.csb.yale.edu/synchrotron/xanthippe-5.txt.

• Install Maxtor 1394 pcmcia card in laptop. Connect Maxtor disk to the card and apply power. Boot laptop. Login as root.
• Installation instructions for IEEE1394 on linux are at http://linux1394.sourceforge.net .
• Website suggests using kernel 2.4.6, or maybe 2.4.12 or higher. We are running 2.4.7, and will try that instead of down- or upgrading.
• Downloaded libraw1394.
  # cd /root
  # gzcat /home/libraw1394_0.9.0.tar.gz | tar xvf -
  # cd libraw1394-0.9.0/
  # ./configure
  # make
  # make install
  # make dev
• Test progress so far.
  # modprobe ohci1394
  # modprobe raw1394
  # dmesg | grep 1394
  (should show info for ohci1394, ieee1394 and raw1394).
  # ./libraw1394-0.9.0/src/testlibraw
  (should report finding card. Should report successful tests on one node, failure on the other node (because a device is connected to only one node) ).
• (optional)Download diagnostic program gscanbus from debian website. Running this program dumped a lot of information about the Maxtor disk, along with a bunch of error messages. I didn't understand any of it, but it confirmed that the computer could see and talk to the Maxtor disk. I would skip this step unless you have trouble later on.
• More diagnostic procedures, gleaned from http://www.mandrakeforum.com/print.php?sid=1495&lang=en.
  # cat /proc/pci (shows a FireWire (IEEE 1394) device
  (after rebooting:)
  # modprobe ohci1394
  # modprobe sbp2
  # cat /proc/scsi/scsi (shows a Maxtor disk at scsi0).
  Note that the Maxtor appears as a SCSI disk, even though it is not.
• Format the disk. The disk arrived with one big FAT32 partition. I repartitioned it for EXT2, under the assumption that would be more efficient. Also, the FAT32 partition doesn't support unix-style file ownership and protection. In this section, my typing is in bold, and much of the program output has been cut. For the full log, see http://www.csb.yale.edu/synchrotron/xanthippe-3.txt.
  # fdisk /dev/sda
  Command (m for help): t
  Partition number (1-4): 1
  Hex code (type L to list codes): L
  Hex code (type L to list codes): 83
  Command (m for help): w
• Test the disk:
  # mkfs /dev/sda1
  # mount /dev/sda1 /junk
  # df -m /junk (shows about 55GB available)
  # chmod 1777 /junk (so anyone can create a directory there).
  # umount /junk
• If disk is not connected to firewire card when system is booted, the system will hang in /etc/init.d/pcmcia. I was not able to find a solution to this problem, although I am sure there is one. However, if you bring up the system with the firewire pcmcia card removed, there will be some error messages but the system will come up.
• Created a script /root/ieee1394 to load drivers and mount /frames on system startup. Invoke this script from /etc/rc.d/rc.local, which is run after all the other startup scripts. Note that this avoids startup problems that would occur if /frames is listed in /etc/fstab.
• On shutdown, the system excutes /etc/init.d/pcmcia stop before umounting filesystems. The system then suffers a kernel fault when it tries to umount /frames. I took easy way out and edited /etc/init.d/pcmcia, inserting at the beginning of the "stop" sequence:
  # umount /frames if it is mounted. a better script would check
  # for any filesystems mounted on any PCMCIA device. But this is
  # quick, easy, and doesn't have to be general.
  umount /frames
• With the kernel upgraded to 2.4.18-17.7.x, some of the above difficulties have been dealt with:
  
  
  • If the FireWire card is present on bootup, the relevant modules are loaded.
    
  • /etc/fstab has an entry for frames as follows: /dev/sda1 /frames vfat,ext3,ext2 noauto,users 0 0
    The options suppress the boot error messages from attempting to mount before the PCMCIA modules are loaded, and allow anyone to mount and unmount the disk.
    
  • /etc/rc.local can now simply contain the command 'mount /frames' to take care of mounting any disk that's attached at startup.
    
  • 'umount /frames' and 'mount /frames' can now be used to switch disks without shutting down the laptop.
    
  • If the disk is still mounted during shutdown, there are still error messages, but shutdown proceeds.

Top of Page

Create fixed-IP root partition for running HKL2000

For the unedited log of this phase, see http://www.csb.yale.edu/synchrotron/xanthippe-4.txt.

To review, this is our partition layout:

/boot	hda1	24M
/usr	hda5	2000M	(shared by both)
/	hda7	512M	(default (synchrotron) root)
/rootcore	hda8	512M	(core system)
/tmp	hda9	400M	(shared by both)
/home	hda10	3337M	(home for both)

The root partition is the only thing that changes between the two systems. I booted the default system, and logged in as root. I then used dd to copy hda7 (the active root partition) to hda8. This is really dumb -- you should use dump | restore. After using dd, I did fschk /dev/hda8 to fix the filesystem. Then I mounted hda8 onto /rootcore.

We now do a bunch of things designed to turn /rootcore into a root filesystem that will boot with the correct IP address for xanthippe.core. (The HKL2000 license is enabled forXanthippe.core).
# cd /rootcore/etc
# echo "xanthippe.core" > hostname
Edit fstab to mount hda8 as /, and not mount hda7. Edit hosts to include:
127.0.0.1 localhost.localdomain localhost
172.29.2.187 xanthippe.core xanthippe
172.29.2.10 bunter.core

# cd /rootcore/etc/sysconfig
Edit network: change hostname to xanthippe.core, add GATEWAY=172.29.1.1

# cd /rootcore/etc/sysconfig/network-scripts
# cp ifcfg-eth0 ifcfg-eth0.NC
# vi ifcfg-eth0
# diff ifcfg-eth0 ifcfg-eth0.NC
< BOOTPROTO=static
< BROADCAST=172.29.255.255
< IPADDR=172.29.2.187
< NETMASK=255.255.0.0
< NETWORK=172.29.0.0
---
> BOOTPROTO=dhcp

Reboot the laptop, while it is connected to the CSB Core network. From LILO, select Core to boot the new fixed-IP system. Get the HKL2000 programs. Note that we make /usr/local/bin writeable so that users can add detector files.
# cd /usr/local/bin
# ftp darwin
ftp> cd /srv/local/denzo/current/linux/
ftp> mget *
ftp> quit
# chmod g+w *
# chmod g+w .
# chgrp users .
# chgrp users *
# chmod +x *
# chmod +w /usr/local/bin

Add HKL setup to /etc/csh.cshrc (executed by all users when they log in):
echo "setting up for HKL2000"
setenv HKLDIR /usr/local/bin/
limit datasize unlimited
limit stacksize unlimited

Using /usr/local/bin/access_prod , generate information to send to HKL. They will return a cr_info which will be stored in /usr/local/lib/cr_info.

If desired, allow access from other core hosts (see detailed log). Add any corfe pritners you want to be able to access. Edite /etc/group to add standard CSB groups.

Top of Page