Friday, January 19, 2007

Automated shutdown on power failure - Trial by fire

I installed apcupsd last year. I tested it through to see that all power states are properly recognized, but never did a full power down test to make sure that the system shuts down when battery power runs low. Today we lost power for over 1 1/2 hours and it worked just perfectly:

Jan 19 07:00:02 chef syslogd: restart
Jan 19 14:11:34 chef apcupsd[26943]: Power failure.
Jan 19 14:11:40 chef apcupsd[26943]: Running on UPS batteries.
Jan 19 15:11:21 chef apcupsd[26943]: Battery charge below low limit.
Jan 19 15:11:21 chef apcupsd[26943]: Initiating system shutdown!
Jan 19 15:11:21 chef apcupsd[26943]: User logins prohibited
Jan 19 15:11:21 chef apcupsd[26943]: Attempting to kill the UPS power!
Jan 19 15:11:24 chef syslogd: exiting on signal 15
Jan 19 15:34:48 chef syslogd: restart
Jan 19 15:34:48 chef /bsd: OpenBSD 3.8-stable (RAID) #1: Thu Apr 20 21:55:59 PDT 2006
Jan 19 15:34:48 chef /bsd: root@chef.lostentry.org:/usr/src/sys/arch/i386/compile/RAID


Battery started running low after an hour, and apcupsd initiated a clean system shutdown. When the power returned the server rebooted just fine and went merrily on its way. Neat.

Wednesday, January 03, 2007

Monday, December 25, 2006

Christmas 2006



Merry Christmas!

Friday, December 15, 2006

Rain, Wind, Storm ... No Power

I'm in Seattle this week. The rain comes and goes as usual for this time of the year.

Yesterday afternoon a major storm hit the Northwest. At 5pm we decided to shut down the servers and network in the office, since we had ongoing brownouts and briefly lost power. Outside, the wind was howling around the building, the rain blowing accross the street horizontally. Windows were rattling. Lake Washington had a good surf going, you could see it even from the office. Most of the employees went home.

We took off to drive to a co-worker's house in Bellevue. The office parking lot was flooded, the garage was flooded, and the street gutters were full of water. The normally 15 minute drive to Bellevue took us over an hour on the side-streets. Multiple stop lights were out and cars waiting their turn all over the place. Very orderly though, I must say. Once we got there we had good food and lots of fun. I tried playing Tennis on the Wii as well as a few other games.

Here's a picture of a flodded garage. It's hard to see, but water depth was about 1 foot.

11:30pm

I got back to the apartment with light rain and a decent amount of wind. I planned to be in the office early to bring up the infrastructure back up once the storm has blown over. It was supposed to peak at 2am.

5:00am

Well, yeah... I got a call from the local helpdesk manager not to bother. I notice the power is out in my apartment. "The power is out in 90% of western Washington." Oh... Well then, I'm going back to sleep now.

6:00am

"The office building is dead. 3 feet of water in the lower level of the garage" Guess it's unlikely I'm going to work today. I'll see when and where I can find some coffee and breakfast. In an hour I'll call Patricia to find out what's going on at Sea-Tac, and if my flight this afternoon is still on.

8:00am

Power still out. I take a shower in the dark bathroom. The water is lukewarm. I consider myself lucky. After some consideration and looking out of the window, I decide to pack my stuff and get it down to the car. No point hanging out in the apartment with no power or heat. I want some coffee.
The trip down the pitchblack stairwell with no windows was ... interesting. Good thing the display of my cell phone is this bright.

9:00am

Still no power. I stopped by the office to found the building locked with a couple employees outside chatting. The lower level of the garage is still flooded. They are pumping the water out, only making slow progress. I don't envy the owners of the few cars left in there.

The guy stocking our mini-kitchens left some danish and cranberry cake outside the lobby doors. Good. Still craving a coffee. It starts raining again. "All the power is out in the city of Kirkland", a police officer who was checking on one of the local banks tells me. Bellevue may have power, I'm told, so I decide to make my way down I-405 towards the airport.

