Thankful for backups

I've a read a saying that is quite true

There are two types of people using computers; those that back up regularly and those who will

It's a fact of life that hard drives fail. Not a matter of if, but rather when. After my second hard drive failure - I'm a little slow, it took 2 - many years ago, I became a person that makes disaster recovery discs, and regular file backups. Once a method is developed and put in action, hard drive failures are easier to deal with.

Having suffered 2 hard drive failures in 2 weeks allowed me to put my backup practices to the test. These were not freak hard drive failures, nor anything to make me need to investigate other system components/applications for the cause. The hard drives were each at least 3 years old, and consider the usage I got from them to be more than adequate.

Regular file and data backups are easy enough to do. I tend to burn everything to 2 sets of optical discs, and use an online service (DropBox) as well. Our entire MythTV movie collection is backed up to DVDs. Glancing at the media case, I'd estimate +/- 150 DVDs with ~4 movies each. Granted we still own the original DVDs and could always just re-rip and re-encode, but that's months and months worth of work. 100 high quality Taiyo Yuden DVDs cost less than $30. Well worth the money.

The part of recovering from a hard drive failure that takes the most amount of time and causes the highest level of frustration is the operating system install itself. We've put oodles of time finding and implementing tweaks, customizing settings, hunting down specific applications to do specific tasks. When starting over from scratch we're lucky to remember everything we had done before. More times than not, that website with the fantastic howto is now gone. Archive.org for some reason doesn't have this website in their database. If we even remembered to book mark it in the first place.

This is why I make disaster recovery sets for all of our systems. There's no special tools, applications, nor proprietary formats. If you have the Slackware installation CD/DVD you have everything you need. Best of all, the archive can be read by any Linux Distro, and even Windows if the need arises.

Here's a quick example of how I make our disaster recovery images. Which just recently have been verified to work.

Boot Slackware installation CD/DVD
If you don't already own Slackware, buy it, download it, or make your own.
Press enter to boot the default kernel, log in as root. You have to create an archive, and save it some where. Another hard drive, cifs/nfs share, ftp ... I export my archives to our file server through cifs. To bring up networking type dhcpcd eth0, then verify you have an IP with ifconfig.

Mount remote share and local hard drive
I'm using cifs

mount -o user=user,pass=supersecret //fileserver/backups /var/mount

Mount the partition you want backed up

mount /dev/sda1 /mnt

Create disaster recovery archive
There are other compression schemes besides gzip that result in smaller file sizes. Size saved : time taken does not equal out to be worth while unless you really need to save space. A full Slackware install of ~4.6GiB compresses to ~1.7GiB with gzip, and ~1.2GiB with xz and p7zip. I have timed our backups to be ~15minutes with gzip, and 45+minutes with p7zip and xz.

Create the actual backup archive

cd /mnt
tar -czvpf /var/mount/system.backup.tar.gz \
--exclude=proc --exclude=lost+found --exclude=sys .

If you are going to create your archive on the same drive, be sure to add --exclude=system.backup.tar.gz or tar will attempt to add your backup archive to your backup archive.

And that's it. Your complete installation is now saved in a single portable archive. Don't forget to burn it to disc for keeping.

Restore from disaster recovery archive
I create a DVD that includes the backup archive, and parts of Slackware to make a single bootable disc. This is quite easy to do.
Make a directory ~/slackboot. In that directory place the entire contents of isolinux/ and kernels/ from you favorite Slackware mirror (or copy them from your DVD) along with your backup archive.

isolinux/
kernels/
system.backup.tar.gz

Make the iso image by following the README.TXT inside isolinux/ and boot from it.

Press enter to boot the default kernel, log in as root. Partition and format your new hard drive, and mount it mount /dev/sda1 /mnt Mount the DVD containing your backup mount /dev/sr0 /var/mount
Restore your system

tar -xzvpf /var/mount/backup.tar.gz -C /mnt

Create missing directories

mkdir /mnt/{proc,sys}

(lost+found was created when you formated)
Don't forget to reinstall lilo.

lilo -b /dev/sda -C /mnt/etc/lilo.conf

Of course, adjust to your system.

You can also chroot into your system to adjust things - like /etc/fstab if you change file systems or mount points.

mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
chroot /mnt

Wireless, not that hard

In the past I've had numerous issues with wireless devices and Linux. Either the chipset was not supported, flaky encryption support, weak connections, dropped connections. It was so bad that I completely banned wireless from our home for a number of years. I was under the (wrong) assumption that this is one aspect of Linux that just did not work.

Not too long ago I was given a couple of old Laptops as payment for some work I had done. These varied in speed from 1.7ghz with 1gig ram, to a PIII 600 with 384 ram. Wireless options included an Ornico wireless B card, Broadcom BCM 4309, and a Linksys PCMCIA wireless G adapter. I already had an rt73usb wireless stick that had worked pretty well on unencrypted networks in the past.

