Brian's Blog

I recently finished Knights of the Old Republic 2. It was pretty much more of the same from the first one but since first one was so darn good that makes the second one good also. The only complaint I have is the super lame ending. I hate it when I play a game and you finally overcome that big bad guy at the end and it gives you a crappy ending sequence. Once you kill the bad guy at the end of KOTOR2 you essentially hop into your ship, fly off into the sunset, and then the credits roll. :/ What the heck is that?! To bad the thing you remember most about a game is the end of it.

Either way, there were several hours of enjoyment out of the game and it did have a good story line. Now it's off to Thief 3 (Deadly Shadows). I hope that one has a good ending. I know the first two were incredible games with memorable endings.

Whew, it was a pain but I finally got the drive imaged. Even though I marked the blocks as bad partimage still failed due to bad blocks. I thought partimage was intelligent and read the file system data so that it only backed up the blocks in use by the file system, but apparently not in this case. There probably is a really good reason that I don't understand since I'm not a file system expert.

Anyway, I finally got it to work with dd. I just marked the bad blocks like mentioned in this previous post then followed the steps I gave here to zero out the free space and make the image. The only thing I did different was I piped it through split to divide the image into manageable hunks that can fit on a FAT32 partition or onto a DVD-R. Oddly enough, prior to marking the blocks as bad dd complained about finding bad blocks. But, after marking them as bad dd didn't complain at all. This is the command I ultimately used:

# dd if=/dev/hda2 conv=sync,noerror bs=64K | gzip -c | split -b 2000m - hda2.img.gz.

This produced a 3 files named hda2.img.gz.aa, hda2.img.gz.ab, and hda2.img.gz.ac with the total being just over 4GB when added together. The actual data was about 7GB on this partition so zeroing out the free space really did help cut down the image size, considering that the partition is about 19GB in size.

I haven't tested it yet, but I figure I can get the image back using something like:

# cat hda2.img.gz.* | guzip -c | dd of=/dev/hda2 conv=sync,noerror bs=64K

So, why did I take all this effort to make an image rather than using something like tar? Well, no real reason other than a utility like partimage should be able to work around an issue like this. This is a drive that is brand new, and sometimes a new drive has errors. A couple of bad sectors are OK as long as the file system knows about it and does not use them. If I want to backup a drive like this using a program like partimage then I should be able to. Actually, the odd thing is, I would have never known the bad blocks existed if I didn't try using partimage. reiserfsck --check never found a single problem.

Sure I could have used tar, but then I wouldn't have learned how to use common Linux tools to do the same job!

Well, it seems my problems getting an image of the drive was a problem with the drive itself not the applications I was using the make the image. As I've said before, Partimage just would bomb out at the same point each time. I tried the dd procedure mentioned in my previous post and that barked about problems at about the same location in the imaging process as partimage did. That being said I figured all I had to do was scan the drive for bad blocks and mark them as such. Now, for some odd reason, in reiserfs you have to do this manually instead of just letting fsck take care of it for you with the -c switch. I don't know why this is the case but here is what I had to do.

Boot into a live CD like Knoppix and make sure it has the latest reiserfs tools as specified here. Also, I suggest you read the man pages for all the commands here and understand all the options. One mistake with these things can cause data loss.

1. Find out your partitions block size. This is 4096 by default in reiserfs but you can use the debugreiserfs command to find out what it is. It's important for the badblocks command next.

   debugreiserfs <device> | grep -i 'blocksize'
   

2. Run badblocks to scan the drive and store the list of found bad blocks in a file. I'm assuming the blocksize is the default here, if it isn't replace 4096 with the number given by debugreiserfs.

   badblocks -n -b 4096 -o badblocksfile <device>
   

3. Then run reiserfsck to fix the areas where the bad blocks are and mark them to not be used again.

   reiserfsck --fix-fixable --badblocks badblocksfile <device>
   

   Supposedly you can use reiserfstune to just update the bad blocks list without having to run a check and a fix but in may case the bad blocks were already in use in the tree. Reiserfstune made it clear I had to use reiserfsck in the error message.

So, right now I have partimage trying to image the drive. Hopefully with the blocks marked bad it won't trip up anymore.

I just found this article that explains how to use dd to image a hard drive. Being that partimage has some strange issue that I can't seem to work out in imaging my Laptop (and just my laptop it seems) I figure I better have a backup plan. I'm not sure if I'd do this or just tar the drive up. What would the advanage of one be over the other I wonder?

