R.I.P. All my pictures … almost

I’ve kept all of my digital photos on an external hard drive. And that hard drive crashed – Linux just wouldn’t mount it. I let out an audible gasp after realizing the drive won’t come back.

Luckily I had dejadup running and I was able to restore the photos. Phew. But I didn’t backup everything on that drive and so I was wondering if I could get back all the other miscellaneous files I had on there. I don’t know what they were but now I was curious.

The error message in /var/log/syslog was:

Jul 17 23:56:33 tower kernel: [ 10.374777] sd 12:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 17 23:56:33 tower kernel: [ 10.374781] sd 12:0:0:0: [sdf] tag#0 Sense Key : Medium Error [current]
Jul 17 23:56:33 tower kernel: [ 10.374784] sd 12:0:0:0: [sdf] tag#0 Add. Sense: Unrecovered read error
Jul 17 23:56:33 tower kernel: [ 10.374788] sd 12:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 00 00 00 38 00 00 08 00
Jul 17 23:56:33 tower kernel: [ 10.374791] blk_update_request: critical medium error, dev sdf, sector 56 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jul 17 23:56:33 tower kernel: [ 13.730496] sd 12:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 17 23:56:33 tower kernel: [ 13.730500] sd 12:0:0:0: [sdf] tag#0 Sense Key : Medium Error [current]
Jul 17 23:56:33 tower kernel: [ 13.730503] sd 12:0:0:0: [sdf] tag#0 Add. Sense: Unrecovered read error
Jul 17 23:56:33 tower kernel: [ 13.730506] sd 12:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 00 00 00 38 00 00 01 00
Jul 17 23:56:33 tower kernel: [ 13.730509] blk_update_request: critical medium error, dev sdf, sector 56 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jul 17 23:56:33 tower kernel: [ 13.730574] Buffer I/O error on dev sdf, logical block 56, async page read
Jul 17 23:56:33 tower kernel: [ 17.086792] sd 12:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 17 23:56:33 tower kernel: [ 17.086796] sd 12:0:0:0: [sdf] tag#0 Sense Key : Medium Error [current]
Jul 17 23:56:33 tower kernel: [ 17.086798] sd 12:0:0:0: [sdf] tag#0 Add. Sense: Unrecovered read error
Jul 17 23:56:33 tower kernel: [ 17.086801] sd 12:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 00 00 00 39 00 00 07 00
Jul 17 23:56:33 tower kernel: [ 17.086805] blk_update_request: critical medium error, dev sdf, sector 57 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 0
Jul 17 23:56:33 tower kernel: [ 17.086867] Buffer I/O error on dev sdf, logical block 57, async page read
Jul 17 23:56:33 tower kernel: [ 17.086883] Buffer I/O error on dev sdf, logical block 58, async page read
Jul 17 23:56:33 tower kernel: [ 17.086899] Buffer I/O error on dev sdf, logical block 59, async page read
Jul 17 23:56:33 tower kernel: [ 17.086914] Buffer I/O error on dev sdf, logical block 60, async page read
Jul 17 23:56:33 tower kernel: [ 17.086929] Buffer I/O error on dev sdf, logical block 61, async page read
Jul 17 23:56:33 tower kernel: [ 17.086945] Buffer I/O error on dev sdf, logical block 62, async page read
Jul 17 23:56:33 tower kernel: [ 17.086960] Buffer I/O error on dev sdf, logical block 63, async page read
Jul 17 23:56:33 tower kernel: [ 20.485982] sd 12:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 17 23:56:33 tower kernel: [ 20.485986] sd 12:0:0:0: [sdf] tag#0 Sense Key : Medium Error [current]
Jul 17 23:56:33 tower kernel: [ 20.485989] sd 12:0:0:0: [sdf] tag#0 Add. Sense: Unrecovered read error
Jul 17 23:56:33 tower kernel: [ 20.485992] sd 12:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 00 00 00 3f 00 00 08 00
Jul 17 23:56:33 tower kernel: [ 20.485996] blk_update_request: critical medium error, dev sdf, sector 63 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
Jul 17 23:56:33 tower kernel: [ 23.842040] sd 12:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 17 23:56:33 tower kernel: [ 23.842043] sd 12:0:0:0: [sdf] tag#0 Sense Key : Medium Error [current]
Jul 17 23:56:33 tower kernel: [ 23.842046] sd 12:0:0:0: [sdf] tag#0 Add. Sense: Unrecovered read error
Jul 17 23:56:33 tower kernel: [ 23.842049] sd 12:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 00 00 00 3f 00 00 02 00
Jul 17 23:56:33 tower kernel: [ 23.842052] blk_update_request: critical medium error, dev sdf, sector 63 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jul 17 23:56:33 tower kernel: [ 23.842117] Buffer I/O error on dev sdf1, logical block 0, async page read
Jul 17 23:56:33 tower kernel: [ 27.241768] sd 12:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 17 23:56:33 tower kernel: [ 27.241772] sd 12:0:0:0: [sdf] tag#0 Sense Key : Medium Error [current]
Jul 17 23:56:33 tower kernel: [ 27.241775] sd 12:0:0:0: [sdf] tag#0 Add. Sense: Unrecovered read error
Jul 17 23:56:33 tower kernel: [ 27.241778] sd 12:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 f0 00
Jul 17 23:56:33 tower kernel: [ 27.241782] blk_update_request: critical medium error, dev sdf, sector 0 op 0x0:(READ) flags 0x4000 phys_seg 16 prio class 0
Jul 17 23:56:33 tower kernel: [ 30.619864] sd 12:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jul 17 23:56:33 tower kernel: [ 30.619868] sd 12:0:0:0: [sdf] tag#0 Sense Key : Medium Error [current]
Jul 17 23:56:33 tower kernel: [ 30.619871] sd 12:0:0:0: [sdf] tag#0 Add. Sense: Unrecovered read error
Jul 17 23:56:33 tower kernel: [ 30.619874] sd 12:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 00 00 00 3f 00 00 f0 00
Jul 17 23:56:33 tower kernel: [ 30.619878] blk_update_request: critical medium error, dev sdf, sector 63 op 0x0:(READ) flags 0x4000 phys_seg 15 prio class 0

