Glad it's not my bug.
3:14am, spring daylight savings time day. The church bells across the street have been ringing for 14 minutes.
3:14am, spring daylight savings time day. The church bells across the street have been ringing for 14 minutes.
After my dismal failure at Pohmelfs, I shopped for alternative distributed files systems. I can’t tell if CODA is abandoned or not, but I’ll give it a try.
aptitude update ; aptitude install coda-server, scary text about
unsigned packages follows, but it is OK.vice-setupaptitude install coda-client… ends with
00:35:02 Venus starting… 00:35:02 /coda now mountedclog until I realize that the
example I’m working from only has an account of admin because that
is what they gave vice-setup. Use the account I gave with the
password “changeme” and I’m in.cpasswd, change that password.au -h MYHOST nu, coda is a
pretty hostile system. It echoes my new password in the clear even
though it knows how not to, then fails
with AuthNameToId() --> AUTH_FAILEDau from a
client, and now I can set my password.Coda is badly documented, user hostile, and not robust.
I do not trust it.
I’ve enjoyed reading zbr’s blog postings about POHMELFS and the Elliptics network for years. With POHMELFS in the staging directories of Linux 2.6.33 and me needing to share some files across several machines, it is time to try it out.
--with-kdir-path=<mylinuxsourc>/drivers/staging/pohmelfs/ is
the right answer.dmesg reports there is a null pointer reference
in the kernel.I will go shopping for other distributed file systems.
Let’s just say you have taken your old PPC G4 mac Mini with the dead hard disk and fitted it with an 8GB compact flash card in a 2.5” IDE adapter. Installing Debian Lenny on there is easy, but you end up with an ext3 journaled filesystem that may be concentrating wear on the journal area.
NILFS2 is a spiffy new filesystem that probably doesn’t concentrate wear and is attractive when writing is slower than reading. Sounds great, but yaboot doesn’t know how to find the kernel and initrd.img on it, so you need to make an ext2 /boot partion and then tell yaboot to look there.
The secret is in the naming of the files in yaboot.conf. Here is mine:
boot=/dev/hda2
device=hd:
ofboot=hd:2
partition=4
root=/dev/hda4
timeout=50
install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot
enablecdboot
image=hd:3,/vmlinux
partition 3
label=Linux
read-only
initrd=hd:3,/initrd.img
image=hd:3,/vmlinux.old
partition 3
label=old
read-only
initrd=hd:3,/initrd.img.old
As you can see, hda3 is my /boot, hda4 is my root.
Astute readers will also notice that you have to either save a partition or migrate from another drive to pull this off since you need to build yourself a shiny new 2.6.31 kernel with NILFS2 compiled in.
Note: My G4 Mini has developed an odd hanging problem when using X programs with the root on NILFS2. I’ll go back to ext2, 2.6.26 for now then try ext2 2.6.31 and see where the trouble lies.
I just finished finding a four day bug. It sounds simple in retrospect, but oh the wrong paths I have trod and wild codes I have explored.
If, like me, you run Debian on tiny routers, like WRTSL54GS or other
Broadcom units from Linksys, you probably use an OpenWRT kernel and a
Debian root. Somewhere between 2.6.25 and 2.6.28 the OpenWRT people
chopped the FPU emulator out of their Linux tree. Sadly for Debian
people this causes any program you try to run, like init, to hang in
an infinite loop.
The solution is now enshrined over at https://dev.openwrt.org/ticket/5774 where it talks about the invisible kernel config option: MIPS_FPU_EMU.
Addendum: Oh yeah, you are going to want to go into
drivers/usb/host/ehci-ssb.c and pull the static off
of ssb_ehci_attach and ssb_ehci_detach if you want USB 2.0 built
into the kernel.
If you are going to run virtual machines in LXC containers it is nice to let each one have a console on your physical box. You can do this thusly…
Note: we are going under the knickers of lxc. It may not appreciate having its config files changed, but I didn’t find an exposed command to accomplish this.
Linux Containers are a mechanism by which you can run multiple virtual instances of linux inside a single machine.
Following are my notes for using Linux containers with Debian Lenny. Read along on that IBM article I just linked. It is good stuff.
wget http://ftp.us.debian.org/debian/pool/main/l/lxc/lxc_0.6.3-1_i386.debdpkg -i lxc_0.6.3-1_i386.deb (note: As
squeeze diverges, later versions of this may have linkage problems
that won’t let them install on lenny)/usr/share/doc/lxc/README.Debian file. See some neat
stuff.lxc-checkconfig to verify the kernel has what it takes. Notice
the cgroup memory controller is disabled, but don’t care.cgroup filesystem has to get mounted somewhere.
It doesn’t matter much where. I chose to put mine in /cgroup to
avoid any mount order dependencies. Some people will have
ontological problems with this. Imkdir /cgroup and add this to my
/etc/fstab file: cgroup /cgroup cgroup defaults 0 0I think I have all the pieces now. Pop over to LXC: Linux container
tools and
slide down to “Configure networking” and lets get going. I am going
to have to change my ethernet to a bridge. Here is the before and
after of my /etc/network/interfaces file
# The primary network interface
allow-hotplug eth1
iface eth1 inet static
address 172.18.36.4
netmask 255.255.255.0
gateway 172.18.36.1
and the after
# The primary network interface
auto br0
iface br0 inet static
bridge_ports eth1
bridge_maxwait 0
address 172.18.36.4
netmask 255.255.255.0
gateway 172.18.36.1auto eth1
iface eth1 inet manual
Use ifdown -a and ifup -a to make the change, from the console.
I failed here because I didn’t have bridge-utils installed. Make
sure you do that first. If you are using dhcp just reboot and save
yourself the heartache when your old dhcp trashes your address.
Try using lxc-debian to make a container. You can find this in
/usr/share/doc/lxc/examples. Pull it out and uncompress it, then
run it. You will need to install debootstrap first. It appears to be
a trainwreck. I had to patch it a little to make it run. The patch
is attached below.
Note: lxc-debian doesn’t allow you to specify your package source, it is hard coded to ftp.debian.org. If you have a local cache, or a faster source you will want to edit a line in there. debootstrap handles its own cache, so it only sucks once.
When you get the “Configuring Locales” dialog, take the time to scroll down to en_US.UTF-8 and turn it on, then select it on the next page to prevent a cloud of error lines. I suppose other ones work, but not generating and selecting makes noise.
The last line will tell you how to start your container, mine says:
You can run your container with the 'lxc-start -n test1'
You now have a container with a bunch of bad config files and no editor. Fortunately you can edit the afflicted files from the main linux.
Go look at your ROOT/etc/network/interfaces. Mine had a bad netmask.
Check your ROOT/etc/apt/sources.list, it is probably missing security and volatile.
Go ahead and start your container now and start working form the inside.
I am going to use aptitude, so “apt-get update ; apt-get install aptitude”
Let’s get the “normal” packages installed. “aptitude update” and
then aptitude install "?priority(standard)" and
aptitude install "?priority(important)"
There are still issues starting up as a daemon and some collisions with the system console, but I’ll address those in a later post.
This should be enough to get started.
You should read the article Setting up a server for PXE network booting
It is a bit dated, but swapping all the “etch” references for “lenny” works. I don’t get the “boot” menu when I booted my test system, so when the prompt says “boot:” just type in something like “lenny_i386_install”.
I was wondering if I needed to keep as many physical development machines or if I could just use virtual machines on my laptop and main desktop machine. I think I can certainly lose the P4 3GHz. It offers no real advantage over the Atom 330 1.6GHz.
I don’t think I’ll rely on the VirtualBox machine for Linux kernel work, but perhaps for mortal scale projects it will serve.
(pardon my confusing terminology: Compile time vs. Concurrent Jobs would have been a better graph title. i.e. make -j3 )
The blue line is different. That is a different version of gcc so you
can’t directly compare the hardware with the others, but for developer
experience you can make the comparison.
I guess the bottom line is that I still lust for a Core i7 machine but will hold off for the lower power versions coming in the fall.
I used to test web pages for IE compatibility by walking around the office, finding a person with IE and asking them to pull up the page. I can’t do that anymore, and it doesn’t seem likely to work well if I go to the local coffee house and try it on a stranger, so I have found a new solution.
Microsoft makes VPC (virtual PC) system images available for minimal OS + IE installs for IE6, IE7, and IE8, some on both Vista and XP. Download details: IE App Compat VHD (These are timebombed and die after a few months, and look in the ReadMe.txt file for passwords.)
These can be run in VirtualBox on Windows, Mac OS X, Linux and Solaris hosts. The initial boot is a little ugly as Windows gropes for drivers, but once you get the VirtualBox guest additions installed it is smooth.
On my 12+ month old iMac booting an XP machine with IE takes about 22 seconds (10 seconds in BIOS, 10 booting XP, 2 logging in), restarting one from saved state takes about 6 seconds. Once running they are snappy. They don’t feel any different from native applications.
You can find excellent instructions for running these under VirtualBox at zytzagoo’s den. These are written for linux users. I used linux for the unrar step but used my Mac for the VirtualBox machine.
If you want to test with more than one version of IE you will discover that Microsoft used the same UUID for all of the disk images (challenging the meaning of unique) and that VirtualBox is offended by that. You can read the also good instructions at Shape Shed and look at the Fixing Microsoft’s Duplicate Identifiers section for details on converting the image to a raw image and back to a VDI to get a new UUID.