Previously I've gone as far as attempting to use one of the User Friendly Distros and acclaimed Network Manager. Each which failed just the same as Slackware's wireless tools and/or Wicd. Looks as though things have changed today - for the most part.

The good - My rt73usb stick now works out of the box, nothing special to do at all. Plug it in, and everything is auto loaded. Fire up Wicd, and WPA/WPA2 worked without a hitch. Good speed, no drops over a decent period of time. The same with the Ornico wireless B, though this chipset did require me to put the agrere firmware in /lib/firmware. The Ornico only supported WPA encryption. Not really bothered by that. If a person can hack WPA, WPA2 is not that much more difficult.

The not so bad - The Linksys PCMCIA (InProComm) adapter is not supported by Linux. Ndiswrapper to the rescue. This is simple to do. Install ndiswrapper, ndiswrapper -i $driver.inf, modprobe ndiswrapper. Done. Just a couple of extra steps, but everything worked, and works well.

The bad - The BCM 4309 complained about needing a firmware, and to use the fw-cutter tools. So I did. Chipset was found and loaded, Wicd, nor any of the wireless tools could find any wireless networks. Ndiswrapper to the rescue again? Well, sort of. Using ndiswrapper I was able to find and connect to our network, but this still had issues. Either poor connection strength - all other wireless devices report between 80-99% strength the BCM 4309 reports between 50-75%. Connection drops, and OH the battery drain. Kernel 2.6.32.4 has better support for the 4309 (did not need fw-cutter), but the result was the same.

So, currently wireless in Linux works, and actually works to the point I'd call flawless. As long as you use a quality, well supported chipset. After searching for solutions for my Broadcom wireless, it seems as though these chipsets produce problems for most people. Though there appears one or two versions that work marginally well. Personally I'll avoid or replace anything Broadcom for now.

CPU Upgrades

My girlfriend's PC is long overdue for an upgrade. She's been running an Intel PDC 2140 (1.6ghz dual core) for just about two years now. While I've enjoyed a nice Intel e8400 (3.0ghz core2duo). Microcenter is running a combo deal on the newer AMD Athlon II X4 620 (2.6ghz quad core) and Gigabyte motherboards. I opted for the GA-MA785gm-US2H originally $99, combo deal was $49.99 out the door. The AMD Athlon II x4 620 was $95. I figured the X4 620 would give her a nice upgrade.

Motherboard/CPU swaps are always straight forward. Unplug everything, remove motherboard, install motherboard, reconnect all the wires, power on, and check the BIOS. This one was no different than any other. This Gigabyte BIOS is not much different than my Gigabyte P45 board. CPU had a temp of 32 at idle. Ran memtest86 a few times, then checked the temp again, 40 degrees. Appears the heat sink and fan are working correctly.

Rebooted into Slackware64-current just to make sure everything was recognized and still worked. Besides needing to run alsaconfig again, everything was perfect, a little too perfect. This new setup was quite fast. Without benchmarks, I'd say it feels just as peppy, if not more, than my e8400.

My girlfriend does little with her PC besides browse some websites, a bit of word processing, jam some tunes, and play a few games. No video/audio editing nor encoding, no compiling, not really anything that needs this much power. This is when I decided to see which setup would be faster for me.

Using the built in timer in my head (read non sophisticated benchmarks) I tested which one was quicker at doing some of the tasks I normally do. Using handbrake, the x4 620 was of course much faster (2 cores vs 4), compiling larger programs were quicker on the AMD as well. But what really surprised me, was the fact that poorly threaded, and single threaded programs showed virtually no difference between the two CPUs. I expected the e8400 to walk all over the x4 620. It didn't. The e8400 was faster with oggenc and xvid encoding, not enough to forget about the extra 2 cores on the 620.

In the end, my girlfriend ended up with the e8400 and (IMO) stellar Gigabyte P45 motherboard, while I got a new AMD Athlon II X4 620, and the (IMO) entry level MA785GM motherboard. Not that I was taking full advantage of everything the P45 had to offer. We both received worthwhile upgrades. This should hold me down for a little while longer while i7/i5 prices drop. Or who knows, maybe I'll get another AMD.

X-Mass gift from the Slackware Store

Every year for the holiday's my Girlfriend likes to get me something Slackware. Last year she bought me the fabulous heavy weight black Slackware tee-shirt. This year I was surprised with a DVD subscription.

Recently there was a post at Linux Questions about the Slackware store. A few people complained their shipment was slow to arrive, and one poster made bold complaints of the store being a rip off. This prompted me to ask my Girlfriend how long - from payment to delivery - did it take. She said it was less than a week. Last year, I know it took only took 3 days for the tee-shirt to arrive. Maybe those that had issues are non US residents. Out of country shipping can be slow most of the time.

