First, apache stopped serving http://localhost/ -- not important for most machines, but on the laptop it's nice to be able to use a local web server when there's no network connected. Further investigation revealed that this had nothing to do with apache: it was localhost that wasn't working, for any port. I thought perhaps my recent install of 2.4.29 was at fault, since some configuration had changed, but that wasn't it either. Eventually I discovered that the lo interface was there, but wasn't being configured, because my boot-time tweaking had disabled the ifupdown boot-time script, normally called from /etc/rcS.d.
That's all straightforward, and I restored ifupdown to its
rightful place using update-rc.d ifupdown start 39 S .
Dancer suggested apt-get install --reinstall ifupdown which sounds like a better way; I'll do that next time. But meanwhile, what's this ifupdown-clean script that gets installed as S18ifupdown-clean ?
I asked around, but nobody seemed to know, and googling doesn't make it any clearer. The script obviously cleans up something related to /etc/network/ifstate, which seems to be a text file holding the names of the currently configured network interfaces. Why? Wouldn't it be better to get this information from the kernel or from ifconfig? I remain unclear as to what the ifstate file is for or why ifupdown-clean is needed.
Now my loopback interface worked -- hurray!
But after another dist-upgrade, now eth0 stopped working. It turns out there's a new hotplug in town. (I knew this because apt-get asked me for permission to overwrite /etc/hotplug/net.agent; the changes were significant enough that I said yes, fully aware that this would likely break eth0.) The new net.agent comes with comments referencing NET_AGENT_POLICY in /etc/default/hotplug, and documentation in /usr/share/doc/hotplug/README.Debian. I found the documentation baffling -- did NET_AGENT_POLICY=all mean that it would try to configure all interfaces on boot, or only that it would try to configure them when they were hotplugged?
It turns out it means the latter. net.agent defaults to NET_AGENT_POLICY=hotplug, which doesn't do anything unless you edit /etc/network/interfaces and make a bunch of changes; but changing NET_AGENT_POLICY=all makes hotplug "just work". I didn't even have to excise LIFACE from the net.agent code, like I needed to in the previous release. And it still works fine with all my existing Network Schemes entries in /etc/network/interfaces.
This new hotplug looks like a win for laptop users. I haven't tried it with usb yet, but I have no reason to worry about that.
Speaking of usb, hotplug, and the laptop: I'm forever hoping to switch to the 2.6 kernel, because it handles usb hotplug so much better than 2.4; but so far, I've been prevented by PCMCIA hotplug issues and general instability when the laptop suspends and resumes. (2.6 works fine on the desktop, where PCMCIA and power management don't come into play.)
A few days ago, I built both 2.4.29 and 2.6.10, since I was behind on both branches. 2.4.29 works fine. 2.6.10, alas, is even less stable than 2.6.9 was. On the laptop's very first resume from BIOS suspend after the first 2.6.10 boot, it hung, in the same way I'd been seeing sporadically from 2.6.9: no keyboard lights blinking (so not a kernel "oops"), cpu fan sometimes spinning, and no keyboard response to ctl-alt-Fn or anything else. I suppose the next step is to hook up the "magic sysrq" key and see if it responds to the keyboard at all when in that state.
[ 23:06 Mar 02, 2005 More linux | permalink to this entry | comments ]