The messages indicate that sectors 56 – 63 were bad but I was hoping the rest of the drive was ok. Since this was an older drive with no SMART capabilities, I couldn’t use any of those diagnostics. Since I couldn’t mount it, I couldn’t run any of the command-line tools. But I did have a lot of other HDD space free and so I attempted to create an image of the disk and repair the image.

After some Googling, I found these two sites:

https://forums.unraid.net/topic/51819-solved-disk-disappeared-then-reappeared-empty-how-i-recovered-my-data-xfs/

https://major.io/2010/12/14/mounting-a-raw-partition-file-made-with-dd-or-dd_rescue-in-linux/

Using a combination of ddrescue, losetup, and xfs_repair, I was able to remount the image. Success!

ddrescue -f -n /dev/sdf /mnt/external_hdd/bad_hdd.img ~/ddrescue.log
sudo losetup –offset 32256 /dev/loop2 /mnt/external_hdd/bad_hdd.img
sudo xfs_repair /dev/loop2
sudo mount -v -t xfs -o ro,loop,offset=32256 /mnt/external_hdd/bad_hdd.img /mnt/img

Update to WidescapeWeather Screenlet

I was looking for desktop widgets for Ubuntu and I came across screenlets.

I didn’t realize it was 8 years old and not maintained at all but I ended up spending some time fiddling around with it and fixing the WidescapeWeather widget.

The reason it wasn’t working was because weather.com changed the URLs for getting the most recent data and so a manually modified the Python script.

Original widget download location: https://www.gnome-look.org/content/show.php/Wide+weather?content=77168

After installing this with Screenlets Manager, edit the script

gedit ~/.screenlets/WidescapeWeather/WidescapeWeatherScreenlet.py

And modify:

data = urlopen('http://xoap.weather.com/weather/local/'+self.ZIP+'?cc=*&dayf=10&prod=xoap&par=1003666583&key=4128909340a9b2fc&unit='+unit + '&link=xoap').read()

to

data = urlopen('http://wxdata.weather.com/wxdata/weather/local/' + self.ZIP + '?cc=*&dayf=10&unit=' + unit).read()

The only tricky thing here is to make 100% sure that you keep the tabs on the modified line.  Python will be upset if the formatting is not correct.

Result:

Screenshot from 2016-07-16 17:22:47

And then after more Googling, I think I should have used Conky.  Oh well.

RIP LinkStation :(

My 250GB Buffalo LinkStation has died.  And I’m kinda sad.  I don’t remember exactly when I purchased this, but the earliest review I can find was from 2006 (http://www.smallnetbuilder.com/nas/nas-reviews/28111), which makes it about 9 years old.

IMG_20151107_172324432.resized

It first started with the dreaded 6 red blink hard drive error.  I took the device apart, placed the hard drive into my Ubuntu box, and used xfs_repair to fix the drive.  It looked like there were some journal and read errors that were fixed.

I was able to browse the file system while the drive was connected to the Ubuntu box so I thought I was in the clear.  But when I reassembled the LinkStation, there was another problem; this time, it was a 4 red blink error.

(Decoding error flashes: http://buffalo.nas-central.org/wiki/Information/LSProLED)

When I looked at the fan, it was not spinning.  I tried a few other PC fans I had lying around, but none of them spun up.  I then dusted off the multimeter and found that there was no more 12v supply going into the fan from the 3-pin header.  I first suspected a blown fuse (http://forum.buffalo.nas-central.org/viewtopic.php?f=39&t=6561) but the multimeter indicated that the fuse was intact and there was 12v coming from the power supply.

At this point, I gave up.  I didn’t search for a schematic to try and isolate where the 12v could be cut off.  Even if I was able to find the faulty component (or maybe a broken trace), I don’t have the tools to rework the board.

It was a nice run.  I’m thinking about keeping the 250GB drive, but if the root cause of all this was in fact some side effect of overheating due to the fan not spinning, I probably shouldn’t trust the integrity of the drive.

Thanks for the 9 year uptime, Mr. Buffalo LinkStation LS-GL.

 

Cyanogenmod

I have a really old Nexus 7 (https://en.wikipedia.org/wiki/Nexus_7_%282012_version%29) and upgrading that to Lollipop basically made it unusable.  It was terribly slow.

I unlocked the bootloader and reflashed with 4.4.4 (https://dl.google.com/dl/android/aosp/nakasi-ktu84p-factory-2c6e4d6f.tgz) and that was much better.

But that’s really no fun so I decided to give CyanogenMode a shot (http://download.cyanogenmod.org/?device=grouper&type=).  It was a bit overwhelming at first to work out that:

  • nakasi is the codename for that tablet at Google while grouper is the codename for the CM team
  • CM 11.0 is based on Android 4.4.4
  • M vs N vs stable vs snapshot … (http://wiki.cyanogenmod.org/w/Release_Versioning)

I finally settled on this http://download.cyanogenmod.org/get/jenkins/90453/cm-11-20141112-SNAPSHOT-M12-grouper.zip but that’s no fun either so I built it from scratch.  https://wiki.cyanogenmod.org/w/Build_for_grouper

Everything is all documented and there are even steps to make sure the GMS apps are installed so the resultant build is very much usable.

That was fun.