Below is the text of the article by sandip from his blog at Linuxweblog mainly for my notes and just in case the original site would go down for some odd reason.

1. Boot from the live cdrom distribution.
2. Switch to root.
3. Make sure NO partitions are mounted from the source hard drive.
4. Mount the external HD.

   # mount -t vfat /dev/sda1 /mnt/sda1
   

5. Backup the drive.

   # dd if=/dev/hda conv=sync,noerror bs=64K | gzip -c  > /mnt/sda1/hda.img.gz
   

   "dd" is the command to make a bit-by-bit copy of "if=/dev/hda" as the "Input File" to "of=/mnt/sda1/hda.img.gz" as the "Output File". Everything from the partition will go into an "Output File" named "hda.img.gz". "conv=sync,noerror" tells dd that if it can't read a block due to a read error, then it should at least write something to its output of the correct length. Even if your hard disk exhibits no errors, remember that dd will read every single block, including any blocks which the OS avoids using because it has marked them as bad. "bs=64K" is the block size of 64x1024 Bytes. Using this large of block size speeds up the copying process. The output of dd is then piped through gzip to compress it.
6. To restore your system:

     # gzip -x /mnt/sda1/hda.img.gz | dd of=/dev/hda conv=sync,noerror bs=64K
   

7. Store extra information about the drive geometry necessary in order to interpret the partition table stored within the image. The most important of which is the cylinder size.

     # fdisk -l /dev/hda > /mnt/sda1/hda_fdisk.info
   

   Notes:
   
   One of the disadvantages of the dd method over software specifically designed for the job such as Ghost or partimage is that dd will store the entire partition, including blocks not currently used to store files, whereas the likes of Ghost understand the filesystem and don't store these unallocated blocks. The overhead isn't too bad as long as you compress the image and the unallocated blocks have low entropy. In general this will not be the case because the emtpy blocks contain random junk from bygone files. To rectify this, it's best to blank all unused blocks before making the image. After doing that, the unallocated blocks will contain mostly zeros and will therefore compress down to almost nothing.
   
   Mount the partition, then create a file of zeros which fills the entire disk, then delete it again.

   # dd if=/dev/zero of=/tmp/delete.me bs=8M; rm delete.me
   

Backing Up the MBR

# dd if=/dev/hda of=/mnt/sda1/mbr.img bs=512 count=1

This stores the first 512 bytes of the disk (contianing the MBR and the primary partition info - i.e. the first four primary entries) into the file "mbr.img".

To restore (be careful - this could destroy your existing partition table and with it access to all data on the disk):

# dd if=/mnt/sda1/mbr.img of=/dev/hda

If you only want to restore the actual MBR code and not the primary partition table entries, just restore the first 448 bytes of the MBR:

# dd of=/dev/hda if=/mnt/sda1/mbr.img bs=448 count=1.

This quote should be read with things like the Patriot Act in mind. The fathers of our country were truly ahead of their time.

They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.

-- Benjamin Franklin

OK, this is ridiculous. Last week I noticed on Sunny 104.5 (WSNI-FM) out of Philadelphia that they are playing nothing but Christmas songs all day long. WHAT THE HELL! It's not even Thanksgiving yet! Give me a freakin' break. Every year this seems to happen earlier and earlier.

Why do we feel compelled to celebrate Christmas over a month before it actually arrives and even before the preceding holiday comes to pass? Why must stores have ornaments and trees all over them and holiday mood musing on the PA before we even get to Thanksgiving? Only one reason comes to my mind. Marketing. They want to get us all hyped up and ready to buy the next useless little "must have" instead of putting our energy into silly things like time with our loves ones or even to just think about being nice to each other for a change. Why would they want that? There's no profit in it.

Actually, we shouldn't need a special day for being nice to each other but that's a topic for a different rant.

I for one refuse to accept that Christmas is coming until Thanksgiving passes. How about we start to get all hyped up over the 4th of July in the beginning of June? Wait, no point. That's not a money making holiday.

I just added more info to the Slackware Thinkpad article. Specifically I've added more on general power saving and how to automatically hibernate when the battery goes critical. Read and comment if you wish.

Well, all this talk about configuring Slackware 10.2 on my Thinkpad has turned into a few blog entries so far. So I decided to consolidate what I've figured out, as well as what I figure out in the future into an article instead of having it peppered all over my blog.

I know it's a bit Slackware and Thinkpad specific, but the general theory should be universal. Take a look and see what I have so far and let me know what you think.