Blogospheric Refraction

The life and times of Stuart Longland (VK4MSL)

Yep, after 2 power failures, weeks of anticipation, and much hair pulling on my part (good thing though, I need a haircut anyways), the full set of stages is finally built and uploaded. You can find them on my devspace in the usual place.

These haven’t undergone much in the way of testing… so it would be greatly appreciated if some brave souls could give these a try and report back on how they go. All going well, we should be able to get these pushed out to mirrors by the end of the month. :-)

I’ll also start knocking up some new netboot images shortly. The new images will differ from the old ones, in that you will no longer have to download and extract CoLo into /nfsroot. I’m planning to produce images which can just be untarred directly into /nfsroot, and contain all the necessary files for boot. It’d also be nice to rid ourselves with the past time of mucking with the shell. All going well here, I’ll be re-writing that section of the handbook, and things should become significantly more simpler.

But we’ll see — for now I’m breathing a sigh of relief, but soon I’ll be back into the slog that is end-of-semester exams, so I don’t have long just now. Likely, this will be a summer holiday project. (Yes, for those of you playing along in the Northern Hemisphere…temperatures are warming up down here in Brisbane.)

As always, I’ll keep you posted on further notices, and I’m usually online if people wish to contact me.
Regards,
Stuart Longland

Well, ain’t it lovely… I’m busy fixing a few things up in a local CVS repository…. I hit cvs commit, as you do… then all a sudden the lights go out, my screen goes blank, and I’m left in the dark — totally silent except two computer UPS’s screaming about the loss of power. As for my stage 3 tarball compilation on my Qube2 … up in smoke.

So I get up, and crash around in the dark looking for my torch so I can check the meter box (it hasn’t been unusual for the earth leakage to trip out without reason). No sooner do I get just 3 meters, the lights come back on. Okay, fine, it was late, so I just switched the rest of my computer off (namely the monitor, desklamp and tuner) and headded for bed. Then the power fails again. Lovely.

I found a torch and went looking at the meter box… Hrmm, not our end, and looking around, I see other people looking around in the darkness. Unfortunately in this case, the outage lasts longer than my UPS’s can supply power — so we go offline.

The power was restored at around 1:00AM, but unfortunately this means my compile for the Cobalt stages is now put back a whole couple of days, as the build must now start again. I’ve now pieced my network back together (namely a couple of IRC bots were offline, and my IPv6 tunnel was nonfunctional) and so I’m back online again.

Hopefully there won’t be any further interruptions, and this build can progress right to the end. :-)

Well I’ve fixed it. After a lot of arguments with my Qube2, I finally have a stage 1 tarball for 2005.1, with stage 2 and 3 tarballs on the way.

I’ll be uploading the stage 1 tarball shortly (tomorrow in fact, as QUT has a slightly faster pipe, and it costs me nothing to upload there), and will upload the stage 2 and 3 ones later as they are built.

I’ll also be uploading binpkg’s, for those who wish to just upgrade their existing Cobalts to the latest Gentoo release.

So yeah, Gentoo/MIPS Cobalt 2005.1 comming soon, to a mirror near you. :-)

After some tinkering today, I managed to figure out the wonderous black art that is IPv6. Now I get to discover the Internet that IPv4 user’s don’t see.

How does one get hooked up to IPv6? Well, if your ISP doesn’t support it, then you have to establish an IPv6-in-IPv4 tunnel with an IPv6 broker. Since I’m in Australia, naturally, I set up an account with AARNet, and requested a tunnel through them.

Gentoo have a nice little guide, that steps users through setting up with either 6Bone or Freenet6… however it seems AARNet do things slightly differently.

The way I set things up was as follows…

Connecting a host to IPv6 via AARNet

Before we start, you’ll want to make sure you’ve got IPv6 support in your kernel. If you see a directory called /proc/sys/net/ipv6, then chances are good, you’ve got what it takes. :-)

First, create an account. This is the username and password you’ll use to request the tunnel later. You’ll be emailed a system generated password. You only get one, and there’s no password changing facility (that I can see), so it would be adventageous to keep this email safe.

Next, fill out this form. If you’re just wanting to hook up a single host, then ignore the “Request for /48 prefix”. Otherwise, you’ll need to check that box — in the “Interface Name” field, enter the interface name for your internal LAN interface (e.g. eth1 in my case). You’ll then be asked for your username and password before downloading a setup shell script (linux.sh if you selected Linux).