My only complaint about the DVD is that it is in a some what cheap jewel case. The inserts are nicely printed on good quality paper, and the DVD is of course pressed, not some DIY burn job. I swapped the inserts over to a thicker jewel case I had laying around.

It makes us feel warm on the inside, not only to give gifts to each other, but to also support a product like Slackware that we use day in and day out. Next I'll have to get one of those mouse pads.

File compresion tests

Slackware had a recent update to pkgtools which adds support for other compression formats. The standard tgz (tar.gzip), tbz (tar.bzip2), tlz (tar.lzma), and txz (tar.xz). lzma and xz in Slackware current can be handled by a new package called ---xz. I wanted to see if using the different compression algorithms made any difference. For this test, I'm using a folder which contains 9,264 files, and 806 sub folders. Uncompressed size is 25112411 (~23.9MB). I wanted to test the file size, compression time, and decompression time. Using gzip, bzip2, lzma, xz, and P-7zip. 7zip is another lzma compression utility I already had on my system.

Commands used -

time tar -cf - fluxbox-themes | gzip -9 >fluxbox-themes.tar.gz
time tar -cf - fluxbox-themes | bzip2 -9 >fluxbox-themes.tar.bz2
time tar -cf - fluxbox-themes | lzma -9 >fluxbox-themes.tar.lzma
time tar -cf - fluxbox-themes | lzma -5 >fluxbox-themes-5.tar.lzma
time tar -cf - fluxbox-themes | xz -9 >fluxbox-themes.tar.xz
time tar -cf - fluxbox-themes | xz -5 >fluxbox-themes-5.tar.xz
time tar -cf - fluxbox-themes | 7z a -si -mx=9 fluxbox-themes.tar.7z
time tar -cf - fluxbox-themes | 7z a -si -mx=5 fluxbox-themes-5.tar.7z

All of the tools except 7zip follow the same option structure. This is something that's nice about xz compared to 7zip. 7zip also prints out some junk while compressing P-7zip 4.58 beta Copyright (c) 1999-2008 Igor Pavlov 2008-05-05 p7
zip Version 4.58 (locale=en_US,Utf16=on,HugeFiles=on,1 CPU)
Creating archive fluxbox-themes.tar.7z

Nothing horrible, but it is nice to have lzma compression tools that follows the other standards. There are other lzma Linux based compression tools besides the 3 here. How ever they are reported to not be stable, quite slow, or the compression isn't uniform. On to the test results. Ordered by compressed size.

Tool	Time to compress	Compressed size	Time to decompress
7z -mx=9	real 0m30.865s user 0m27.943s sys 0m0.967s	7,388,688	real 0m10.011s user 0m1.461s sys 0m1.210s
lzma -9	real 0m28.085s user 0m25.833s sys 0m1.178s	7,388,924	real 0m12.952s user 0m1.452s sys 0m1.354s
xz -9	real 0m28.184s user 0m25.904s sys 0m1.106s	7,390,384	real 0m10.748s user 0m1.462s sys 0m1.281s
7z -mx=5	real 0m24.188s user 0m21.998s sys 0m0.714s	7,427,311	real 0m11.924s user 0m1.514s sys 0m1.216s
lzma -5	real 0m23.208s user 0m19.469s sys 0m0.739s	7,507,885	real 0m10.020s user 0m1.425s sys 0m1.317s
xz -5	real 0m21.079s user 0m19.559s sys 0m0.674s	7,511,708	real 0m10.614s user 0m1.457s sys 0m1.265s
bzip2 -9	real 0m15.024s user 0m14.212s sys 0m0.325s	8,807,485	real 0m13.550s user 0m3.767s sys 0m1.355s
gzip -9	real 0m5.258s user 0m4.729s sys 0m0.357s	9,456,727	real 0m6.796s user 0m0.467s sys 0m0.867s

7zip, lzma and xz where all just about exactly the same size. lzma being the slower of the three to decompress, and 7zip being the slowest to compress. Gzip, of course, being the speed king here. It's at least 4x faster than any of the lzma compression tools and ~3x as fast as bzip2. Given the size of bzip2, the amount of time it takes to compress and decompress compared to the other formats, it just doesn't seem like a valid choice here. Where bzip2 comes in, is that 7zip, lzma, and xz are not that popular, and support may or may not be available with your tools.

On my system (Slackware with KDE 4.2.2) Ark and xarchiver could open 7zip files, but did not know how to handle lzma nor xz files. The standard tar command tar xf $file.tar.$ did not work either.

