|
|
So I finally found some time to work with the T-1000 again, I wanted to run Linux on it - but not as a full install, I only wanted to use the Ubuntu Installer (network install) as a conveniently packaged boot loader and once it had loaded all the runtime components from the package repository I would exit into the shell and see what Linux life would be like on a T-1000 (differences in dmesg, /proc, etc).
There are severeal steps involved in this procedure:
- Setting up the OpenBoot environment to not boot from disk (Solaris) automatically
- Setting up the TFTP Server
- Booting...
The first step is easy: you boot up the system (regular Solaris boot), connect to the system console, log in and shut the system down ("init 0"). Once Solaris has rendered control back to OpenBoot, disable auto-booting:
setenv auto-boot? false
Now reset the system and instead of booting Solaris the OpenBoot prompt will greet you on the console. Once the TFTP server is set up boot the T-1000 via network:
boot net
Now the Net-0 interface will look for an IP-Adress via a RARP-Request (which your TFTP Server should provide either via the rarpd-daemon or by the rarp-kernel module) and pull the boot image via TFTP. Unfortunately, this doesn't quite work as expected (as I've seen it with Intel PXE clients): the T-1000 does query for the image on the broadcast address, but after the first packet adresses the server by its IP address as it saw it in the TFTP first response packet. At first I though this would be a problem with the tftpd package in Debian, so I replaced it with the tftpd-hpa package, but that didn't change anything. So I decided to use a little trickery to make it work: I used iptables on my TFTP-Server to rewrite incoming packets destined for 255.255.255.255:69 to the TFTP server's IP address and now the T-1000 fetched the image and started booting.
I thought it would all downhill from here...but: the Ubuntu installer image I had obtained promptly crashed (I don't recall where I got this image from, or what kernel version it was based on). A newer image based on 2.6.15-23-sparc did the trick - at least it appeared that way. While the system booted fine and everything seemed dandy there was an issue with networking: the system didn't seem to have a working networking subsystem. Other people have also experienced this and pointed to the network interface driver (tigon3) as not being supported, but I noticed that ARP packets were on the wire - so the network driver must have been somewhat functional. I did however not get this kernel to put any IP packets on the wire - although all the kernel's debug messages suggested that the IP networking subsystem is fully functional. At some point I gave up and hunted for yet another installer image and found one based on 2.6.15-25-sparc dated June 15th; this one did resolve the networking issue and I finally had had a chance to let the installer pull its remaining parts from the package repository and could have went on with my test-linux-life-on-sparc experiment, but I figured it was time to go home.
|
|
Accessible Version
Imprint