The end of this blog is nigh. Allow to me explain.
In short, I've decided to consolidate my internet presence down as much as possible. I have 3 or 4 blogs, not to mention a facebook, 4 Myspaces, 4 Twitter accounts, and, it seems, 234,432 websites to maintain. It has come to my attention that, these days, the Internet values quality more than quantity. So to that end, I will be terminating this blog. The information posted will remain, but new tech-related posts will go on to my (ONE!) remaining blog, Scamwagon - which was formally relegated exclusively to political and consumer rants.
Instead of creating separate blogs for each of the crazy interests I have (cars, music, computers, to name a few), you'll be able to find all of my posts on one, single blog site. Wow, look at all the added value already!
I thought I'd follow up my last post on my troubled Terastation. I replaced the power supply, only to find that it still shutdown a few minutes after turning on. I finally determined that this was happening as a result of a corrupt operating system. The Terastation apparently responds to a failed bootup by turning off. I attempted several times to replace the firmware (a great opportunity to try using a telnet enabled firmware), but the device kept shutting down before the firmware update could complete.
After resolving that I didn't care about the data that was on the drives (I had already recovered it, see last post), I figured out an approach that worked. I took each drive and connected to a linux booted computer (I used a Knoppix live CD). Each time, I went into fdisk and observed that there didn't appear to be any partitions. Regardless, I created a partition (the type doesn't matter), and then deleted it - leaving no partitions again. After completing this for all 4 drives, I reassembled the Terastation and was able to execute the firmware update with no problem.
After the firmware update was complete, there was no data on the drives - but my config info was somehow intact! I was surprised, they must store it in flash or NVRAM. The only thing I had to do was reset the language to english, which involved a lot backflips and screwing around, until I found that article.
So now I have a fully functioning, blank Terastation that is telnet enabled and has the latest firmware! Exciting, now I just need to come up with a cool project for it - or more likely I will just put my data back onto it, as it's a little annoying having my desktop as the server for the house.
On Sunday night, I was doing some video editing for a friend, when I realized that my Terastation (original) was not running. I glanced in my server closet and discovered 4 green HDD lights (all on solid), a diag light (flashing), and no fan or hard drive noise coming from the unit.
I cycled the power and the unit started up again. It worked for a short time (performing an array check) and then would quit and go into the same state again. Each time I powered it up, it lasted between 30 seconds to 3 minutes or so.
I called Buffalo tech support, who graciously offered me assistance (even though this device is sorely out of warranty). The tech recommended I turn it off, hold the "init" button in and power it on, while continuing to hold the init button down for 15 seconds. He recommended I wait until the device powered up and completed the array check, then perform a firmware upgrade. He seemed fairly confident that this would solve my problem, so we hung up.
No sooner did the phone disconnect, then the Terastation shutdown again with a "click". The init button routine seemed to do absolutely nothing. I decided I was on my own, and I attempted a firmware upgrade.
The firmware upgrade (available from Buffalo Technology's website) ran, and seemed to complete successfully. However, when I booted the Terastation back up after the upgrade, it came up in "EM mode" (Buffalo's name for the recovery firmware, stored on flash, that only allows you to upgrade/write the firmware to the hard disks). This was probably what the tech was trying to get me into when we did the INIT button thing... I again attempted the firmware upgrade. This time, while writing the firmware, I shuttered as I heard:
* click *
... Sure enough, the device had shut off, and it would no longer boot at all (not even to EM mode!) My Terastation was a brick. I searched around online and found that it's possible to recover the device with some soldering of a connector that I didn't have, a JTAG cable that I didn't have, and a firmware upgrade. At this point, I was panicking a little, as a backup of the device was another thing I didn't have (yes, yes, shame on me.)
Recovering the Data
My next feat was to get the data off the drives, which were in RAID 5 configuration, without the Terastation. I found several articles online, in particular this one from UFSexplorer . Basically, you can hook the 4 PATA drives up to a computer running Windows, and use UFSexplorer to build the array virtually, and copy the data off of it. Here's the basic procedure I followed.
Obviously, do all of this at you're own risk, but presuming you're doing this because you have no backup, you're probably into risk taking anyway. What you'll need:
-We'll be running a total of 5 drives (the 4 Terastation drives, plus one Windows system drive), so you'll need a full tower PC case, with a hard drive running Windows.
-It should have at least 4 free power connectors and 2 IDE controllers on board. You can improvise, such as with an extra IDE controller card if you have one, and a 'Y' adapter drive power cable, or an external drive power supply. You'll probably need to disconnect any DVD drives to free up some power and data connectors.
-An external PATA IDE->USB converter (for the 5th drive, which will actually be drive #4 on the Terastation). Again, you can improvise with things like an extra IDE controller card, if you have one.
1. Assuming you have the Terastation "original", you'll have to pretty much completely disassemble it to get to the drives.. This involves the removal the outer case (many screws), a metal guard (many screws), the system board (many screws), one more small metal guard (2 screws), and finally, the drive cage (2 screws). The drives are numbered 4,3,2,1 from left (system board side) to right. You'll probably need to remove drive #4 completely, as you'll be connecting that to your USB hard drive adapter.
2. Set the jumpers on all of drives, and connect them to power.
Note: you may be able to get away with powering the drive array with the Terastation power supply, but in my case, I later found out that the power supply was bad, which was responsible for this whole mess. It's advisable to use as little from the Terastation as possible unless you are certain you know what's wrong with it).
After a lot of futzing around to get the drives all powered and connected, and changing jumper settings on all the drives, I finally got them all to be recognized by the computer. Here's a full description of the setup, by drive:
Windows system drive: -Primary onboard IDE controller, jumpered as master.
Terastation drive #1: -Primary onboard IDE controller, jumpered as slave
Terastation drive #2: -Secondary onboard IDE controller, jumpered as master
Terastation drive #3: -Secondary onboard IDE controller, jumpered as slave
Terastation drive #4: -USB IDE adapter, jumpered as master or cable select
Get your Windows PC all booted up after verifying the drives are all visible to the BIOS setup. They won't show up in Windows as drive letters, because they don't have recognizable file systems. Don't panic.
3. Now you'll need to download (and eventually buy, for about $75 USD) UFS Explorer Professional Recovery. It's worth the money. One major issue this gets around is that the RAID was originally built on a PPC, big-endian-based system, and you are now trying to access it on a PC, which is little-endian. If you don't know what that means, just continue.
4. Follow the instructions on the UFS Explorer site, specific to the Terastation. Here's the basic steps:
-When you launch the program, you should see all 4 drives with a mess of partitions. Some will be "XFS", and some will be "Unknown".
You'll most likely need to need to use the "Hex View" function to establish which drive is which. This is documented on the UFS Explorer site, as well. View each of the large partitions (232GB on mine) and pay attention to the very first 4 bytes or so - they should help you identify what part of the RAID 5 you're looking at. If you connected the drives as I did above, your array order should be 2 (Superblock), 3 (iNode block), 1 (parity), 4 (parity).
-Click the "RAID Builder button"
-Choose the partition option, not the disk option (I forget the exact wording)
-Go through and add all 4 of the really big partitions to the right side.
-Use the "move to top" and "move to bottom" buttons to get them in the correct order
-Click Ok and you should see a new partition on the bottom of the list. Right click and choose "explore". If you see all of your folders on the right, you can now copy your data somewhere (i.e. to a network or USB drive). If you don't see all of the folders, or you get "error in filesystem", you probably have your drives in the wrong order. Right click to close the partition and try again in a different order.
After almost 2 days of copying, I have all of my data back, and I am now building a FreeNAS-based NAS, using a dual eSATA enclosure and an older Dell. Terastations are great, but I'm too strapped for cash to replace it now. Maybe someday I'll resurrect it by replacing the power supply, but right now I just don't have the time. The other thing I plan to do, ASAP, is setup Jungledisk to sync the NAS files with an offsite backup.
A friend recently asked me for some tips on network cabling tools. After realizing I have a lot to say on this subject, I figured it was as good a reason as any to do a post on it. Here's some tips from a guy who has done more cable-crimping than his pay scale warrants:
-Don't skimp when buying crimpers (i especially like the ones that "click" to let you know that they are completely crimped)
-Buy the bulk pack. Don't underestimate how many terminators you'll go through if you don't do cables often.
-Print out (in color) the specification for the T568B standard as small as possible, and STICK IT somewhere on your crimping tool. Then you'll always have it!
Color Code Guide Note: Others will argue that the T568A standard should be used. In my experience, the T568A standard is usually only involved when making a crossover cable. It's a matter of preference, but be consistent.
-A simple network cable tester is REALLY nice to have. It can save you a lot of frustration, especially if you are doing a job (whole house, building, etc.)
So, after a little bit of screwing around, I have gotten my Windows Mobile phone to connect to my home network via a PPTP VPN to my DD-WRT router. My main goal for this was to allow my SIP client (I'm using SJ Phone) to connect to my Asterisk Box behind the firewall.
Here's how I did it!
On DD-WRT router/firewall Go to Services->PPTP Click "enable"
Enter the following: Server IP: 192.168.15.1 (internal IP address of router)
Client IP(s): 192.168.15.150-160 (a range of internal IP addresses that are unoccupied)
CHAP-Secrets: myusername * mypassword * (Asterisks and spaces are required as shown)
Hit apply-settings, and save.
On the Windows Mobile Phone Go to Start->Settings->Connections, Click the advanced tab Click select networks Set to the following: "Programs that automatically connect to the Internet should connect using: 'My ISP'" "Programs that automatically connect to a private network should connect using: 'My Work Network'" Hit Ok Click to the Tasks tab Under "My Work Network", click "Edit my VPN servers" Click "New"
Enter the following: Name: "Home VPN" (or whatever you want) Hostname or IP: "blah.dyndns.org" (assuming you have some kind of ddns setup) VPN type: PPTP Click Next
Enter the following: User name: myusername (Or whatever you used above) Password:mypassword (Or whatever you used above. NOTE: this probably won't be remembered by the device anyway) Domain: (Leave Blank)
Click Finish
Tell the phone to connect to the VPN
With your device outside your LAN, activate your VPN connection as follows:
Start->Settings->Connections Under "My Work Network" Click Edit my VPN Servers Click and hold the VPN connection entry Choose "Connect" Enter your username and password (if asked) (leave domain blank again) You should see it connect. If you don't see an error pop up, it worked!
Configure SJPhone Next, configure SJPhone to connect to the internal IP address of the asterisk box: Menu->Options Click the "Profiles" tab Click "new" Profile Name: My asterisk box (rest as defaults) Click the "SIP proxy" tab Proxy domain: 192.168.15.14 (or your asterisk box internal IP) : 5060
Click Ok, and your SIP device should register! If you drop your VPN connection, you may need to manually force SJPhone to reregister the SIP connection before you can make/receive calls again.
The other day, my brother asked me to recover the data from a linux hard drive that would no longer boot for him. He said the superblock was reported as damaged and the machine refused to boot.
I took the hard drive home and put it in a spare machine I had. Presuming the hard drive was damaged, I decided it was best if I didn't try to boot off of it. The more the hard drive is used, the worse the chances of recovery.
The first thing I did was download, burn, and boot from the Ubuntu Rescue Remix live CD. This is basically a stripped version of Ubuntu with only some of the basic tools helpful for performing data recovery and forensic analyses.
I mounted the "victim" drive as follows (after sudo -i to get root access):
# mkdir /mnt/victim_drive
I used fdisk and printed the partition table on the device in order to determine which partition was the one with the data I was after. In this case it was /dev/sda4.
# mount /dev/sda4 /mnt/victim_drive
This operation failed due to the bad superblock. Time to get to work.
I ran fsck.ext3 (my brother told me he had formatted it ext3) on the device:
# fsck.ext3 /dev/sda
Immediately it asked me if I wanted to make changes to a bunch of inodes, and some other stuff that sounded generally scary. At this point, rather than proceed, I hit Ctrl-C and decided to do things the "safe" way. Read on.
The "safe" way of recovering the drive involves working on an image of the damaged disk, rather than the actual one. This has 2 main advantages:
The repairs will be done on a known working device, as opposed to a damaged one that could respond in an undefined way.
Most of all, attempts to repair could ultimately result in even further damage, sealing the fate of the already damaged file system. If you are working on an image instead of the actual drive, you can always go back and try a different approach.
Next, I mounted an alternate location (this could be a network share or another drive) on which I could store the image of the damaged disk. Remember that you'll need at least as much space free as the size of the drive you are working on (actually more):
# smbmount //server/share /mnt/rescue
Then I grabbed an image of the drive using ddrescue (took a while!). ddrescue will automatically try to do low level repairs in order to get a complete image. mmls is part of the sleuth-kit (apt-get install sleuth-kit) - a handy tool to look inside the disk image once it's done.
# ddrescue -r 3 /dev/sda /mnt/rescue/diskimage.dd
# mmls /mnt/image.dd
DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors
This is a list of all the partitions that are in the disk image. Now we can operate on the disk image and try to repair the partition. The target partition is Linux (0x83), starting at sector 63. We need to know the offset in bytes, so we multiply the 512 byte sectors
63 * 512 bytes/sector = 32256 bytes.
Now we can work on that partition. We first setup a loop device with the image file, and then run fsck on it:
# losetup /dev/loop2 fsimage.dd -o 32256
# fsck.ext3 -y /dev/loop2
The -y option is useful when you have a partition with lots of problems - it's better than sitting there and repeatedly answering "yes" to each of the prompts.
With any luck, after this, you now have a clean disk image that is ready to be mounted. Mount it as follows:
# mkdir /mnt/recovered # mount /dev/loop2 /mnt/recovered
In my case, the files were all there, but they had all been dumped into the lost+found directory, and they were listed under directory names of their respective inodes. I was able to quickly locate the files I was looking for using a command such as this:
# cd /mnt/recovered/lost+found
# find | grep home/wmcgrath
If the results had been less successful, I could have gone back to the drawing board. Unmount the image, get rid of the unwanted loop device, and (re)move the image file, such as:
Now you can go back and make a new image as we did in the beginning, and try other approaches. More information is available at the Ubuntu data recovery page
Remember - the best way to avoid losing data is to make regular backups, but if you have to "operate", this is the safest way to do it!
I was psyched for the new Ubuntu 7.10 release, Gutsy Gibbon, but I'm a KDE user and I had a lot of problems upgrading Feisty/Kubuntu to Gutsy. I followed the instructions using AdeptI had some minor successes, but I was unable to get the upgrade, and KDE and Compiz to work in combination. In the end, here's a rough overview of what I wound up doing:
1. Clean install of Gutsy Ubuntu (Gnome)
2. Go into restricted driver manager and enable restricted drivers for nVidia (Compiz worked right off!)
3. Using Synaptic package manager, add the Advanced Desktop Effects Manager (CompizConfig Settings Manager)
4. Now there is a new button "Custom" when you configure your desktop settings
5. Stop to play around with adding desktop effects. Remember to turn your vertical desktop size to 1 and horizontal to 4. Otherwise you will have a plane instead of a cube.
6. Back to Synaptic. Add "kubuntu-desktop". Wait a long time for lots of packages to download/install
7. Select KDE as the default environment
8. Wait some more. Reboot the machine when everything is finished.
9. The machine will come up in KDM. Go over to the little picture of a drop down, click, and select Session Type->"KDE", instead of "Default (previous)"
10. Log in and wait for desktop to come up
11. Compiz will be disabled. Don't panic: go to the KDE menu and select Settings->GL Desktop
12. Enable GL Desktop
13. Configure Compiz as desired using Settings->Advance Desktop Effets Settings
I won't bother going into any more details for now. Feel free to post comments if you have any questions