The floating bridge accross Lake Washington is still closed. They closed it last night before the brunt of the storm came in, since it's unsafe to cross with heavy winds. Which means all the traffic headed to Seattle has to go down to I-90 and across Mercer Island. I'm in the middle of that traffic. Crap.

10:30am

I tried taking side-streets looking for some coffee place and to bypass the mess on I-405. Success for the latter, but still no coffee. Eventually I get south of I-90, make it via Factoria and Coalcreek Parkway back to I-405 and out to the airport.

11:30am

I got to the airport early enough to catch an earlier flight back to San Jose. Phew. Looking forward to see Patricia and the kids.

Lessons learned:


  • Don't expect to be able to get back into the office building the next morning. Take the stuff you might need.
  • Carry a flashlight. I'll get one of those little keychain lights. Way better than nothing.
  • Listen to the news and traffic reports. Find one of those AM news channels. I got a pretty good picture on what's going on. They advised to avoid I-405 between Bellevue and I-90. I should have taken I-405 north to I-5 and on to the airport through Seattle.
  • Always carry some cash. Most ATMs and credit card pay stations don't work without utility power.



Sunday, December 17th:

Power was restored to the office this morning. As I'm writing this there are still over 200,000 people without power in western Washington. Down from over a million Friday morning. I'm just reminded again how much we depend on and are used to the conveniences of modern live. Electricity, clean water, garbage pickup. This was a weather event, people could prepare at least a little bit. However, I'm living in earthquake country. Those things happen without warning. We better get our earthquake kit back together (we had to throw everything out after a rat hit the jackpot and got into the storage box...).

Friday, December 08, 2006

Lucky snapshot



Taken late September in Santa Cruz. Union Pacific freight train returning from the cement plant in Davenport..

UP 916 (GP38) is leading UP 1351 (GP40-2, ex-DRGW) crossing Bay St in Santa Cruz.

Saturday, December 02, 2006

Got a transformer

... and the "Krokodil" no longer requires a 9V battery.



Monday, November 27, 2006

cleaning track...

Amazing how grimy old track can be. Yuck. I used a dry scotch brite cloth to wipe off all the dust, oxidation and dirt from these old brass rails. First with the green side to scrape off the big stuff, then with the yellow side to wipe off any leftovers. low and behold, it worked on the first try.

I cleand four straight pieces of track and within minutes the old "Krokodil" was going up and down the track powered by a 9V block battery held right against the rails. HO track is just wide enough for the connectors of the battery to fit.

This worked so well, I cleaned a dozen curves and set up a little oval on the table. After a few rounds of sputtering the track was clean enough that the locomotive was running around in circles just fine. Exciting!

Sunday, November 26, 2006

Model railroading...

So, over the weekend I had a good conversation about model railroading (and railroading in general), which made my heart ache with the thought of the really nice Maerklin layout we have at my parents place back in Germany. I pulled out the only electric train stuff I have in the house here, the "FischerTechnik Bauspielbahn", a Fleischmann track based trainset my father bought for me and my brother a long, long, long time ago. I must have played with this the last time maybe 20 years ago. To my surprise the one motor left in the two locomotives is still working just fine, including the familiar whining sound it always had. No idea what happened to the other motor.

Just the rails ... oh boy. Brass track. No conductivity at all. Zip. I learn from a Google search that brass track is the worst. Lots of oxidation of the non-conducting kind. ok, looks like in order to make this work, I'll have to clean the track ... somehow.

Reading up on cleaning blocks, and various other methods serious railroaders recommend is ... pretty cool. Doesn't really apply to my situation, though. Heck, this is not even a real layout or anything. Either way, I'll give this cleaning idea a shot on a few pieces of track. Just for fun.

Friday, November 24, 2006

Audiotron and smb server on different subnet

What a pain.

