What a difference a video card makes…

A couple months back I tried getting a Dell 2007WFP working with X, using the Intel graphics controller built into my motherboard. I didn’t have much luck. Well, now I have a new video card, with an nVidia GeForce MX 4400 chipset. And, all I had to do was specify the card, driver and resolution (1680×1050) in my xorg.conf, and it worked right away. Great. Still more work than it was with my Mac (where I just plugged it in and it worked), but not bad at all, especially considering that this is X.

Still a few things to be resolved:

1. The new card is only working through the VGA port. Need to figure out what magic incantations I need to use DVI.
2. Apparently I can’t use the onboard graphics controller and the new (AGP) card at the same time. As soon as I plugged the new card in, it was like the onboard controller didn’t exist. So, I’m still stuck using the old Matrox PCI card for my other monitor. The Matrox only has 8mb video memory, which limits me to a 16 bit display depth. The MX 4400 apparently supports multiheading via the DVI port and VGA port, so I’ll have to see if I can do this with X.
3. The widescreen monitor is vertically smaller than my other standard-resolution flat panels. I’m getting a little squinty-eyed staring at it. I think I may make it the “secondary” display and use a physically larger screen as my “primary” display.

But all in all, I’m really happy to have the 1680×1050 working, and without much extra fiddling or hair-pulling.

On another note, I’ve restored sonata to a new drive (after its old drive crashed). I lost a few files before I backed the dying drive up. The system works fine, but fonts in some applications are screwy (screwy fonts in X is a relative term, of course…). So, I may end up reinstalling the machine anyhow…

Followup… looks like I may need to use nVidia’s driver (instead of the built-in nv driver) to get multihead support. I’ll try that out later this week.

Well, the hard drive in sonata, my desktop machine at work, is dying a slow death. I saw the writing on the wall a few months ago, and now it’s finally biting the big one. I’m typing on the box now, but it’s slowly getting wonkier and wonkier as it churns out ever more i/o errors, read errors etc.

A new drive is forthcoming, but in the meantime, I’ve managed to back up what’s left of the old drive, so I can restore it onto the new one. And, I’ve found that when it comes to archiving drives with errors, cpio beats tar hands down. I started out doing

cd /filesystem
tar cvplf - . |
ssh other-box "cd /backup/disk; tar xpf -"

But, it dies as soon as it hits a bad spot.

I ended up doing

cd /filesystem
find . -xdev -depth -print |
cpio -o --verbose -H newc |
ssh other-box "cd /backup/disk; cpio -id -H newc"

The -H option is needed to back up files with inode numbers greater than 65535.

Cpio is even more obfuscated than tar WRT command line options, etc., but it seems to do a better job at disaster recovery.

Fun fun…

I’m beginning to think I need to set up a Wiki for this stuff.. but later.

Trying to get the sshdfilter stuff up and running on my new Debian box, and of course I didn’t document the process when I did it on 3 previous machines awhile back, so here goes.

1. Install sshdfilter script in /usr/local/sbin
2. Edit /etc/init.d/ssh. Look for two lines that look something like
   

   start-stop-daemon --start [...] /usr/sbin/sshd -- $SSHD_OPTS

   Replace them with

   start-stop-daemon --start --quiet --exec /usr/local/sbin/sshdfilter -- $SSHD_OPTS &

   Don’t forget the trailing ampersand!

3. Create an executable file /usr/local/etc/iptables.sh:
   

   
#!/bin/sh
modprobe ip_tables
iptables -N SSHD
iptables -A INPUT -p tcp -m tcp --dport 22 -j SSHD
exit 0


4. Modify /etc/network/interfaces. Under interface eth0, add the following line:
   

   pre-up /usr/local/etc/iptables.sh

And that should do it.

OK. Documenting this here for the next time I have to do this.

I’m working on setting up a computer that dual-boots into Linux and XP.

Rule 1: Always put Windows on the first primary partition on the drive. Linux can go pretty much anywhere else.

Rule 2: Always install Windows first, then Linux, so the boot loader will get set up properly. I knew this, but chose to do things the other way around anyhow (yep, I’m stupid that way). And of course, the XP install hosed the Linux boot loader, so I had to manually restore it, which was a big pain.

Here’s how I reinstalled the boot loader, for the next time I ignore my own advice…

1. Boot into the Debian netinst CD, or Knoppix, or Tom’s Root Boot, or whatever flavor of standalone Linux you prefer.

   With netinst, you’ll need to walk through the install process until it gets to the disk partitioning part (this ensures that the disk devices are loaded). Then, hit ALT-F2 to get a shell.

2. Create a mount point, say /disk, and mount your root filesystem there. Example: mount /dev/hda5 /disk
3. chroot /disk
4. Mount any additional filesystems you might need, like /boot, etc.
5. grub-install /dev/hda

That’s all I needed to do, but it took several unsuccessful attempts to arrive at this.

References: here and here.

I just wasted an entire day trying to get a new Dell 2007WFP working with my 3-year-old Dell GX270 desktop, which runs Debian. The result: total failure. It works at 1280×1024 (and looks all stretched out), but flatly refuses to work at the monitor’s optimal resolution of 1680×1050.

In the xorg.config file, first I tried just adding a new “Screen” resolution for 1680×1050. This failed with “no such mode” or somesuch. After much head scratching and googling around, I learned that I needed to patch my video BIOS (Intel 810 series) to add the new mode. I did this via a utility called 915resolution. This seems to work.

With 1680×1050 programmed into the BIOS, I then tried several different ModeLine entries in the config file, with varying different modes of failure. At certain settings, X would refuse to use the mode, complaining about “vrefresh out of range” or something. At other settings, when I started X, the monitor would go into power-save mode as if it wasn’t receiving a signal. At other settings, the monitor would display a message stating that the signal was out of range and it couldn’t use it. I fiddled with turning DDC on and off, to no effect. Everything I tried resulted in one of these three failure modes. I’m pretty sure I’ve got good ModeLine numbers, as they match what’s reported by DDC in the X.org log.

I’m pretty much at my wit’s end here, so I’ve given up for now and am back to using my old dual-monitor xinerama setup. Needless to say, I’m not too high on the whole Linux/X desktop scene right now. I’m ready to punt the thing and go to a Mac.

Still playing around with Coppermine, trying to set things up so that Cathy can have a separate login and still have the ability to upload and edit photos in the public albums. First, I tried setting her account up in the registered group. After a bit of fiddling and RTFMing, I was able to get it so that the account could upload to public albums. I had to

1. Remove the disk quota from the registered group (group admin area, change default quota from 1024K to 0)
2. Enable registered group to upload to public albums without admin approval (group admin area)
3. For each album, go to the configuration page (go to album list and click “properties”). In properties, select “Visitors can upload files”

After I did that, I could upload pictures, but once uploaded, I couldn’t do anything further with them (like adding captions etc). So it looks like this isn’t the answer. That leaves me with two options:

1. Add Cathy’s account to the administrators group; or
2. Move all the albums to Cathy’s “personal” album space, so she “owns” them; then she should have access to them and I can access them through my administrator account.

For now, I’m going with option #1 because it’s the easiest.