Older blog entries for mjd (starting at number 1)

Wed Aug 16 01:29:41 EST 2000 1400-1800, 2050-0240:

A slow day today.

  • The retailer we rang didn't come through with the router they'd promised, so I found another retailer and went to them instead. Because it's not an in-stock item, I paid the money at the retailer, but had to go to the wholesaler to pick it up.
  • Read the router manual and played with it for a bit. We couldn't get the serial interface to work properly (it sends but won't receive) but we got the telnet over ethernet method working in short order.
  • In the process of testing filtering rules, we managed to cause the ethernet interface of the router to stop listening.
  • After a lot of stuffing around with different cables and ports and PCs, we have to conclude that the serial port of the router is faulty, so it's an expensive paperweight. I'll take it back and get it replaced tomorrow. Good thing we did this before the cable modem arrives.
  • Greg started work on getting strace to work. He's trying to do this natively on fluffy, but unfortunately we are still being plagued by assorted NFS errors and timeouts. It's really painful. As a datapoint, trying to save a file from inside Chiyonofuji's "vi" hangs for ages. We strongly suspect a bug with NFS writes.
  • Cleaned up some more files and directories in our working area.
  • Sent mail to Warren Harris.
  • Did we mention the strace user-mode code is simply hideous?

I want to get a CD containing the RedHat 6.2 source RPMs. This would be a convenient way of making new or replacement packages for Chiyonofuji when we find existing ones that don't work, like inetd.

There's just so much stuff we could work on. What to do next? We really need a whiteboard so we can chuck TODOs on it and juggle them around until we get a priority we're happy with. Hmm, might do it with some scraps of paper.

Mon Aug 14 14:38:10 EST 2000 1015-1315, 1415-1800, 2300-0430:
  • Drew up purchase order for Craig.
  • Rang Optus to order the cable modem. The installers will be here in one week - Monday between noon and 5pm.
  • Rang a local computer hardware retailer, got him to order a Netgear RT311 home router from his distributor. We will use this as our firewall. Should be picking this up tomorrow afternoon.
  • Rearranged our office, with the addition of Greg's table. Rerouted and tidied up all the cables and the junk that's been accumulating. Now it looks like an office!
  • Went to lunch at 1315, back at 1415. Picked up credit card.
  • cvs uped our checkouts. This PSTN modem is killing us - 15 minutes per checkout per update.
  • Cleaned up and deleted a few old checkouts we had.
  • Drew up list of equipment we need.
  • mjd worked on the NFS timeout problem. Turns out that to effectively debug the kernel after it's started we will need a separate command channel from the serial port, either another serial port or telnet over the Ethernet port.
  • gnb worked on building a telnetd for the SuperH. After spending a lot of time on it, in.telnet was found in /usr/libexec/. What's it doing there?
  • inetd is not working. netstat shows no waiting connections, even though inetd is running. After much head- scratching, we found that the "syslog" logging mechanism wasn't working. /dev/log could not be created by syslogd. We traced this down to having left "Unix-domain sockets" out of the kernel configuration.
  • After this, inetd was running, but not binding any ports. After much head-scratching we found that the inetd program doesn't have a problem, but the chiyonofuji distribution has misconfigured it by putting the config file somewhere else. After creating the necessary configuration files, inetd seems to work now. In particular, Greg symlinked /usr/etc/ to /etc/. Did inetd ever work?
  • Grr, this inetd has a bug: It adds extra, random and irrelevant options to the program it's spawning. As an example, in.ftpd complains about being given "-L" - where does that come from? This is possibly because TCP wrappers aren't being used on this machine, but we'd need to dig around more to find out.
  • We tried to run the in.ftpd daemon manually, but it doesn't like the -p flag that is supposed to tell it to open its own connection, rather than being handed the connection on stdin/stdout like when it's started by inetd.
  • We're now starting in.telnetd manually, but the client-side telnet says "All network ports in use". We think this is because there are no pseudo-ttys. Time to get them working.
  • Created /dev/ttys[0-7] and /dev/ptys[0-7] and tried again. No luck. Maybe it uses Unix98 ptys.
  • Recompiled the kernel with Unix98 ptys. Still doesn't work.
  • Worked out how to mount the devpts filesystem necessary for Unix98.
  • Grr, still the same problem. Greg is looking at the glibc sources to see how it accesses ptys. It seems to try and use the Unix98 method (if the kernel headers glibc is built against supports Unix98 ptys). If they're not available, it falls back to the BSD pty method.
  • Oops, those BSD pty/tty pairs should have been [pt]typ instead. Once we fixed that, we now get a login prompt. But after the username, things die. It turns out that in.telnetd is looking for /usr/bin/login which doesn't exist in chiyonofuji. This incarnation of in.telnetd could never have worked! We worked around this by symlinking /usr/bin/login to /bin/login, which does exist.
  • Well, a telnet login works!! Hi-5's all round!! inetd is still broken though - without it, in.telnetd will have to be manually started via the serial port whenever we want to log in. But at least we can log in two people at the same time, and we can use the serial line as the debugger channel for kernel debugging while using the network for interaction.
  • Sent off mails to people.
  • Arrgh! The cache patches that Niibe-san checked in earlier today seem to have fixed our NFS problems. More testing tomorrow.

One conclusion we have reached: Although Chiyonofuji shows signs of not having been extensively exercised, the selection of packages and its basic philosophy will make a worthwhile basis for the work we're planning in the future. I think coupling this with Stuart's ideas of having source RPMs for the packages in the distribution and we have a winner. I cannot wait to start working on it.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!