The Audiotron appears to be unable to work with a WINS server. There is no way to specify one in the Web UI. I tried various approaches to get this work:


  • force global browse master on gw by running the Samba nmbd server with the appropriate smb.conf file (Audiotron finds the browse master on gw, but apparently ignores the information about hosts in other subnets)
  • limit and eventually turn off the firewall rules dropping packets between the wired and wireless portions of my network (I do have holes for smb traffic, but it doesn't matter. I can get to //chef/media just fine using smbclient via wireless)
  • redirect 137/138/139 tcp/udp from gw to chef (doesn't work because of heavy use of broadcasts in the smb protocol)
  • Allow remote hosts in the Audiotron WebUI (no visible effect)
  • Hardcode the specific share name \\chef\media in the Audiotron WebUI (no visible effect)
  • make heavy use of tcpdump on all systems involved (except the Audiotron which is a closed box)
  • search Google (and this blog is among the first 20 hits when I search for [audiotron browse master]...)
  • make sure all the passwords are right for the media user, both in the Audiotron and on chef (checked)
  • confirmed using nmblookup that I can't see chef, when browsing the wireless broadcast domain (duh, of course not. It's a separate /24.)
  • The Audiotron aborts browsing the subnet, if it can't find a running smbd on gw (how annoying)


In some cases chef shows up in the Audiotron log with "No IP reply". The Turtle Beach docs are fairly unhelpful on this whole thing.

Since WINS is not supported by the Audiotron and hardcoding paths on the Audiotron doesn't seem to have any effect, I'm thinking about bringing the songs closer to the Audiotron: Mount the media partition via NFS from Chef on gw, then export the NFS mount from gw via Samba to the wireless side.

How ugly.

I searched more and found a note in the Audiotron FAQ that the Audiotron does indeed support WINS, but the server information has to come from DHCP. The option for isc-dhcpd is netbios-name-servers in dhcp.conf. That might work. I'll try that when we are back from shopping. It's Black Friday after all.

...

Finally! It's working.

Serving netbios-name-servers via dhcp didn't seem to have any visible effect.
The magic config options that made it work were "dns proxy = yes" and "wins proxy = yes"in smb.conf on gw. Then I went into manual configuration mode on the Audiotron and set it explicitly to get the music from \\chef\media.
Samba on chef was not configured to use the WINS nmbd on gw, so nmbd didn't serve IP information for chef, even though it served the name as part of the list when queried.

So, in the end, as usual, it was operator error. I could have saved myself quite some pain by configuring chef as WINS client of gw, or run a WINS server on chef outright and serve chef's IP as WINS server to the Audiotron via dhcp. Actually, that's not a bad idea, I'd rather not have smbd/nmbd running on gw...
Not tonight, though, now that Patricia is happily listening to music served by this crazy infrastructure.

So, here's what I'm going to try next:
- run WINS server on chef
- serve chef as netbios-name-server in dhcpd.conf for the audiotron
- turn off nmbd and smbd on gw
- Verify I can still listen to music...

Update:
The Audiotron appears to ignore the dhcp option netbios-name-servers. With only nmbd running on gw, being the WINS server, and the Audiotron manually set to go to \\chef\media, it finds my songs just fine. Good enough for me.

A curious note:
When the Audiotron tries to resolve a remote name it queries first for "A? CHEF.", it gets a NXDomain in my network. Then it uses the fully qualified domain name "A? chef.domain.comm". Not a typo, it actually appears to append an 'm' to the query. I couldn't find the source of the extra 'm'. Even reset the Audiotron to factory defaults and started over, still queries an extra 'm'.

Tuesday, November 21, 2006

There ... now it happened

It's my own fault. I connected the serial console of my Net-4801 to chef, started minicom and ... nothing happened. A fatal "Send Break" later, minicom is no longer responding and the userland on chef is dead. No idea _why_ that happened, but it coincided with the break on the serial port. Thankfully, chef's kernel dutifully continued to route traffic, so I could search Google, and openbsd.org, but to no avail. In the end I power-cycled chef and am now waiting for the raid check to complete. *sigh*

On the positive side, my Internet connection is now running through the NET-4801. mail and web will continue to be handled by chef for the time being (once it comes back up), but basic Internet access as well as my private domain server and key-protected ssh are working already. My prep-work from early October paid off. Another 1.5 hours to go until chef is back online. I'm going to bed, but set the alarm early, so I can fix email before Patricia gets up.

Things left to do for chef:
- ifconfig to .10
- connect LAN cable
- reconfigure syslog to use -u and accept syslog from gw
- test mail connectivity (local and remote)
- test web connectivity (local and remote, both sites)

Update:
I also had to add the rdr entries for PF to redirect web/mail connections to chef. Then, my website didn't work anymore from the inside, because the redirect is applied only on traffic that enters gw on the outside interface, so I changed the internal DNS views to resolve my websites straight to chef, instead of going through gw.
Testing the configuration from my workstation at work, it worked right away for web access, but for the heck of it I couldn't get a SMTP connnection going. Everything looked right on my end. Actually, I used the same config options for web as for mail. While thinking about this, I noticed a mail coming in. Huh? ... I remembered we block outbound SMTP from workstations at work. Alright, all good.

Sunday, November 19, 2006

pvr500 and composite input

I'd really like to access DVDs through the MythTV interface, as well as be able to hook up my camcorder and convert analog video to MPEG2 streams. My TV has only one composite input and that's taken by MythTV, so the DVD thing is mostly for convenience. The catch? It doesn't seem to work.

I got the closest today. After scouring Google and reading lots and lots of different How-tos the most promising approach for getting the DVD player/camcorder hooked up was to define a new video source, bind it to the composite input, manually define a channel and off we go. Uhm, yeah. Not quite. The new channel (1001 - DVD) shows up in the channel selection. However, when I do select it, apparently MythTV tries to use the tuner to select it, which doesn't work. Either, the channel doesn't switch, and I continue to see Fox and then roll over to channel 82, or depending on which approach I tried, the channel switches and I won't get out of this mode anymore, and only got a black screen. Even [ESC] didn't work anymore. Couldn't tell whether the front-end or the back-end hung.

What's more frustrating is that even with ivtvctl -p, I can't seem to switch inputs on the PVR500. It does work, however, if I don't start mythbackend at all on boot. I'm suspecting an issue between MythTV, the ivtv driver, and the PVR500 card.


I'm using Linux 2.6.15 with ivtv 0.4.4. Looks like I'm going to sync grumpy to the latest Debian testing, 2.6.18 and ivtv 0.7 (or so). And then rebuild the nvidia driver, and take care of other mayhem that might ensue. I'm hoping this will also fix the problems we have with closed captioning (VBI).

Sunday, November 05, 2006

kde kamera DOES support disconnecting and reconnecting the camera

... it's just not obvious.

I use KDE's kio_kamera to download my photos from our Canon Rebel Digital SLR. Whenever I connect the camera a new USB address gets allocated and we end up with a URL like this:

camera://Canon EOS 300D (normal mode)@[usb:001,006]/

The camera icon on the desktop eventually takes me to camera:/, which is an overview page of configured devices. When I plug in the camera, this page always comes up with links to the usb address when the camera was first plugged in that day (usually usb:001,004), so I can't just click through. Annoying. More annoying is that many pages under camera:/ are cached, so it appears to be working until I get to the actual images folders and then get "port not found".

Solution:
In the camera:/ location, refresh the page, then continue. Simple as that. Now, if I could get kio_kamera to do this for me...

Saturday, October 21, 2006

ATX power supplies

I admit I'm behind the times with PC hardware. That comes with being a bottom feeder. I usually buy technology only when it gets close to be thrown out of the stores. I like special offers, particularly clearances. So, yes, most of my stuff here is on the outdated end. But it's cheap, some of it even free.

So, last weekend when I bought a power supply to replace the rather old power supply in chef, I went for a half-way decent, but relatively cheap power supply from CoolerMaster (400W, reg. $39.90, onsale for $27.50). If only I had paid more attention to the labels.

ATX12V 2.01 actually means not only serial ATA power connectors and this extra 4pin 12V connector for the CPU (which I don't need since I don't have those). It also means that instead of 20 pins the ATX mainboard connector now has 24 pins, apparently to satisfy the power needs of PCI Express (which I don't have either).

The ca. 2001 motherboard in chef has a 20pin connector, and yes the pinout of the lower 20 pins is all backwards compatible to the old socket. However, in their infinite wisdom the Acorp motherboard designers placed a couple capacitors right next to the mainboard power connector. Exactly in the spot where the extra 4 pins would hang over. Ugh.

It's not too bad, though. I was eyeing to upgrade my Linux rackmount upstairs with something more modern anyways (the mainboard of that computer currently does duty in my MythTV box). Might as well keep the new power supply, and move the power supply from the rackmount into Tatjana's computer for now.

Update (Nov 21):
I ended up buying an adapter cable at Central Computer that translates the 24pin ATX powersupply connect to a 20pin connect as needed by my motherboard. The old power supply from chef is going to move to Tatjana's computer. We are not using that computer nearly as often...

Sunday, October 15, 2006

Exploding capacitors

Thursday Patricia calls me with a very alarmed voice, "Hey, it stinks as if something's burning, and there was a loud pop from the computer cabinet". Hmmm, that doesn't sound good. We shut down all the computers in the cabinet until I come home.


Once the kids are in bed, I unrack the firewall machine, open it up, and yes, there is some smell, but not really bad. While I'm looking at the firewall machine, Tatjana's computer turns itself on spontaneously, a loud pop, and electric smell starts to fill the air. "That must be what Patricia meant when she called me."


Nothing out of the ordinary when I open the case, aside from the smell. However, when I open the power supply, the first thing I see are a two capacitor shells sitting oddly in the corner. Also note, how the leftmost capacitor is starting to bend the pressure relief top upwards.


"What is that furry stuff anyways?". The content of the capacitors. Look at the blast marks on the metal heatsink in the background, and the nicely blackend resistor.


As the capacitor on the right blew up it must have hit something in the powersupply (probably the metal heatsink), which dented the top quite a bit.

Saturday, October 14, 2006

Soekris NET4801-60

Having a firewall, mail server, file server, web server, ... all on the same box is just a bad idea. Every sysadmin knows that. I run my firewall on OpenBSD which makes me feel better, but not comfortable. OpenBSD's software RAID (RAIDframe) scares me every time the machine crashes (which happens seldomly, actually only once so far, but that's another story), or loses power (which used to happen more often. Thanks to my UPS that's no longer an issue). I like my firewall to run OpenBSD, but I just don't need yet another computer sucking up power in my living room.

When a co-worker was looking for some more people to join in a bulk-oder for Soekris NET4801 boxes I got in. A few weeks later it was on my desk. Nice box, metal case, AMD Geode 266, 256MB main memory. I have a 1GB CF card (specs as displayed by comBIOS: "SAMSUNG CF/ATA LBA Xlt 1012-32-63 1020 Mbyte"), and a 256MB CF card ("Hitachi XXM2.3.0 LBA 695-15-48 250 Mbyte"). Originally, I wanted to run even my Web server from the Soekris box, but then realized that the photo collection on the Web site alone eats up 3.2GB already. Whoops. Oh well, don't have that much storage, so I put the 1GB CF card into our Canon Rebel Digital SLR, and use the 256MB card for the soekris box.

I replaced FreeBSD on Sneezy with the latest OpenBSD built (and will upgrade again, come 4.0 in November) and started to investigate flashdist.sh, a snazzy shell script that builds an OpenBSD distribution on flash media. Oh, I need a flash reader? ... Our Nikon Coolpix 2100 shows up as a regular flash media when plugged in to USB:


umass0 at uhub0 port 1 configuration 1 interface 0
umass0: NIKON NIKON DSC E2100, rev 1.10/1.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets
sd0 at scsibus1 targ 1 lun 0: SCSI2 0/direct removable
sd0: 244MB, 244 cyl, 64 head, 32 sec, 512 bytes/sec, 500400 sec total


ok. that was easy.

I built a NET4801 kernel with the config from the flashdist archive and ran


flashdist.sh sd0 flashsmall.txt bsd-4801 /tmp/openbsd39/ bsd-4801 /tmp/openbsd39/


disklabel comes back with:

Total size of media: 500400 sectors (256204800 bytes)
Bytes/Sector: 512
Sectors/Track: 48
Sectors/Cylinder: 720
Tracks/Cylinder (heads): 15
Cylinders: 695


Once everything is on the flash, I reboot the Soekris box and it just works. Nice.

Now on to configuring things they way I actually want them.

distflash.sh pulls the default configurations from a staging area on Sneezy. For now I'm configuring stuff directly on the Soekris box, now affectionately named "gw". Once I'm done I'm planning to run a find accross the whole file system looking for files that are newer than today 18:07, and save all my changes back to the staging area on sneezy.

Here's the service split between gw and chef:

gw:

  • three ethernet legs - working
  • PF - working
  • dhcpd - working
  • named - working
  • sshd - working
  • ntpd - done, not thoroughly tested yet
  • smb service to wireless network - working (see the long story)
  • httpd - redirect working
  • email proxy - redirect working
  • apcupsd - not done (stays on chef for now)
  • snmpd - not done (not critical)
  • sensorsd - not done (not critical)


chef:

  • email - postfix (working)
  • email - dovecot (working, to be replaced with courier)
  • email - spamassassin (working)
  • email - squirrelmail (won't fix)
  • media files - nfs (working)
  • media files - smb (working)
  • httpd - apache (working)
  • httpd - authenticated proxying to grumpy/mythweb (not done, not critical)
  • HD stats - smartd (working)
  • network monitoring - mrtg (working, needs gw added)
  • monitoring - nagios (not done, not critical)


I my current setup the music files on chef are exported via smb both to the wireless and the wired LAN, so I actually don't have to worry about anything. In the new setup chef is only connected to the wired LAN. smb broadcasts from the Audiotron won't be sufficient to find chef. This link at O'Reilly seems to indicate that I need to run Samba as a wins server. However, funny enough, right now when the Audiotron probes the network for music files, it will show babybaer which is only connected to the wired network. Why is that? I suspect chef is browse master and responds with the host lists for both the wired and wireless segments, so I either need a WINS server on chef, and point the Audiotron at that, or, if the Audiotron doesn't support WINS, run a smbd on gw and force it to try to acquire browse master.

Sunday, August 13, 2006

OpenBSD, bind, NAT & aliased IPs

Yay for routing and NAT. Not.

I'm using RollerNet for my secondary DNS. Works quite nicely most of the time, but hey it's free. The DNS logs at rollernet showed

zone goodcoffee.net/IN: refused notify from non-master: 216.27.180.188#14688


Hmmm, yeah, ns.goodcoffee.net is on 216.27.180.215, which is an alias on my outside interface. I'm not serving requests on .188. ok, so bind just hands the notify to the OS, which does its thing and sends out the notify via the default route. Only, that happens to not be the master in the bind config at RollerNet.

I like my setup, so let's just reverse the assignment of IP and alias. Long story short, PF doesn't allow NAT on an aliased IP. I couldn't get it to rewrite outbound traffic for the RollerNet name servers to come from .215. Nor could I convince bind to use .215.

After some fussing with configs and options, I eventually changed the bind config to listen on .188, and changed RollerNet to take .188 as the master. Since that looks ugly in the config, I'm migrating the DNS entry for ns.goodcoffee.net from .215 to .188. Along the way I fixed bind and PF configs to use the new ns2.rollernet.us IP.

Hah, ns1.rollernet.us apparently didn't notice the change in the configuration yet. It's still refusing notifies from .188, while ns2.rollernet.us already happily serves the updated zone. I'll wait some time before I stop serving DNS on .215.

Update:
ns1.rollernet.us came around to update as well 15 minutes later. All is good now.

Saturday, July 29, 2006

Friday, July 28, 2006

grumpy and wireless

Having much more success with the WG111T now on grumpy. I attached it to the supplied cable and left it on the TV cabinet, instead of connecting straight to the PC. Transferred several hundred MB of movie files with no issues whatsoever. I get about 830kByte/s (7MBit/s) actual throughput on wlan0 when copying files via scp. Not great, but perfectly sufficient for the occasional file transfer and daily program guide updates.


Some fun with ARP and routing

grumpy has eth0 on my internal network, and wlan0 on the WG111T. My wireless LAN is a separate leg off the firewall. Originally, it was an open WLAN with its own IP space, DHCP, etc. I set this up this way so that others can use my connection if they are within reach. However, with all the multimedia equipment now on the WLAN (and the Linux drivers supporting encryption), I turned on WEP. Not perfect security, I know, not even close, but better than nothing. But I disgress...

So, when grumpy has wlan0 enabled, I can ping grumpy.wlan from the wired network iff I ifdown eth0.
Looks like either the kernel on grumpy sees the directly attached network and tries to reply to ICMP requests originating on the wired LAN via eth0, even though they were sent to wlan0 via the firewall. This happens even when the cable is disconnected, resulting in an (incomplete) ARP entry. So, in order to access grumpy from the wired LAN, eth0 needs to be ifdown when the cable is disconnected.
However, I want it up if the cable is connected. Now, how do I do that?
...
ifplugd to the rescue. It's very straight-forward, easy to configure. It detects when the network cable is plugged in and configures and unconfigures eth0 accordingly.
The catch?
MythTV is configured to use the IP address of eth0 for the backend server. If I unconfigure the interface, mythfrontend is getting *very* unhappy. *sigh*
Let's use 127.0.0.1 for now...

Update:
After leaving grumpy running overnight in this config, wlan0 was dead _again_ this morning. rmmod ehci_hcd . Let's see if it's really the ehci module causing issues. Of course, that drops the transfer rate to a measly 230kByte/s.

Update:
grumpy has been running for two weeks with no wireless drops. So it really is the ehci_hcd kernel module giving me grief. I wonder if going to kernel 2.6.17 would help, but ah, the pain of rebuilding all the drivers for the TV cards. otoh, going to ivtv 0.6.x might fix closed captioning support. Hmmmm.

Thursday, July 27, 2006

grumpy gets a bigger hard drive

I started grumpy with a 120G drive I had laying around, figuring this will last for a while. As I quickly discovered, not so. Particularly, when I wanted to keep a few movies around. Also, the ShiftTV pieces started to eat up space quickly.

So, I finally got a whopping 300GB disk at Fry's. Special offer, 80 bucks. Not too bad. Here's how I transfered the system to the new disk:

  • partition the new disk like the old one, just bigger /opt (where I keep the movies)

  • initialize the file systems (mke2fs -j /dev/hdc1, mkfs.jfs /dev/hdc6, mkswap /dev/hdc5) and mount them under /mnt/

  • Use cpio to transfer the files from the root file system: find / -xdev -print0 | cpio -pa0V /mnt/hdc1

  • Use a plain cp to copy the video files (which cpio doesn't like due to huge file sizes): cp -av /opt/* /mnt/hdc6/

  • Install grub: grub-install --root-directory:/mnt/hdc1 /dev/hdc


ok, the latter didn't work ("/dev/hdc does not have any corresponding BIOS drive"). wtf? after searching quite a bit I ended up editing /mnt/hdc1/boot/grub/devices.map. adding

(hd1) /dev/hdc

finally, that worked. and I can boot from that drive when it is hda.

Monday, July 24, 2006

ACPI wakeup and grumpy

Going to sleep and waking up works great from MythTV. With a few gotchas:


  • if the frontend is running, the backend doesn't shut down the system.
  • echoing into /proc/acpi/alarm reliably starts the system... at midnight. The BIOS seems to completely ignore the time I set.


Once the frontend is not running, it's not trivial to bring it up again (particularly for my family). I'm running a window manager, in order to be able to use MythVideo properly. Otherwise, this would be simple (mythfrontend exits, gpm comes up again). I need a little app that just loops forever, accepts a key stroke to bring up the frontend, and when it exists, loops back.
Maybe even include some automated shut-down counter off the mythtv logs somehow. Hmmm, there's a little project to start playing with Ruby... or learn about window programming in Python.

The latter is more nasty. I guess, I have to check out nvram, or play with some wake-on-lan solution, but that would require that the wireless network connection worked properly.

But first, it's time to haul the trash from our recent kitchen remodel to the landfill.

Update (a few days later):
I suck. Had a typo in the script filename given to MythTV. sudo executed with no error, even though it couldn't find the script, so the shutdown proceeded without setting a new wakeup time. I'm still puzzled why grumpy wakes up at midnight.