Now, Place this linux.sh somewhere convenient. I stuffed it into /etc/setup-ipv6. This script is what you’ll use to establish the tunnel. I call it from my /etc/conf.d/local.start (rc.local for those playing along with other distributions), so my tunnel is established at boot.

Right, with that over, it’s now time to install the tools necessary. On Gentoo, simply USE=ipv6 emerge iputils iproute2 freenet6 — Freenet6 use the exact same tools. Other distributions, AARNet provide the tools from their front page. You’ll also want iproute2, and a version of iputils with IPv6 support.
Gentoo users may find it adventageous to set USE=ipv6 in their /etc/make.conf, and update their system so that they can make use of IPv6 support in any applications able to utilise it.

Lastly, we need to configure tspc, the tunnel client. On Gentoo, edit /etc/freenet6/tspc.conf (just hack up the example config). Place in there, the username and password you were given from AARNet, and down the bottom, change the server= line to read broker.aarnet.net.au. You’ll also want to edit the linux.sh file, to make sure the directories mentioned are correct, in particular, TSP_HOME_DIR should point to the directory containing tspc.conf.

And now we’re ready to bring up the tunnel. Run sh linux.sh (or whatever you ended up calling it). You should see something like this…

(23:32) www ~ # /etc/setup-ipv6
--- Start of configuration script. ---
Script:  setup-ipv6
sit1 setup
Setting up link to 202.158.196.131
This host is: 2001:0388:f000:0000:0000:0000:0000:0279/
Adding default route
Router configuration
Kernel setup
net.ipv6.conf.all.forwarding = 1
Adding prefix to eth1
Starting radvd: /usr/sbin/radvd -u radvd -C /etc/freenet6/tsprtadvd.conf
--- End of configuration script. ---
(23:32) www ~ # _

You’re now running IPv6. Go on, get out there… explore. :-) To check you’re really browsing IPv6, try pointing an IRC client at irc.ipv6.freenode.net (Ohh, and don’t forget to pop in to one of the Gentoo channels and say Hi ;-) ), or point your web browser at the KAME website. If you’re running IPv6, their tortise should be dancing (it’s an animated GIF). You can also try pinging various sites such as irc.ipv6.freenode.net or www.kame.net using the ping6 utility.

Sharing the love

So, suppose you asked for a /48 prefix, and you’ve got a bunch of machines sitting behind the router that you want on IPv6 too. Easy fixed. You’ve got a couple of options. One is to set up dhcpv6, or the other, is to simply use radvd. The latter works out of the box, the tunnel script automatically configures radvd for you.

On Gentoo, simply emerge radvd. Then restart your tunnel script. It should start radvd, and within a few seconds, the other machines on your network should receive the route/adressing advertisments, and automatically configure themselves for IPv6.

This is only half of the story though … You then have to enable IP forwarding on your server. (Sound familiar? Should do… same as IPv4).
Simply run echo 1 > /proc/sys/net/ipv6/conf/default/forwarding, and you should see the packets start flowing.

Keeping the nasties out

Now that you’ve got routing set up, it’s time to lay down the law regarding firewall rules. Quite obviously, you don’t want the outside riffraff upsetting your delicate hardware unless it’s got a specific invitation to do so. Make sure you’ve got netfilter6 support in your kernel, and the ip6tables utility. (distributed with iptables)

At the moment, there’s no connection tracking in IPv6, nor is there any network address translation (which is unnecessary on IPv6 anyways). The following is what I use for my firewalling rules, adapt to taste.

# Generated by ip6tables-save v1.3.2 on Sun Sep 11 23:57:08 2005
*mangle
 :P REROUTING ACCEPT [16827:6712869]
:INPUT ACCEPT [1297:98415]
:FORWARD ACCEPT [15530:6614454]
:OUTPUT ACCEPT [1629:131392]
 :P OSTROUTING ACCEPT [17230:6752830]
COMMIT
# Completed on Sun Sep 11 23:57:08 2005
# Generated by ip6tables-save v1.3.2 on Sun Sep 11 23:57:08 2005
*filter
# By default, drop anything comming in or through us.
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Allow all ICMP traffic
-A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT

# Local LAN interfaces (note, since I'm behind an ADSL router, all my interfaces are private, except sit1)
-A INPUT -s ::/0 -d ::/0 -i eth+ -j ACCEPT

# Allow SSH and IRC connections (I'd open more, but I'll need DNS working first)
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 6667 -j ACCEPT

