csant/log

Is graffiti art or vandalism?
That word has a lot of negative connotations and it alienates people, so no, I don't like to use the word 'art' at all.

I am a security guard at Heathrow. If you don't like it, don't fly. This is happening for a reason and you're quick to forget it. If we were not doing this and a bomb did get on a plane, you would be quick to complain that nothing was being done about it. Get real, there is more to life than music.
Laura, Middlesex, England

To Laura from Middlesex, music is some peoples lives.

I have been running Plan 9 on one of my machines for quite a while now. My first installation had been a clean, default fossil installation. Before starting to choose some extra features, it is best to get to know how the system actually works.

But then I decided to explore more, and discover the joys of venti. So I nuked my previous installation, formatted the partition, and made a default fossil+venti installation. And here my trouble started.

Venti

At reboot I started getting lots of error messages:

ventiSend vtWrite block 0xa failed: not connected to venti server
archWalk 0xa failed; ptr is in 0x7 offset 0
archWalk 0x7 failed; ptr is in 0x5 offset 0
archWalk 0xae71 failed; ptr is in 0xae70 offset 0
archWalk 0xae70 failed; ptr is in 0xae6f offset 0
archiveBlock 0xae6f: not connected to Venti server

Now what? I had accurately followed the installation instructions on the wiki and naively had been hoping it would work. Half a day of playing around with various solutions, and I realized that there was only one thing missing: telling the fossil file system where venti actually was - just one line was missing in the plan9.ini file.

When rebooting after installation, start 9fat: (yes, the colon is important) and edit /n/9fat/plan9.ini, adding one line:

venti=/dev/sdC1/arenas

Make sure this points to where you configured the arenas to be - and then reboot.

Network

That is the first step - and then I fell flat on the second one. I had a system now, with fossil+venti, so I quickly reconfigured my network settings - naively expecting them to work. Why shouldn't they, after all - that exact configuration was nicely working on my fossil system.

Well, at reboot I was now greated with a message:

ndb/dns: cannot read my ip address

and any networking that would require a name resolution was not working - so I wasn't even able to mount /n/sources. It took me quite a while to make sure that everything was configured as in the last known-to-work system. To no avail. Digging through the mailing list archives brought up other similar experiences - but no solution.

Some investigations later, here is what seems to happen: the kernel sets up a loopback device for venti to listen on. When termrc starts, the device is busy, and the machine fails to query the DHCP server for it's IP address, and anything else from there goes down the drain. The solution is simple: do not check if /net/ipifc/0/ctl exists before starting ip/ipconfig and ndb/dns - modify /rc/bin/termrc to simply run:

ip/ipconfig >/dev/null >[2=1]
ndb/dns -rf $NDBFILE

Voilà, a fossil+venti system - with a network!

Following packages have not been found on the medium:
operaopera

# yast2 -i <operapackage>