VERSION 1.13 NOVEMBER 21, 2005 Pebble Install and Configuration for Prometheus E-balloon System ====== ======= === ============= === ========== ========= ====== Overview: This document describes how to install the Pebble Linux distro. on the compact flash. It then explains how to further configure the system for balloon flight operations. It also turns out to be a decent general tutorial on preparing an embedded PC to boot off of a compact flash. Why Pebble Linux? Pebble Linux was chosen for several reasons. The two main ones are that it's small and it's designed to run on a compact flash(CF). Compact Flashes contain a limited number of write cycles, so it is important to not have the filesystem continually writing small bits of log data to the flash. Pebble creates a ram disk for the log files and mounts the flash as read-only. The down side of pebble is that it's designed for a router and has many security modules and firewalling stuff loaded by default that are not needed for the balloon package. The other problem is that it contains the 2.4.xx kernel by default and the balloon system would be better off with the real time features of the 2.6.x kernels. The good news is that Pebble is a Debian based distro. and the packages on it can be easily updated/removed/added with the apt-get command. One word of caution though is that when apt-get is run it can pull down 100 Meg of package listings. So if you put it on a small partition less than 64 Meg and try to update the database it will fill up the flash. Pebble can be found at www.nycwireless.net/pebble/ Theses installation instructions were based on the pebble.README file. Section 0: Configuring the Prometheus board and Pre-boot hardware bugs: The whole point of configuring the compact flash is to get it to boot on the Diamond Prometheus single board computer. Here are some ways to customize Prometheus and to check that it is working correctly. . a) Prometheus jumpers need to be changed from factory default settings. These changes are mostly to activate all four COM ports, but there are other things to be changed as well. See the Prometheus hardware docs. b) Hook up Prometheus with a video board below and an adaptor board above. c) Boot prometheus. No flash is needed as we are setting up the BIOS only in Section 0. In the BIOS, enable booting through remote serial terminal. This allows watching Prometheus boot via serial cable without a video monitor and before LILO and then Linux take over. d) Also in the BIOS, disable the USB ports. If you don't the Linux boot process that you set up below will hang while initializing the Prometheus USB ports. e) One way to monitor the health of the board is to observe the current consumed on the 5V supply by Prometheus. A prometheus+flash alone consume about 1.0 Amps decreasing to 0.9 when get to login prompt. If are drawing substantially more or less than this, you have a hardware problem. We have blown up several Prometheii via power supply problems. f) A second health monitor is to see that the BIOS boot appears on Minicom via a serial cable. g) An intermittent hardware bug seen summer of 2004 allowed Prometheus to boot through BIOS but fail to detect a perfectly good compact flash and move on to LILO and Linux. One fix is to add 3 seconds of hard-drive pre-delay in the BIOS. A fix which is harder to quantify but probably more important is to reduce the crosstalk on the IDE cable from Prometheus to flash. If the cable is excessively cramped beneath the Prometheus board, it seems to make the flash detection unreliable. Section 1: Installation: (best done as root user) 1.1) Put the CF disk into the USB CF reader. The disk will show up under linux typically as /dev/sda, but it depends what other drives are on the system. It could show up as /dev/sdc or other. For this reason, the commands below show /dev/sdX. WARNING: It is extremely important to get the right device, as you will be partioning and formatting it. If you get the wrong device, you will be partitioning it. In the worst possible case, you may reformat and repartion your main hard-drive. Linux will let you do this, and it will keep running ... for a while! You can find out what device the flash is mounted as from doing a dmesg command or looking at /var/log/messages to see what device the CF was assigned to. At this point if the CF is new there will be no partitions on it. So the first thing to do is run something like cfdisk /dev/sdX or fdisk /dev/sdX Create 2 partitions. For a 1 GB we used something like /dev/sdX1 80M /dev/sdX2 920M Set the boot flag on /dev/sdX1 so lilo can boot from it. Here is what Prometheus flash partition table looks like on a 1 GByte flash. (fdisk with the -p option) Disk /dev/sdc: 1024 MB, 1024966656 bytes 32 heads, 63 sectors/track, 993 cylinders Units = cylinders of 2016 * 512 = 1032192 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 79 79600+ 83 Linux /dev/sdc2 80 993 921312 83 Linux 1.2) Create a file system for each partition. Currently ext2 was used for simplicity, but there is a new filesystem called JFFS2 designed for compact flashes that may work better. (Sticking w/ ext2 until further notice) mkfs.ext2 /dev/sdX1 mkfs.ext2 /dev/sdX2 Alternately, mkfs -V /dev/sdX1 will work. It defaults to ext2. 1.3) Mount the new partitions to the host system. mount /dev/sdX1 /mnt/cf1 mount /dev/sdX2 /mnt/cf2 It helps to make sure you already have the mount point directories on the host system. [cd /mnt; mkdir cf1; mkdir cf2; chmod 755 cf?] cf? means directory cf1 AND cf2. Thus executing a chmod 755 cf? is equivalent to running chmod 755 cf1;chmod 755 cf2. Just saves time and adds to your linux skills! Type "mount" afterwards to check that it worked. The "mount" command will only work if you have the /mnt/cf1 and /mnt/cf2 entries in your /etc/fstab file. If /etc/fstab is setup correctly, typing mount -a will replace needing to do the individual mount commands. To make mounting easier, you can modify /etc/fstab by adding these lines: (This is done on the host system not the prometheus system.) # USB PROMETHEUS FLASH /dev/sdX1 /mnt/cf1 auto defaults 0 0 /dev/sdX2 /mnt/cf2 auto user,rw,noexec,noauto 0 0 Note that sdX1 is mounted w/ defaults. If you mount it noexec, then no commands can be executed on it. Therefor, for example, you can't run lilo on it, which you'll need to do. The error in this case is exceedingly unhelpful "Permission denied". Even if you have the directories on cf1 set to rwx and even if you are root, the "noexec" option in fstab trumps all of that and prevents lilo (or any other command on the flash) from running. The "noauto" option stops mount -a from mounting /dev/sdX2. You really don't need it! 1.4) Unpack the pebble tar file onto the new mount point. (This needs to be done as root) cd /mnt/cf1 [change to the directory into which you want to untar the file] tar --numeric-owner -jxvf //pebble.vXX.tar.bz2 e.g., as of May 2005, it's tar --numeric-owner -jxvf ~/aainfo_linux/Linux/Sonde-software/pebble.v41.tar.bz2 This puts all the pebble files in their correct subdirectories on the compact flash. Note: --numeric-owner is part of the incantation to make this happen. 1.5) Update and install lilo on the CF cd /mnt/cf1/etc cp lilo-standard.conf lilo.conf When you are first bringing up a new Prometheus, you will be using the video driver board, so you want lilo-standard.conf, which puts lilo messages to the video monitor. When you are comfortable with that and are ready to output your lilo messages to the serial port, you can use lilo-serial.conf (In fact, the difference between lilo-serial and lilo-standard is only two lines, the "append" line and the "serial=" line are present in lilo-serial and not in lilo-standard.) /etc/lilo.conf is standard with any lilo distro. However lilo-serial.conf is not generic. It is included with pebble, so when you untar pebble onto the flash, you'll find /etc/lilo-serial.conf In fact, since you are hand-editing lilo to do the right thing, which .conf file you start with doesn't matter. When you finally have the .conf file in the form you like it, it must be copied to to /etc/lilo.conf on the flash before it can be used by lilo. Here is a working lilo.conf for serial port boot: ##################################################################### # # NOTE: boot and disk below must be set to wherever your distro # is currently mounted (while you're installing LILO). Don't mess # with anything else unless you really know what you're doing. # boot = /dev/sdX disk = /dev/sdX #(sdX is typically either /dev/sda or /dev/sdc # -- Depends on your development system setup, not on Prometheus) bios = 0x80 compact delay = 1 serial=0,38400n8 image = /boot/vmlinuz-2.4.26-pebble root = /dev/hda1 append="console=ttyS0,38400n8" label = pebble read-only # NOTE2: The append="console..." and serial commands make lilo # correctly output boot messages to the serial port. That way, you # can use a remote serial cable to watch the sonde boot once it's # buttoned up. Without this, you can't tell what the sonde is doing # until the ethernet comes up. Which means you can't debug it at all! # April 05. We find when the flash boots that sometimes # it spews garbage characters out the serial port. So far, this has always # occurred when minicom on the laptop was set to the wrong baud rate. # # NOTE3: The above file is actually quite a standard lilo.conf. One thing slightly # special about it is the presence of the serial= and append="console ..." lines. # These make it so that lilo spits data out the serial port ttyS0 (COM1 to DOS folks) # If both these lines were commented, the machine would still boot, but you would only # be able to tell that it did if you had a video monitor attached to it. # # NOTE4: The other special thing about it is that boot and disk are only used when # the MBR is first written. They tell what drive to write the MBR on. # /dev/sdc writes to LBA 0, whereas /dev/sdc1 writes to the first sector of the # first partition. Once the MBR is written, boot and disk aren't used anymore. # In fact, I believe that none of those parameters are actually written to # the MBR of the flash. # The parameters that ARE written to the MBR of the flash are from the # image, bios and root commands. # bios gives bios address of drive (which lilo uses. 0x80 means primary master). # image= tells where the linux kernel is. # root says what partition the image is on. # So the flash was mounted as /dev/sdc to be # written, but when the system boots off it, it will be /dev/hda! (For more # discussion, see the Appendix How to think about LILO and GRUB) # ##################################################################### chroot /mnt/cf1 lilo Below is typical response to this command: feynman etc # chroot /mnt/cf1 lilo Warning: LBA32 addressing assumed Setting DELAY to 20 (2 seconds) Added pebble * This runs lilo on the CF. Without the chroot it will run it on your host system! The chroot command is tricky. Read info coreutils chroot for more discussion. Here is a spontaneous essay about chroot, so you use it wisely. Chroot mystifies some people. You may think that it literally changes what kernel you are running or something really tricky. In fact, it only redefines the "root" of your filesystem. An example of a use for this command helps it make sense. Normally "Root" is the directory /. However, let's say you are working off of a compact flash on /mnt/flash but booted from the hard drive at /. You can change your "root" from harddrive to flash by chroot /mnt/flash Then cd /etc actually puts you in /mnt/flash/etc rather than /etc. Why is this necessary? Let's say you want to run lilo to make a compact flash bootable. Could do /mnt/flash/sbin/lilo. However, lilo by default looks for /etc/lilo.conf. Thus, even though you were running lilo on the flash, it would still pull the lilo.conf from the hard-drive. Doing a chroot /mnt/flash /sbin/lilo runs the lilo on the flash and pulls lilo.conf from /etc on the flash. 1.6) The system should now boot and configuration from the console can be done. umount /mnt/cf1 umount /mnt/cf2 remove the CF and put it into the E-sonde. At this point it should boot and you can login as root (there is no password yet.) 1.7) More configuration. You can do this by actually logging into the E-sonde, but I've assumed that you are doing all this with the compact flash still mounted to your host system. (Of course, if you do this from the sonde, the path /etc/network really means that, whereas, if you do this with things still mounted on your host, /etc/network is really /mnt/cf1/etc/network (and that applies to every other command given here). You could chroot if you prefer, but you don't have to. a) Configure /mnt/cf1/etc/network/interfaces ============================================ Replace the existing file with the following: #------------/etc/network/interfaces begin auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.0.100.xxx # where xxx is 181-186 for esonde_x netmask 255.255.255.0 network 10.0.100.0 broadcast 10.0.100.255 gateway 10.0.100.1 #------------interfaces end b) Configure /mnt/cf1/etc/resolv.conf ===================================== Replace /etc/resolv.conf with the following: #------------/etc/resolv.conf begin nameserver 10.0.100.1 #------------/etc/resolv.conf end c) Configure /mnt/cf1/etc/modules ================================= Replace /etc/modules with the following: #------------/etc/modules begin natsemi dscudkp #------------/etc/modules end If you look at original /etc/modules, you will see lots of content. You want it all gone because it loads lots of unneeded (and perhaps incompatible) modules. Also at this point go back and look at section 0 and see that you disabled USB in the Prometheus BIOS. If you didn't the Boot will hang just where it is initializing USB. The dscudkp usually doesn't load because you need to use the -force (-f) on the insmod usually due to it being compiled on a different kernel. The dscudkp is the driver for the A/D D/A IO on the Prometheus. The specifics for this driver will be discussed later in this doc. d) Create mount point for wxdata ================================ mkdir /mnt/cf1/wxdata cd /mnt/cf1 chmod ugo+rw /wxdata e) Configure /mnt/cf1/etc/fstab to mount hda1 ro and hda2 rw ============================================================ Replace /etc/fstab with the following: #------------/etc/fstab begin /dev/hda1 / ext2 defaults,noatime,ro 0 0 proc /proc proc defaults 0 0 tmpfs /rw tmpfs defaults,size=10M 0 0 /dev/hda2 /wxdata ext2 defaults,rw,exec,noatime 0 0 #------------/etc/fstab end e) Configure /mnt/cf1/etc/inittab ================================= vi /etc/inittab Comment out the last line: #NC:23:respawn:start-stop-daemon -S -c nocat --exec /usr/local/nocat/bin/gateway -- F Can also comment out these two (or not -- you just save some memory) # 2:23:respawn:/sbin/getty 38400 tty2 # 3:23:respawn:/sbin/getty 38400 tty3 f) Configure /etc/ntp.conf ========================== Replace /etc/ntp.conf with the following: #------------/etc/ntp.conf begin server 10.0.100.172 # feynman.nmt.edu (10.0.100.172) # If the sonde is on ethernet, it uses the network to set its time # The above setting was not used in 2004, so it remains to be # checked. # The only line used in summer 2004 was the following: # For the gps timekeeping add the following line. server 127.127.20.0 mode 2 burst prefer. #The above line means very specific things. "server 127.127.20" is a clugy #way of telling the ntp driver to discipline its clock using the local GPS with NMEA strings. #Read the full docs of the ntp driver /usr/doc/ntp/html/refclock.html #You will see that server 127.127.22.x decodes as a PPS clock discipline algorithm #while 127.127.36.x is a WWV radio discipline algorithm. There are about 40 different fake "IP addresses" #corresponding to 40 different types of local clock discipline algorithms that NTP can understand. #As if this abuse of IP addresses wasn't obscure enough, the .0 has a specific meaning as well. #.0 means that NTP will look for /dev/gps0. 20.1 means look for /dev/gps1, and so on up #to 127.127.20.3 means discipline with /dev/gps3. #The "prefer" comment means that NTP should use the GPS instead of Ethernet if both #are connected. #The ntp.conf file typically has a driftfile as follows # driftfile /var/lib/ntp/ntp.drift #The sonde omits the driftfile for two reasons: # # The /var/lib/ntp directory is typically mounted r/o # If the flash is moved to different hardware, the driftfile may # cause more harm than good. #------------/etc/ntp.conf end h) Create soft link to /dev/gps0 ================================ ln -s /dev/ttyS3 /dev/gps0 ttyS3 is used because the GPS is brought in on COM4 in our design. This creates a link between the gps driver for NTP (/dev/gps0) and the serial port COM4 (/dev/ttyS3). If you are a linux guru, you might be wondering if /dev/gps0 needs to be created with a mknod command. No. It is just a soft link to an existing device. The ln -s command above is critical, but it is also sufficient. Ambiguity: It has also worked to do the following: ln -s /rw/dev/ttyS3 /dev/gps0 In fact, this is what was actually done in 2004. The /rw directory on Pebble is somewhat mysterious. It appears to be a fake directory populated at run time (sort of like proc). If the flash is mounted on another machine, the /rw directory is empty, but if the sonde is running off the flash, the rw directory is populated. It is possible that this is some cluge to allow most devices to be read only, yet still let the system update the necessary. This is unknown for now. 1.8)Create password so can setup ssh. passwd - to set the root password ssh-keygen - sets up sshd keys SEE *** below for full procedure shutdown -r now or reboot *** ssh-keygen -t rsa When asked where to save it save in /etc/ssh/ssh_host_rsa_key When asked passphrase, just hit enter ssh-keygen -t dsa Note: The dsa key takes almost 5 minutes to generate. Have patience! When asked where to save it save in /etc/ssh/ssh_host_dsa_key 1.9) The system should now be accessible from across the network. ping 10.0.100.xxx scp balloon_tx root@10.0.100.xxx:/wxdata ssh root@10.0.100.xxx Where xxx is the assigned ip address. 1.10) Add software to default pebble install. apt-get install minicom setserial ntp This will install the full ntp, ntpd and ntpdate packages with the gps drivers. Minicom and setserial are also installed. When using apt-get, you will receive several "serious warning" messages. It works anyway. You will also be asked to run apt-get update. The sonde probably doesn't have enough memory for this. It works anyway (at least as of May 2005). When configuring minicom, you will be asked about the "meta" key. Take the default option (Do not use the meta key) When configuring setserial, select "autosave once" When configuring ntp-simple, don't let it overwrite ntp.conf (unless you want to just overwrite it again.) 1.11) Building the DSCUD drivers (from the host machine,not esonde) NOTE: It is now recommended that you use DSCUD58. The procedure in dscud_build.txt supercedes the procedure in this section, though this is still basically correct, if somewhat incomplete. a) untar the driver package LINUX-DSCUD57.tar.gz This runs on the Pebble 2.4 kernel. b) go into the gcc3 directory and run install.sh this will build the files and put the library files in /usr/local/dscud5 on the host machine /lib/modules/misc c)scp /lib/modules/misc/dscudkp root@10.0.100.xxx:/lib/modules/misc d) scp /usr/local/dscud5/load.sh root@10.0.100.xxx:/etc/init.d/dscud e) ssh to the e-sonde and run depmod -a * Remember to write to Sonde /usr/local/sbin/remountrw or remountro 1.12) Assume that you have followed dscud_build.txt procedure. Now log into the esonde either by SSH or console cd /etc/init.d chmod +x load.sh (It is a shell script that creates a mount directory for dscud and then simply does an insmod. You copied it to the flash already when you followed the dscud_build procedure.) cd /etc/rc2.d ln -s /etc/init.d/dscud S99dscud If you have forgotten to rename load.sh to dscud, then do ln -s /etc/init.d/load.sh S99dscud Also -- load.sh may fail (because of kernel mismatches). You can force it to load. Modify load.sh as follows: OLD: /sbin/insmod /lib/modules/misc/dscudkp.o dscud_major=$DEVICE_MAJOR NEW: /sbin/insmod -f /lib/modules/misc/dscudkp.o dscud_major=$DEVICE_MAJOR * This will allow the driver to load when the system is booting (this is the standard Debian boot-scripts trick. dscud.sh is the script that you want to run automatically on boot. Thus you create a link to that script, give it a priority (S99) and put the link in the /etc/rc2.d directory.) * You may want to clean out all the S?? files that you don't want running at runlevel 2 as well. * The S99 sets the run priorities. The init scripts start with S1 and work up through 99 being the last. Thus the dscud driver is the last thing loaded during boot. 1.13) Checking that dscud really loaded correctly. Since dscud loads as a module, do an lsmod and you will see natsemi crc32 dscudkp If you DON'T see dscudkp, then dscud is NOT loaded and Balloon_TX WILL NOT WORK correctly. The /etc/init.d files are trying to get dscud loaded. You can actually load it from the command line. "insmod -f dscud" will do it. (-f means force. When you do load dscud, you will see the kernel complain that the driver does not match the kernel version. It's OK. It works.) If lsmod does not show dscudkp, then Balloon_TX is not working correctly. It doesn't matter whether it claims to be working. (It might work for slow data acquisition, but the dscudkp module is needed for interrupts). 1.14) Serial Port setup Make sure /etc/rc2.d has a S13setserial and it's executable. * If no setserial in /etc/init.d/ then apt-get install setserial from pebble then from /etc/rc2.d/ ln -s /etc/init.d/setserial s13setserial Create /etc/setserial.conf /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test /dev/ttyS1 uart 16550A port 0x02f8 irq 3 baud_base 115200 spd_normal skip_test /dev/ttyS2 uart 16650V2 port 0x03e8 irq 9 baud_base 115200 spd_normal skip_test /dev/ttyS3 uart 16650V2 port 0x02e8 irq 15 baud_base 115200 spd_normal low_latency You might also edit last four lines of /etc/serial.conf # #/dev/ttyS16 set_multiport port1 0x107 mask1 0xff match1 0 #/dev/ttyS16 set_multiport port2 0x147 mask2 0xff match2 0 /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test /dev/ttyS1 uart 16550A port 0x02f8 irq 3 baud_base 115200 spd_normal skip_test /dev/ttyS2 uart 16650V2 port 0x03e8 irq 9 baud_base 115200 spd_normal skip_test /dev/ttyS3 uart 16650V2 port 0x02e8 irq 15 baud_base 115200 spd_normal low_latency Setting serial.conf and setserial.conf both may be redundant, but seems to be OK. To check that this worked, try: pebble:~# /etc/init.d/setserial start "Loading the saved-state of the serial devices... /dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A /dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A /dev/ttyS2 at 0x03e8 (irq = 2) is a 16650V2 /dev/ttyS3 at 0x02e8 (irq = 15) is a 16650V2 (low_latency)" Note that ttyS2 seems to come up with irq=2, though you tried to set to irq=9. Because of the way interrupt controllers work, irq9 is the first of the so called "secondary" interrupts. IRQ's 1-8 were on the first IBM PC. Around the time of the IBM-AT a second set of 8 IRQ's (9-15) was added, but it was connected to the first set through irq2. Thus irq9 is sometimes called irq2/9. They are not entirely independent. I don't know what would happen if you intentionally set ttyS2 to irq=2. Probably that would work as well. The entire reason that you are going to this trouble to set the irq's different for each COM port is that the COM ports are unreliable when they share irq's (they may work for a while, even several minutes, then suddenly hand or spew garbage. We actually saw this behavior on Prometheus before fixing the problem.) Another question about serserial is the baud rate. Most of the ports will be used at <115200 baud, but it's OK to set them this high in setserial. It's not a mistake. ================================================================== ** You are now ready for flight ** Currently (Summer2004) the balloon_tx program was started by hand before flight. Mostly this was done because the startup parameters were being tweaked on each flight. This should be automated though. There is a danger that the balloon might get launched without this program running, in which case tracking becomes more difficult. Section 2: Duplicating a working system onto other compact flash cards: 2.1) It is fairly easy and straightforward to create a duplicate of a CF. There is a command called 'dd' which will create a byte by byte image of a CF. In order to do this use the following command: dd if=/dev/sda of=image_file.out bs=512 The if= is the input device to be copied. of= is the output device or file. bs is the number of blocks to copy at a time. 512 is standard for most hard drives and CFs. - The above command will create a file of the same size of the compact flash. - It is best to do this as the root user. - /dev/sda is the device where the compact flash is. - The device should not be mounted. - The process can take a long time on a 1GB flash hooked to USB 1.1 - Make sure you have enough room on the local hard drive to store the file image. - It is recommended that you encode the file with the date of the image, such as pebble_20050203.img 2.2) The process can be reversed by issuing the following command: dd if=image_file.out of=/dev/sda bs=512 The CF can be un-formatted, but must be the same size or greater. The boot sector and partition table are part of the image so it should be rady to boot as soon as the command returns. Section 3: Advanced methods of creating CF images You want to save space on the local hard drive or time by only copying part of the CF. You may also want to move to a CF of different size. 3.1) You can copy only a single partition with the dd command with the followling: dd if=/dev/sda1 of=image_sda1_20050203.img bs=512 This creates an image file with just the first partion. On the e-ballon the first partion may only be 64 MB. 3.2) Now you want to create a CF that is only 256 MB. a) Put the new CF in the CF reader/writer. b) use cfdisk /dev/sda - create the new partiotion to the size you want. - set the first one as bootable. c) use lilo to make the CF bootable as outlined in section 1. d) use mkfs.ext2 /dev/sda2 to format the second/data partition e) mount the second partition: mount /dev/sda2 /mnt/cf2 f) copy any files such as balloon_tx to /mnt/cf2 3.3) This will build a smaller or large CF with the partion one setup with the pebble boot image. When it boots it should mount the second partition from the fstab table in partition one. 3.4) Beware that not all 1GB flashes are the same exact size even though they say they are 1GB. When copying images from one brand to another make sure they have the same byte counts when dd runs. 3.5) If they are different then the technique in this section can be used instead of duplicating the entire CF. ====================APPENDIX A================ ********How to think about LILO and GRUB********** Lilo has two personalities and functions. The first function is to write a master boot record on the drive or partition that you select. To that end, if you run lilo from a running machine, you end up writing the boot record in the location specified by the /etc/lilo.conf file. The second function is to boot a machine by locating the kernel and booting it. It is INCORRECT to think that in this second mode Lilo looks at the file /etc/lilo.conf to tell it what to do. It CANNOT look at this file, because it has not yet mounted a file system. Here is the practical upshot of this. Let's say you are running Lilo on a system and it doesn't do what you want. You tweak the lilo.conf file and reboot the system. The system STILL doesn't do what you want. Why? Because you tweaked lilo.conf, but you never ran lilo again (from the running machine) to rewrite the MBR with the information from the tweaked Lilo.conf. You can see this problem when using Lilo to output data through the serial port for a headless embedded system like Diamond Prometheus. Let's say you put a head (video display) back on the system and expect it to put data on the screen. It doesn't happen, because its MBR is still telling it to output to the serial port, not the screen. Not until you tweak lilo.conf AND rewrite the MBR do you see the data on the screen. (And not out the serial port.) This is particularly confusing, because it is precisely opposite to how GRUB works. The nice thing about grub is that /boot/grub/grub.conf IS read on boot, because grub DOES mount a file system that allows it to read grub.conf during the boot process. However, we don't use grub on Prometheus. Revision History: ======================================================================== Version 1.0 by J.Battles (created original document) Version 1.1 by R.Sonnenfeld Version 1.2 by W.Walden Version 1.3 by R.Sonnenfeld Version 1.4 by R.Sonnenfeld (adding versioning info on DSCUD) Version 1.5 by J.Battles (Reformatted code. Clarified and cleaned up a few issues.) Version 1.65 by R.Sonnenfeld (Added Appendix A and more discussion about LILO.) Version 1.70 by R.Sonnenfeld (Inserted section 0 on how to setup Prometheus) (Added discussion of how to check dscud driver loads correctly and how Debian boot scripts work in general.) Version 1.8 by W. Walden (Inserted notes found while cleaning out beige notebook) Version 1.9 by R. Sonnenfeld (Tested procedure again, fixed minor errors. Clarified exactly what went into the configuration files in section 1.7 and added tutorial info about mount and fstab) Version 1.11 by R. Sonnenfeld Final checkout -- Ran the entire procedure again and fixed more errors and open questions, particularly clairified the mysteries /dev/gps0.