# Forwarding rules...
# Allow internal traffic OUT
-A FORWARD -s ::/0 -d ::/0 -i eth+ -j ACCEPT

# Allow established connections back IN
-A FORWARD -s ::/0 -d ::/0 -i sit1 -o eth+ -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT

# Allow ICMP traffic
-A FORWARD -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT

# Log anything else
-A FORWARD -s ::/0 -d ::/0 -j LOG --log-prefix "FORWARD IPv6: "
COMMIT
# Completed on Sun Sep 11 23:57:08 2005

It’s a crude firewall, but it works. :-)
The above guide, is far from being perfect, but hopefully my notes above will assist others in migrating to IPv6.

I’m really beginning to dispise glibc, if I wasn’t doing so already.

For those trying to update their boxes from an existing 2005.0 installation, you should be fine now. glibc-2.3.5 was recently bumped to stable, as has binutils-2.16.1.

However, for whatever reason, catalyst doesn’t like me, or glibc. Thus stages are still in hiatus at the moment while I sort the issues out.

Hi All,

Those who are trying to update their boxes, may have struck problems building the latest versions of glibc. It appears, a bug in the binutils package, is causing the following error message to be spat out, and thus causes portage to bomb out:

/var/tmp/portage/glibc-2.3.4.20050125-r1/temp/ccyZTFe5.s: Assembler messages:
/var/tmp/portage/glibc-2.3.4.20050125-r1/temp/ccyZTFe5.s:131: Error: operation combines symbols in different segments

The build usually falls apart from there. This problem affects both 2.3.4 and 2.3.5. Currently, progress on building 2005.1 stages is halted due to this issue.

At the moment, I’m trialling binutils-2.16.1 (as opposed to 2.x.9x.x.x series, which have known issues), and there are plans to potentially mark it stable on mips. glibc-2.3.5 is a definate candidate for a bump to stable.

So, for those who have hit this problem… try upgrading using the following commands:

# ACCEPT_KEYWORDS="~mips" emerge =binutils-2.16.1
# source /etc/profile
# ACCEPT_KEYWORDS="~mips" emerge =glibc-2.3.5

If you’re paranoid, do the following, first, before attempting an upgrade:

# quickpkg /var/db/pkg/sys-libs/glibc* /var/db/pkg/sys-devel/binutils*

then store the resulting packages somewhere handy, as you’ll need them if you have to recover your system.

We hope to have the situation rectified in the very near future.

Regards,
Stuart Longland.

Hi All,

For those wondering where the 2005.1 Cobalt stages are, read on.

I have just started updating my Qube’s portage tree. Once that is done, I’ll start making a seed stage (a crude stage 3 image) before the build commences in earnest.

As with last time, I’ll upload the binary packages during the stage3 build phase as they are compiled, these will go into my devspace.

Please note, the changes to CoLo with respect to menus. This release will have the newer CoLo loader, and the syntax has changed slightly. See my previous post on the topic for details… I’ll be updating the documentation as soon as I have arcload nutted out.

I’ll keep you posted. :-)

Hi All,

I will shortly (i.e. probably this weekend) will move CoLo 1.16 into
stable (mips, currently in ~mips), and eventually remove CoLo 1.13 from
the tree.

In the newer release, the syntax for your CoLo scripts does change
slightly. In particular, the “menu” command (covered in the handbook)
has been changed to the “select” command. It differs, in that rather
than spitting out a text label, it spits out a numerical ID that you use
with the goto command. You’ll therefore need to update your scripts.

Below is an example of the old ‘menu’ command and the new ‘select’ command.

The old ‘menu’ command:

#:CoLo:#

lcd "Mounting hda1"
mount hda1
menu "Which Kernel?" 50 Working working New new
lcd "Loading Linux" {menu-option}
load /vmlinux.gz.{menu-option}
lcd "Booting..."
execute root=/dev/hda5 ro console=ttyS0,115200
boot

The equivalent script, using ‘select’:

#:CoLo:#

lcd "Mounting hda1"
mount hda1
select "Which Kernel?" 50 Working New

goto {menu-option}
var image-name vmlinux.gz.working
goto 3f
@var image-name vmlinux.gz.working
goto 2f
@var image-name vmlinux.gz.new

@lcd "Loading Linux" {image-name}
load /{image-name}
lcd "Booting..."
execute root=/dev/hda5 ro console=ttyS0,115200
boot

It is advised that you have a look at the documentation that’s
distributed with CoLo. I’ll advise you all once the update is complete.

Regards,
Stuart Longland