In my personal opinion - bzip2 loses here. I don't see much difference between xz and lzma, other than 2 extra characters at the end. 7zip, lzma, and xz where all virtually identical in compression time, decompression time, and compressed size. 7zip does not support the same common command line switches that all of the other tools do. There's also warnings about using 7zip to backup Linux file systems It (7zip) does not correctly follow symlinks, for keep permissions. You could, in theory, tar the directory first then pipe it into 7zip. Plus 7zip supports multiple cores.

I will still continue to use the standard gzip for the bulk majority of my archiving. If I was running a mirror, or another bandwidth hogging service, you can believe I would quickly switch over to one of the lzma compression tools. For my home use, archiving space isn't limited enough to compensate for the 3-6x time increase to archive and 2x time increase to decompress.

New myth frontend

Built a new myth front end today with these components -

• Asus P5KPL-CM $50
• Evga GeForce 9400 GT $50 (before $20 MIR)
• Kingston 1gig DDR2 $10
• Intel Celeron 2100 $50
• Seagate 120gig hard drive $?
• Antec NSK2480 Case $100

I love this case. It is a tad bit large, but looks right at home under our TV. Came with a 380 watt power suply, two large 120 mm fans (with speed control). Chose the Asus board because it was in stock, has 6 audio plugs instead of the 3 that normally come on the G31 based boards. The evga card supports VDPAU, plus all of our other cards are evga models - might as well stick with what works. Picked the Celeron because it was the cheapest Intel CPU Microcenter had in stock. Had the Seagate laying around collecting dust. $260 for a complete system, not too bad.

The Celeron feels like a Celeron (duh). Even though it is a 2.0ghz dual core, I'd say my PDC 2140 (1.6 Pentium dual core) has more power. No test results to prove this, it just feels that way. The PDC 2140 is in an identical setup, except with a Biostar G31 motherboard. Both systems are running Slackware©-current with the packages I've recompiled.

If you notice, I did not purchase an Optical drive. I have plenty of ATAPI drives already. What I neglected to do was purchase another SATA hard drive. All of my spare hard drives are IDE. The Asus board has 4 SATA ports, and one IDE 2 channel port. The case is setup in a way that it wouldn't be practical to use an IDE hard drive and optical drive with one IDE cable. I'll purchase a new SATA drive latter and just clone the installed drive over to it.

This brings me to installing Slackware© without an optical drive. No sweat, there's a USB boot image. dd it to my 1 gig usb drive, boot the PC, Slackware© setup is running. Yeah! No network! Damn! The Asus board is using the Attansic L1 network chip. Well there is a kernel module for it, but no eth0 devise. I fooled around with attempting to make my own USB image on a 1 gig and 2 gig usb stick. Nothing I did worked. Followed alienbob's scripts from here ->usbinstall Didn't work either. My 2 gig usb stick is only 1.9 gig. While searching for solutions I found this application UNetbootin. Easy to use, and it actually worked! Stuck my usb stick back in the PC. I was presented with an option to chose my kernel, then install went on it's ..... until

Until I was presented to select the source medium. Crossing my fingers I let the installer search for the medium on its own. Nope. Just switched VT's and mounted the drive to /mnt/tmp. Installation completed without any hiccups I like installing from a usb stick. It's faster than using a DVD, and almost as fast as an nfs install.

Now I have a myth frontend running without issues, and got to do away with the tower sitting next to the TV.

Playing with MythTV

I've always wanted to check out MythTV. Never had a PVR type capture card before. A couple of old DC30's from my wedding videos days, but never a PVR 150 or similar. Ended up getting some extra money the other day, and decided to pick an HVR1600.

There is not a proper kernel module for the 1600 (yet). Since I'm using Slackware with KDE 4.2, that means I'm also using qt-4. Myth stable needs qt-3. Not a problem getting the v4l drivers from git. Not a problem getting mythtv from svn. Everything even compiled cleanly.

There's a bug with the data base and qt-4.5. A bug report was filed at trolltech, mythtv, and kde. Kde has a patch for their qt-copy release of qt, and myth patched the main data base file, but not any of the plugins for dbcheck.cpp. Then those on the mailing list claim it's a charset issue with mysql. It's not. Simply applying the same patch to each plugin fixes the issue.

while (thequery != "")

{

- query.exec(thequery);

-

- if (query.lastError().type() != QSqlError::None)

+ if (!query.exec(thequery) &&

+ (query.lastError().type() != QSqlError::NoError))

That's the same patch that was applied to mythtv's dbcheck.cpp, and also need's to be applied to at least 7 plugins. Mytharchive, mythflix, mythgallery, mythgame, mythmusic, mythnews, and mythweather.

I can understand myth not patching the mythplugins. After all, this is stated as being a qt error, and the qt patch is available from kde.

I'm truly surprised mythtv is as stable as it is being an svn version.

More on mythtv latter.