Disable X on boot

I usually do this in some violent way, making it hard to run X again when I want to. The Debian manual contains the solution to this (as well as everything in my previous post about lost root passwords):

update-rc.d -f ?dm remove ; update-rc.d ?dm stop 99 1 2 3 4 5 6 .

Where the ? needs to be replaced with any installed display managers. On my system, I only had gdm installed.

Linux password reset with init=/bin/bash

init=/bin/bash is my usual technique for resetting a forgotten linux root password. However, I recently received a strange error message (which I forget) after entering my new password. I say strange because it doesn’t indicate the real problem: the filesystem may still be mounted as read-only, even if the output of the mount command says it’s mounted read-write. Thus, try:

mount -o remount,ro /

Linux on a colorful iMac

My fiance’s parents have an older iMac — one of the colorful CRT ones. We are trying to install Linux on it.
Here are some more details about the particular machine from lowendmac.com. The Debian PowerPC installer page suggests that our iMac is a “new world” PowerPC iMac, and that Debian should install just fine. Now, this particular system runs at 333 MHz and has only 32 MB of RAM, i.e., not much. I crossed my fingers and inserted the installer CD, and powered on the iMac while holding down the ‘c’ key to boot from CD. The ‘yaboot’ prompt greeted me, it loaded the kernel, and then tried to load the initial ram disk. At that point the screen’s background changed from black to white and the system dropped to an Apple firmware prompt (pretty cool actually, that’s never happened to me with a PC). The following error message appeared:

Error: Can’t allocate initial device-tree chunk
This Ubuntu forum post suggests that numerous people have seen this issue, and that it can be resolved by installing the “Alternate” version of Xubuntu 6.06.1. Unfortunately, this didn’t solve my problem. It seems that 32 MB is just not enough RAM for these stock distributions. Here is another thread about somebody else who had the same problem.

I decided to try an older version of Debian, and it worked! I successfully installed Debian Sarge for PPC from the netinst CD.

I had some problems formatting the hard drive during the install. Specifically, formatting worked fine, but the resulting partitions couldn’t be mounted. I believe this to have been a problem with the necessary kernel modules not being available. These modules were unavailable because, on a system with so little RAM (32 MB), the Debian installer doesn’t automatically load all components. I experimented with different combinations of what appeared to be the right installer components (sorry, I didn’t keep more careful records), rebooting several times. In the end I used the ‘partman’ automatic partitioning module to setup the partitions, and it just worked. 🙂

I also had to enable specific installer components to get the ‘bmac’ ethernet driver to work. Once those were enabled, the network configured successfully using DHCP.

The installer booted with a v2.4 kernel. At the end of the install, it wanted to install a v2.6 kernel. I nervously accepted, and the resulting system booted perfectly during the first reboot without the CD. Cool!

I was able to get X working using `aptitude install x-window-system`, accepting all the defaults, and then adding one line to the “Device” section of my XF86Config-4:
BusID “PCI:0:18:0”
I got the hint for that line from this page, and the actual numbers from `cat /proc/pci`.

I installed the xfce window manager, and Mozilla Firefox. Both worked. We’re up and running. 🙂

The system ran out of memory trying to compile scilab from source, but I killed the X server and did the compile from a tty. It worked. 🙂

NAT

echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

The line with “–state” caused iptables to return an error to the tune of “iptables: No chain/target/match by that name”. How useless. I needed to compile some additional kernel modules. If I get motivated, maybe I’ll figure out precisely which modules need to be enabled and post it. Usually I’m so furious by this point that I go on an enabling frenzy, so I can never be sure just which modules did the trick.

Xen networking is tricky

I did a lot of playing around with Xen recently, and getting networking configured to my liking was a chore. Here are two of the problems that I had, and some of what I did about it.

My goal was to “do NAT“, with one domU (call him “router”) acting as the gateway, and a bunch more domUs accessing the Internet via “router”. Simple instructions for an ordinary Linux system. I’ve been playing with VMware ESX Server as well, and ESX only supports ethernet-level virtual networking. For consistency, I decided to continue using Xen’s bridge-based networking (I’ve never had any luck getting NAT configured using the stock Xen NAT scripts anyways). I gave domU router two virtual NICs, one connected to xenbr0 (the default bridge), and another connected to a new bridge I created (call it “isolated”) to connect the other domUs to router.

To connect domU’s first NIC to the outside world, I used the second physical NIC on my server (it has two; I let eth0 be dom0’s connection to the world, and eth1 be router’s connection).

ifconfig eth1 down
ifconfig eth1 hw ether fe:ff:ff:ff:ff:ff
ifconfig eth1 -arp
brctl addif xenbr0 eth1
ifconfig eth1 up

Create the new bridge:

brctl addbr isolated
ifconfig isolated up

I had to recompile the domU kernel to enable the necessary packet mangling, which I did following these instructions for the Perfect Xen 3.1.0 Setup for Debian Etch. Other noteworthy commands are those to use the existing Xen makefiles to configure, make, and install the guest kernels:

make linux-2.6-xenU-config
make linux-2.6-xenU-build
make linux-2.6-xenU-install

After all this, I expected things to work. I tried the obligatory pings, and nothing came back. Nothing, as in, not even a “destination host unreachable”. WTF. I fired up tcpdump in my domUs and started trying to track down the problem. Let’s call the players Guest A, Router, and Remote. The idea was for a ping to go A -> Router -> Remote -> Router -> A. There are four arrows there. It turned out that traffic was getting from A to Router, and Router was mangling the packets correctly, and sending them on to Remote. Remote was replying back to Router, but Router was not sending the packets back to A! I call this problem 3/4 of a network since three of the four necessary network links were working as expected. The problem turned out to be that I still hadn’t enabled sufficient domU kernel options to do NAT correctly. I didn’t keep track of exactly what I changed, but I believe some of the connection tracking options needed to be enabled.

I rebuilt my kernel and tried again. Now, ping works, but TCP and UDP do not. WTMF. This turns out to be a packet header checksum issue with the way Xen’s virtual network devices behave. Basically, no point in computing checksums for virtual network segments since the normal forms of corruption do not apply. A fine optimization, but it makes the TCP and UDP stacks very unhappy. The solution here is to run the command:

ethtool -K eth0 tx off

I believe this disables checksumming. To effect this automatically in Debian, you can manipulate your /etc/network/interfaces file thusly:

iface eth0 inet static
address 192.168.1.123
netmask 255.255.255.0
gateway 192.168.1.1
network 192.168.1.0
broadcast 192.168.1.255
post-up ethtool -K eth0 tx off

The Xen Wiki has an entry about this problem.

It is also helpful to look at the Xen Networking page of the Xen Wiki. I deem the information on that page necessary, but not sufficient to configure networking in Xen to my satisfaction.