Differences between revisions 1 and 2
Revision 1 as of 2005-12-03 01:05:31
Size: 1985
Comment: split from MississippiNetworkDiagram ala Calebs changes to news
Revision 2 as of 2005-12-03 03:36:10
Size: 11716
Comment: inserts procedures RussellSenior has been using to maintain/upgrade the software
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
== Maintaining the Image ==

The following is a description of how RussellSenior has been working on the software running on the metrixes. When I encountered them, all of the metrixes already had the BenjaminJencks firmware, referenced above.

=== Updating in place ===

The metrix firmware is a minimized Debian distribution. The /etc/apt/sources.list include these archives:

{{{
deb http://www.backports.org/debian/ stable kernel-2.6
deb http://debian.oregonstate.edu/debian woody main
deb http://security.debian.org woody/updates main
}}}

As long as the metrix has access to the internet it can be updated using the standard Debian methods.

{{{
# remountrw
# apt-get update
# apt-get upgrade
# apt-get clean
# remountro
}}}

For my personal sanity, I have installed "less". For testing/debugging, I have installed "tcpdump", and to keep the clock remotely in sync I have installed "ntpdate" (this seems to be hanging briefly during bootup, not sure why).

=== Building Software ===

In order to incrementally build software (e.g., new kernels, madwifi drivers, utilities) for the metrix, one needs a build environment that corresponds to the one on the metrix. My initial attempt to build the madwifi utilities produced partially-broken results because I failed to do this (binaries were linked against symbols that didn't exist in the metrix-installed libraries). Here are the steps I went through to create and use the build environment.

The host for this work was a Debian/unstable system.

  ==== Unpacking the Image ====

  First, create a directory in which to work, e.g. /src/mississippi/ and download the starting image there:

  {{{
  $ mkdir /src/mississippi
  $ cd /src/mississippi
  $ wget http://cornerstone.personaltelco.net/~brj/metrix-missnet.img
  }}}

  The downloaded file is 64,028,672 bytes (125,056 512-byte sectors). This represents the /dev/hda flash device on the metrix. It includes the boot sector and partition table, and the root partition /dev/hda1. Grub is used as the boot loader (a rather old feature-missing version, which it would be nice to update, to, for example, be able to control the "next boot"). Before we can mount the first partition, we need to dissect the image a bit. We set up a loop block device associated with the image.

  {{{
  $ losetup /dev/loop0 metrix-missnet.img
  }}}

  Now, run fdisk on the loop device to figure out where the first partition begins. Use the -u option to fdisk in order to get sector units.

  {{{
  $ fdisk -u /dev/loop0

  Command (m for help): p

  Disk /dev/loop0: 64 MB, 64028672 bytes
  4 heads, 32 sectors/track, 977 cylinders, total 125056 sectors
  Units = sectors of 1 * 512 = 512 bytes

        Device Boot Start End Blocks Id System
  /dev/loop0p1 32 125055 62512 83 Linux

  Command (m for help): q
  }}}

  Take particular note of the starting sector of the first partition. We'll need that in just a bit. Now disassociate /dev/loop0 from the image file.

  {{{
  $ losetup -d /dev/loop0
  }}}

  Now you have a choice. You can either make a copy of the first partition, which you can mount, or you can create a new loop block device offset to the start of first partition and modify it "in place". I chose the former in order to preserve the original, but for reference, you can create the offset loop device as follows. Note that 16384 bytes is the starting sector (32) multiplied by the sector size (512 bytes).

  {{{
  $ losetup -o 16384 /dev/loop0 metrix-missnet.img
  $ mkdir metrix-missnet
  $ su
  # mount /dev/loop0 metrix-missnet
  }}}
  
  Now, what I did instead:

  {{{
  $ dd if=metrix-missnet.img of=metrix-missnet-part1.img skip=32
  125024+0 records in
  125024+0 records out
  64012288 bytes (64 MB) copied, 7.40427 seconds, 8.6 MB/s
  $ su
  # mount -o loop metrix-missnet-part1.img metrix-missnet
  }}}

  ==== Creating the Build Environment ====

  Now you have access to the image's filesystem through the metrix-missnet mount point. However, the little 64Meg filesystem is too small for the build tool chain, so we are going to create a working copy next door, that we'll chroot into and install the software there. Because we're working with root owned files, we need to stay root here for a while.

  {{{
  # rsync -v -a -H metrix-missnet/ metrix-missnet-build-env/
  # chroot metrix-missnet-build-env
  }}}

  Now a little explanatory digression is necessary. The metrix-native environment runs with the filesystem mounted read-only. It copes with changing files by symlinking them to a /rw tmpfs filesystem. That /rw filesystem gets populated during boot from static versions in a /ro tree.

  You are going to be needing to install software from Debian archives, but your DNS resolution won't work until you modify the build environment's /etc/resolv.conf to something that works for you locally. However, /etc/resolv.conf is a symlink pointing at /rw/etc/resolv.conf. At this stage, that file doesn't exist, since /rw is just a mount point in the original. There are lots of potential solutions to this problem. I took the most direct one, effectively replicating what the metrix itself does:

  {{{
  # rsync -v -a -H /ro/ /rw/
  # vi /etc/resolv.conf (as appropriate)
  }}}

  Then ping some well-known host to confirm that your network is functioning in the chroot.

  {{{
  # ping www.google.com
  PING www.l.google.com (66.102.7.147): 56 data bytes
  64 bytes from 66.102.7.147: icmp_seq=0 ttl=238 time=56.0 ms
  64 bytes from 66.102.7.147: icmp_seq=1 ttl=238 time=56.4 ms
  64 bytes from 66.102.7.147: icmp_seq=2 ttl=238 time=60.8 ms
  64 bytes from 66.102.7.147: icmp_seq=3 ttl=238 time=59.7 ms

  --- www.l.google.com ping statistics ---
  4 packets transmitted, 4 packets received, 0% packet loss
  round-trip min/avg/max = 56.0/58.2/60.8 ms
  }}}

  ==== Install toolchain ====

  {{{
  # apt-get update
  Hit http://debian.oregonstate.edu woody/main Packages
  Hit http://debian.oregonstate.edu woody/main Release
  Get:1 http://security.debian.org woody/updates/main Packages [245kB]
  Get:2 http://security.debian.org woody/updates/main Release [113B]
  Hit http://www.backports.org stable/kernel-2.6 Packages
  Hit http://www.backports.org stable/kernel-2.6 Release
  Fetched 245kB in 5s (48.4kB/s)
  Reading Package Lists...
  Building Dependency Tree...
  # apt-get upgrade
  Reading Package Lists...
  Building Dependency Tree...
  7 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  Need to get 1259kB of archives. After unpacking 61.4kB will be used.
  Do you want to continue? [Y/n]
  }}}

  Say yes. Now, install the toolchain:

  {{{
  # apt-get install make gcc libncurses5-dev
  Reading Package Lists...
  Building Dependency Tree...
  The following extra packages will be installed:
    binutils cpp cpp-2.95 gcc-2.95 libc6-dev
  The following NEW packages will be installed:
    binutils cpp cpp-2.95 gcc gcc-2.95 libc6-dev libncurses5-dev make
  0 packages upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
  Need to get 6576kB of archives. After unpacking 24.8MB will be used.
  Do you want to continue? [Y/n]
  }}}

  Say yes. You may get a warning while configuring binutils about a possible kernel link failure. It applies to older kernels, and we'll be using something newish, so it shouldn't affect us.

  


  ==== Building a Kernel ====

  Now, download a kernel tarball. I'll use 2.6.14.2 here. Since I forgot to install bzip2 above, I'll just download the gzip'd tarball and unpack it:

  {{{
  # cd /usr/src
  # wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.2.tar.gz
  # tar xzvf linux-2.6.14.2.tar.gz
  }}}

  Start with the kernel config in /boot:

  {{{
  # cd linux-2.6.14.2
  # cp /boot/config-2.6.12.3-metrix .config
  # make oldconfig
  }}}

  I selected defaults for everything, except:

    * Dell Systems Management Base Driver (DCDBAS) [M/n/y/?] (NEW) n
    * Generic IEEE 802.11 Networking Stack (IEEE80211) [N/m/y/?] (NEW) y
    * Inotify file change notification support (INOTIFY) [Y/n/?] (NEW) n

  Note that this configuration is set up for a Metrix Mark II, with a Soekris 4826 board and a Geode GX CPU. In order to work with the Metrix Mark I, which uses a Soekris 4526 and an AMD 486 clone, you need to modify the configuration, e.g. using "make menuconfig". Trying to boot the 4526 with a Geode compiled kernel will choke as follows:

  {{{
  CPU: AMD 486 DX/4-WB stepping 04
  Kernel panic - not syncing: Kernel compiled for Pentium+, requires TSC feature!
  }}}

  Next, compile the kernel:

  {{{
  # make
  # make install
  # make modules_install
  }}}
  
  The modules are installed in /lib/modules/2.6.14.2-metrix. Edit /boot/grub/menu.lst, adding a stanza for the new kernel. For example:

  {{{
  title Debian GNU/Linux, kernel 2.6.14.2-metrix
  root (hd0,0)
  kernel /boot/vmlinuz-2.6.14.2-metrix root=/dev/hda1 ro console=ttyS0,19200n8 panic=5
  savedefault
  }}}

  Since we have no consoles on the metrixes in the field, and no non-volatile storage is available to record any oops messages, there isn't much purpose served by having a panic just halt the device, so I've added the panic clause to the boot options in hopes that will recover the device in the case of a fault.

  ==== Building the Madwifi-ng modules and utilities ====

  [more to come]

  ==== Installing the new software ====

  ==== Creating a new image ====


Firmware Image

The image for the Metrix boxen is at http://cornerstone.personaltelco.net/~brj/metrix-missnet.img It is setup with all 3 interfaces bridged, and br0 set to 10.11.104.5/22.

To flash:

  • Setup a sarge installer pxeboot environment.
  • Netboot the metrix into the installer
    • Attach a serial terminal.
    • 19200 baud, 1 bit parity, no flow control
    • Press ctrl+p at the prompt to get to the BIOS
    • boot f0

    • Use expert26. You don't need any extra options.
  • Go through the installer up through step 9 (Download installer components). This is where device drivers are loaded.
  • After the drivers are loaded, go to a shell.
  • wget -O - http://somewhere/foo/metrix-missnet.img | dd of=/dev/discs/disc0/disc bs=1M (don't get it straight from cornerstone, copy it to your machine first)

  • Reboot

Note: as of 2005-10-11 this process isn't working for me. The Metrix stalls during the PXELINUX stuff. I think it's probably just an issue with my setup but I've got it working fine using the documentation from Metrix. (- KeeganQuinn)

The way the Metrix website says to do it is actually better. When I was working on the metrixes, though, that documentation didn't exist, to my memory. The debian netboot was simply the easiest way I could find to get a shell netbooted. (- BenjaminJencks)

Can KeeganQuinn or BenjaminJencks please point at or reiterate the referred-to Metrix documentation here? --RussellSenior

Maintaining the Image

The following is a description of how RussellSenior has been working on the software running on the metrixes. When I encountered them, all of the metrixes already had the BenjaminJencks firmware, referenced above.

Updating in place

The metrix firmware is a minimized Debian distribution. The /etc/apt/sources.list include these archives:

deb http://www.backports.org/debian/ stable kernel-2.6
deb http://debian.oregonstate.edu/debian woody main
deb http://security.debian.org woody/updates main

As long as the metrix has access to the internet it can be updated using the standard Debian methods.

# remountrw
# apt-get update
# apt-get upgrade
# apt-get clean
# remountro

For my personal sanity, I have installed "less". For testing/debugging, I have installed "tcpdump", and to keep the clock remotely in sync I have installed "ntpdate" (this seems to be hanging briefly during bootup, not sure why).

Building Software

In order to incrementally build software (e.g., new kernels, madwifi drivers, utilities) for the metrix, one needs a build environment that corresponds to the one on the metrix. My initial attempt to build the madwifi utilities produced partially-broken results because I failed to do this (binaries were linked against symbols that didn't exist in the metrix-installed libraries). Here are the steps I went through to create and use the build environment.

The host for this work was a Debian/unstable system.

  • ==== Unpacking the Image ==== First, create a directory in which to work, e.g. /src/mississippi/ and download the starting image there:
      $ mkdir /src/mississippi
      $ cd /src/mississippi
      $ wget http://cornerstone.personaltelco.net/~brj/metrix-missnet.img
    The downloaded file is 64,028,672 bytes (125,056 512-byte sectors). This represents the /dev/hda flash device on the metrix. It includes the boot sector and partition table, and the root partition /dev/hda1. Grub is used as the boot loader (a rather old feature-missing version, which it would be nice to update, to, for example, be able to control the "next boot"). Before we can mount the first partition, we need to dissect the image a bit. We set up a loop block device associated with the image.
      $ losetup /dev/loop0 metrix-missnet.img
    Now, run fdisk on the loop device to figure out where the first partition begins. Use the -u option to fdisk in order to get sector units.
      $ fdisk -u /dev/loop0
    
      Command (m for help): p
    
      Disk /dev/loop0: 64 MB, 64028672 bytes
      4 heads, 32 sectors/track, 977 cylinders, total 125056 sectors
      Units = sectors of 1 * 512 = 512 bytes
    
            Device Boot      Start         End      Blocks   Id  System
      /dev/loop0p1              32      125055       62512   83  Linux
    
      Command (m for help): q
    Take particular note of the starting sector of the first partition. We'll need that in just a bit. Now disassociate /dev/loop0 from the image file.
      $ losetup -d /dev/loop0
    Now you have a choice. You can either make a copy of the first partition, which you can mount, or you can create a new loop block device offset to the start of first partition and modify it "in place". I chose the former in order to preserve the original, but for reference, you can create the offset loop device as follows. Note that 16384 bytes is the starting sector (32) multiplied by the sector size (512 bytes).
      $ losetup -o 16384 /dev/loop0 metrix-missnet.img
      $ mkdir metrix-missnet
      $ su
      # mount /dev/loop0 metrix-missnet
    Now, what I did instead:
      $ dd if=metrix-missnet.img of=metrix-missnet-part1.img skip=32
      125024+0 records in
      125024+0 records out
      64012288 bytes (64 MB) copied, 7.40427 seconds, 8.6 MB/s
      $ su
      # mount -o loop metrix-missnet-part1.img metrix-missnet
    ==== Creating the Build Environment ==== Now you have access to the image's filesystem through the metrix-missnet mount point. However, the little 64Meg filesystem is too small for the build tool chain, so we are going to create a working copy next door, that we'll chroot into and install the software there. Because we're working with root owned files, we need to stay root here for a while.
      # rsync -v -a -H metrix-missnet/ metrix-missnet-build-env/
      # chroot metrix-missnet-build-env
    Now a little explanatory digression is necessary. The metrix-native environment runs with the filesystem mounted read-only. It copes with changing files by symlinking them to a /rw tmpfs filesystem. That /rw filesystem gets populated during boot from static versions in a /ro tree. You are going to be needing to install software from Debian archives, but your DNS resolution won't work until you modify the build environment's /etc/resolv.conf to something that works for you locally. However, /etc/resolv.conf is a symlink pointing at /rw/etc/resolv.conf. At this stage, that file doesn't exist, since /rw is just a mount point in the original. There are lots of potential solutions to this problem. I took the most direct one, effectively replicating what the metrix itself does:
      # rsync -v -a -H /ro/ /rw/
      # vi /etc/resolv.conf (as appropriate)
    Then ping some well-known host to confirm that your network is functioning in the chroot.
      # ping www.google.com
      PING www.l.google.com (66.102.7.147): 56 data bytes
      64 bytes from 66.102.7.147: icmp_seq=0 ttl=238 time=56.0 ms
      64 bytes from 66.102.7.147: icmp_seq=1 ttl=238 time=56.4 ms
      64 bytes from 66.102.7.147: icmp_seq=2 ttl=238 time=60.8 ms
      64 bytes from 66.102.7.147: icmp_seq=3 ttl=238 time=59.7 ms
    
      --- www.l.google.com ping statistics ---
      4 packets transmitted, 4 packets received, 0% packet loss
      round-trip min/avg/max = 56.0/58.2/60.8 ms
    ==== Install toolchain ====
      # apt-get update
      Hit http://debian.oregonstate.edu woody/main Packages
      Hit http://debian.oregonstate.edu woody/main Release
      Get:1 http://security.debian.org woody/updates/main Packages [245kB]
      Get:2 http://security.debian.org woody/updates/main Release [113B]
      Hit http://www.backports.org stable/kernel-2.6 Packages
      Hit http://www.backports.org stable/kernel-2.6 Release
      Fetched 245kB in 5s (48.4kB/s)
      Reading Package Lists...
      Building Dependency Tree...
      # apt-get upgrade
      Reading Package Lists...
      Building Dependency Tree...
      7 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
      Need to get 1259kB of archives. After unpacking 61.4kB will be used.
      Do you want to continue? [Y/n]  
    Say yes. Now, install the toolchain:
      # apt-get install make gcc libncurses5-dev
      Reading Package Lists...
      Building Dependency Tree...
      The following extra packages will be installed:
        binutils cpp cpp-2.95 gcc-2.95 libc6-dev 
      The following NEW packages will be installed:
        binutils cpp cpp-2.95 gcc gcc-2.95 libc6-dev libncurses5-dev make 
      0 packages upgraded, 8 newly installed, 0 to remove and 0  not upgraded.
      Need to get 6576kB of archives. After unpacking 24.8MB will be used.
      Do you want to continue? [Y/n] 
    Say yes. You may get a warning while configuring binutils about a possible kernel link failure. It applies to older kernels, and we'll be using something newish, so it shouldn't affect us. ==== Building a Kernel ==== Now, download a kernel tarball. I'll use 2.6.14.2 here. Since I forgot to install bzip2 above, I'll just download the gzip'd tarball and unpack it:
      # cd /usr/src
      # wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.14.2.tar.gz
      # tar xzvf linux-2.6.14.2.tar.gz
    Start with the kernel config in /boot:
      # cd linux-2.6.14.2
      # cp /boot/config-2.6.12.3-metrix .config
      # make oldconfig
    I selected defaults for everything, except:
    • Dell Systems Management Base Driver (DCDBAS) [M/n/y/?] (NEW) n
    • Generic IEEE 802.11 Networking Stack (IEEE80211) [N/m/y/?] (NEW) y
    • Inotify file change notification support (INOTIFY) [Y/n/?] (NEW) n
    Note that this configuration is set up for a Metrix Mark II, with a Soekris 4826 board and a Geode GX CPU. In order to work with the Metrix Mark I, which uses a Soekris 4526 and an AMD 486 clone, you need to modify the configuration, e.g. using "make menuconfig". Trying to boot the 4526 with a Geode compiled kernel will choke as follows:
      CPU: AMD 486 DX/4-WB stepping 04
      Kernel panic - not syncing: Kernel compiled for Pentium+, requires TSC feature!
    Next, compile the kernel:
      # make
      # make install 
      # make modules_install 
    The modules are installed in /lib/modules/2.6.14.2-metrix. Edit /boot/grub/menu.lst, adding a stanza for the new kernel. For example:
      title           Debian GNU/Linux, kernel 2.6.14.2-metrix
      root            (hd0,0)
      kernel          /boot/vmlinuz-2.6.14.2-metrix root=/dev/hda1 ro console=ttyS0,19200n8 panic=5
      savedefault
    Since we have no consoles on the metrixes in the field, and no non-volatile storage is available to record any oops messages, there isn't much purpose served by having a panic just halt the device, so I've added the panic clause to the boot options in hopes that will recover the device in the case of a fault. ==== Building the Madwifi-ng modules and utilities ==== [more to come] ==== Installing the new software ==== ==== Creating a new image ====


[CategoryDocumentation]

MississippiMetrixConfiguration (last edited 2009-01-31 02:10:15 by RussellSenior)