Hi All,
Been working on PreLinux lately… been learning lots about how to, and how not to, netboot a workstation… and so far, I’ve now got something that does something useful.

It’s now in Atomic Linux CVS (as I intend to use it for their install/live CDs). If you want to check my work out…

$ cvs -d:pserver:anonymous@cvs.atomicl.berlios.de:/cvsroot/atomicl login $ cvs -z3 -d:pserver:anonymous@cvs.atomicl.berlios.de:/cvsroot/atomicl co prelinux

It’s pretty simple… Adjust Makefile to taste, if you like, customise whatever files you like in root/ (e.g. you might like to replace the startup banner in root/etc/prelinux.d/banner), then run make. You’ll come out at the end with a file called prelinux which is your binary. You’ll need crossdev if you haven’t got an appropriate cross-compiler, and it uses the ebuild utility to fetch, unpack and patch a BusyBox tree.

Booting it, without parameters, drops you to a shell w/ init. This will be particularly of use with later netboot images for Gentoo/MIPS, as it has all the necessary components. Specifying noinit on the command line instead exec’s ash, allowing you to exec init yourself — this mode is mainly for working out exactly what commands are necessary in the script for the third mode. Specifying setup=http://some/script/file.sh tells PreLinux to download the mentioned script and execute it.

It is this third mode that I’m still trying to perfect. So far, an image made from a 2005.0 stage 3 tarball, boots fine. Ubuntu sorta boots, there’s some issues I still need to sort out… at the moment, I’m trying to see if I can netboot Knoppix via this method, as its bootup config is much simpler. (Ubuntu is straight plain weird, still trying to get my head around it) and I might look at what Gentoo LiveCDs are available too… if I can find one with X and some sort of desktop (Gnome, KDE, FluxBox, XFCE… I’m not picky) I’ll give that a try too.

The cross-compilation (for use with Gentoo/MIPS) has still not been tested yet, but I see no reason why it wouldn’t work. As well as testing that feature, I also have to work on handling dynamic libraries. For the moment, BusyBox is linked statically, as locating the necessary runtime libs seems to be a real issue. I could just do it the dirty way and assume they’re in /usr/${CHOST}/lib, but I’d rather not, and besides, this hasn’t worked all that well when I last tried it.

In short, there’s still plenty of hacking to do with this little utility, but I hope to have something useful shortly. Stay Tuned. :-)

Well, I just finished my final end-semester exam for Semester 1, 2005… 6 exams in total (two maths, two electrical engineering, an IT software engineering exam, and a physics exam).

It’s a great thing to see the back of them now… as I can at last get to work on things that have been demanding my attention for some time now.

I’ve started work on a netboot-building system called PreLinux. It’s primarily designed to allow netbooting of diskless/semi-diskless workstations and allow distributions such as Gentoo, Fedora Core, Ubuntu and others run without needing to install them first.

The concept is this:

  • Inside an initramfs image, there’s a version of BusyBox and some basic tools, linked against µClibc, along with just enough driver modules to get the ethernet card and/or storage devices talking.
  • Once a means of downloading the root FS image is established, the system then attempts to connect to the network, and prepares the disk, formatting it completely as swap-space. As initramfs is paged to disk when not in use, it should be possible to run completely out of swap/RAM.
  • If a modules= kernel option is specified, it downloads additional modules to be extracted into RAM, and does further hardware probing.
  • The scripts then look for a root= parameter on the kernel command line. This is a URL to where to grab the image… e.g. http://foo/bar.tbz2, nfs://server/foo.tbz2 or cdrom:/blah.tbz2. This is extracted onto /.
  • The system then execs /setup.sh (from the downloaded tarball for /) which takes care of downloading any SquashFS/cloop images for /usr /opt, etc… and setting up any system-specific configuration settings for the booting machine.
  • Last step… /sbin/init is exec-ed, and Linux boots up like normal

This prodominantly for the Asperger’s Syndrome Support Network, as a means for netbooting their workstations for the Adult Computer Club… however, I’m also aiming to use this for Atomic Linux LiveCD, and for Gentoo/Cobalt-MIPS netboot images. Already, the system is more than capable of calling crossdev to make a cross-compiler suitable, cross-compiling BusyBox statically and cross-compiling a kernel complete with the initramfs — thus making it capable of providing netboot images good enough for bootstrapping Gentoo Linux. I have a prototype script that does some of the other idea too… it’s now just a case of putting it all together.

In short, watch this space. :-)