Tales From The Geek Side

It seems that every time I setup a diskless Linux machine I run into the same problem — nfs mounts hang. I’m not talking about the root filesystem. That mounts fine but other mount points result in mount hanging. Then I track the problem down to rpc.statd and portmap hanging. I also end up coming back to my blog to search for the answer to this problem and get frustrated when I can’t find the answer that to a problem that I’ve solved over and over. So, once and for all, I present the solution to the problem that I know I’ll encounter again.

The problem is that the localhost interface is not defined in /etc/network/interfaces and this causes problems (I do not know why) with the nfs/rpc tools. When I setup diskless machines I use debootstrap to create a root file system. Debootstrap correctly leaves a few things unconfigured. The localhost interface is one of them. And so I say to my future self, “self, just add this to /etc/network/interfaces and all will be well. And calm down this isn’t a big deal!” :

I’ve had an excellent setup using MythTV and a VIA M10000 based system. The M10000 is the frontend which has a 1Ghz VIA chip and onboard hardware support for mpeg2 decoding. When watching TV shows that I recorded using an analog tuner card the system showed about 10% CPU utilization! It was perfect…until digital TV arrived.

Actually the M10000 is fine for digital television if the resolution is in the standard def ranges. 720p content and 1080i content it can not handle in real time. This is because the hardware MPEG decoding is limited to a maximum resolution which the HDTV broadcasts exceed. The onboard CPU isn’t nearly powerful enough to decode the content in real time.

I decided to move my desktop system, a 2Ghz Pentium-M based SD11G5 from Shuttle, downstairs to be my new myth frontend. At the same time I decided to get rid of the Myth frontend software and instead use XBMC. I did some tests and it seemed like it would work perfectly.

Once I got everything setup I found that things did not work perfectly. My testing was with 1080i broadcasts which I assumed would be more taxing on the system than 720p broadcasts. I was wrong. The system can handle 1080i just fine but it can not keep up with 720p. This must be due to the frame rate.

I now have a dual core atom system with an NVIDIA video card. Using XBMC with VDPAU support I should be able to decode anything I throw at the system. I’ve built the system but I haven’t setup XBMC for it yet. I’ll report out when I get that fully functioning.

Sometimes you need to update packages on a Debian based system but you don’t want to updated all of them. For example there are security updates available right now for a system I manage. One of those updates is the linux kernel. I’m not ready to upgrade the kernel because it is a remote machine that many people depend on. To do a kernel upgrade I need to schedule downtime and prepare for the case when the system doesn’t reboot after the upgrade.

With Debian based systems you can handle this by placing packages on hold. Packages that are on hold are not updated. If you use aptitude this is as easy as:

If you use apt-get you can accomplish the same thing with:

When you are ready to update the package you can take it off of hold with (for aptitude):

And for apt-get/dpkg it is accomplished by:

Read the rest of this entry »