Me:	About Me
Things I Have Done:	Linux Toys, Junk
Pictures and Stuff:	Planet Horms, Photo Gallery
Sites I Maintain:	Verge, Slarken, Ultra Monkey, Super Sparrow

Recent News

• The build needs to be done on an x86 32bit system. It should be possible to do this non-natively using a cross-compiler or a chroot. I didn't feel like enhancing the difficulty of the task at hand, so I just found a system on which I could run a native compile.

  A mailing list post breifly discussing this topic can be found here

• Ensure that the following packages are installed: build-essential, bison, flex, guilt, texinfo, git, bcc, gettext, rsync, iasl, locales, python, gawk and subversion.

• Ensure that the en_US.UTF-8 locale is present on the system. This can be done this before the locales package is installed by running the following. Note that debconf-set-selections needs to run as root, which can be achieved by prefixing its invocation with sudo, assuming sudo is set up.

  # echo "locales locales/locales_to_be_generated string en_US.UTF-8 UTF-8" | \
  	debconf-set-selections
  

  Or this can be done by after the locales package is installed by running the following as root:

  # dpkg-reconfigure locales
  

• Check-out the initial source code.

  # git clone http://xenbits.xen.org/git-http/xenclient/build.git
  # cd build
  

• Unset some environment variables.

  # unset MAKE
  # unset CFLAGS
  

  The build system bailed-out early on and asked me to unset CFLAGS. I bailed-out of my MAKE="make -j3" build when the load went over 3000!

• Copy the sample configuration, disable partd and select the 2.6.18 kernel. My preference was for the 2.6.27.5 kernel, but this failed to build.

  # cp configs/xenclient_config ./.config
  # echo "# BR2_PACKAGE_PARTED is not set" >> .config
  # echo "BR2_XENCLIENT_KERNEL_2_6_18=y" >> .config
  # echo "# BR2_XENCLIENT_KERNEL_2_6_27 is not set" >> .config
  

• Activate the configuration.

  # make oldconfig
  

• Build.

  # make
  

  This may take quite a while. It will download things, though it is nice enough to cache most of the downloads in dl/. In the end it consumed about 5Gb of disk space on my system. I did have good luck restarting the build. Hopefully with this advice there won't be a need to restart.

• Ponder the installation instructions in the HOWTO found in the top-level directory.

Fri, 22 May 2009 13:46:03 +1000| Permalink

Xen 3.4.0 has been released and includes two improvements to PCI pass-through that I was involved in:

• Allow any unused PCI slot to be used for PCI pass-through, including hot-plug.

  Previously only slots 6 & 7 could be used, limiting users to two pass-through devices per domU. The new limit is around 28, as there are 32 possible slots on a PCI bus, and at typically 4 are used by a domU for emulated devices. Fewer devices will be available for pass-through if extra ioemu devices are attached to the domU.

• Allow the user to specify slot used for pass-through of devices attached to domU at boot time. This mirrors the ability to select the slot when a device is hot-plugged.

Unfortunately there have also been a number of bugs in pass-through. Many of these have been fixed. But and as of the release a known problem is that domains can't be started if they have previously had PCI devices hot-plugged. At this time I recommend using xm_pci_list_v3.patch and xm_pci_attach_v2.patch which have been provided by Masaki Kanno in his post [PATCH] Fix xm pci-attach/detach for inactivemanaged as a fix for this problem.

Update: Kanno-san's changes have been combined into a single patch and applied to xen-unstable as changset: 19618:780041c4a96d "xend: Fix xm pci commands for inactive managed domains".

Tue, 19 May 2009 12:03:50 +1000| Permalink

Update: I now have the 82576 working and have posted a patch which the mailing list archive mangled. I haven't had any more luck with the 82566DM-2 and have shelved that project for now.

Fri, 08 May 2009 11:10:54 +1000| Permalink

Reading Matt Palmer's recent post SheevaPlug-based serial console concentrators, I decided to write up how I achieved this goal.

Rather than users logging into the console server and then executing a command to access the relevant serial port, I wanted access to be I wanted access to the consoles by telneting to a designated port, one port per serial console that is available.

To achieve this I wrote a small script, screenshell and put it in /usr/local/bin. It is pretty simple, it creates a new screen session for the requested TTY if one doesn't already exist, else it connects to the existing session. I couldn't find an argument to screen that would do this in one hit, so the script looks at what screen sessions are running and acts accordingly - some room for improvement here (see update).

In order to accept connections via telnet, I just added the following lines to /etc/inetd.conf:

8000		stream	tcp	nowait	scs.scs	/usr/sbin/tcpd /usr/sbin/in.telnetd -h -L/usr/local/bin/screenshell-ttyS0
8001		stream	tcp	nowait	scs.scs	/usr/sbin/tcpd /usr/sbin/in.telnetd -h -L/usr/local/bin/screenshell-ttyS1

This basically says, listen for connections on port 8000, if you get a connection, invoke /usr/sbin/in.telnetd and use /usr/local/bin/screenshell-ttyS0 to handle their session. Similarly for port 80001. scs.scs denotes that /usr/sbin/in.telnetd should be invoked as user scs, group scs. The scs (Serial Console Server) user and group were created for this sole purpose, though that is really just a matter of taste.

I couldn't work out how to determine which port the user was connecting to from within screenshell when it is invoked in this way, nor could I work out how to pass extra arguments to screenshell. So instead I just symlinked screenshell to screenshell-ttyS0 and screenshell-ttyS1, which allowed the command name to be used to determine which TTY was being used. Again, room for improvement.

For the problem at hand telnet was sufficient so I didn't investigate how well ssh would work with the solution that I cam up with. For the task at hand, the solution above seems to work quite well.

Download: screenshell
Home: ~horms/junk/

Update: 4th May 2009
Kfish pointed out that screen -xRR -S NAME will attach to an existing session or start a new one as necessary. I have slimmed down the script accordingly.

Fri, 01 May 2009 11:10:34 +1000| Permalink

# /etc/init.d/xend restart
.........

The log, at 61 lines, was much more verbose, though equally useless unless you are prepared to delve into the code. It can be found here. It turns out the interesting portion for debugging the problem is:

  File "usr/lib/python2.5/site-packages/xen/xend/XendNode.py", line 240, in _init_SRs
      saved_srs = self.state_store.load_state('sr')

Diving into the code, I put a few debugging statements into XendStateStore.py, which seemed to indicate that the breakage was occurring around the time that /var/lib/xend/state/sr.xml was read. On inspection I found this file to be empty, while similar files in the same directory were not.

A solution: # rm /var/lib/xend/state/sr.xml

A Lesson Learnt: If you follow xen-unstable, from time to time things will break in bizarre ways.

A Mystery: How did the file end up empty in the first place?

Thu, 30 Apr 2009 11:56:25 +1000| Permalink