Restoring a Time Machine backup from a Drobo Mini

Monday, June 30, 2014 at 11:26 AM

Time Machine is great, for the most part.  You turn it on and it keeps stuff backed-up.  The full system restoration part?  Not so easy... at least for my Macbook Pro. 

tl;dr = USB 2.0 cable ftw


Here's what I tried and the outcomes:

Thunderbolt:  Nope.  When you boot up in recovery mode (Command-R), it won't see the Drobo Mini.  

USB 3.0:  Nope, it only partially works.  I could get the recovery process to 4% or 5% and then it would hang indefinitely.  How do you know if you're using USB 3.0?  The inside of the connector will be blue, and the Drobo-side of the cable connector will have a hump.  

USB 2.0/1.0: Works great.  Yes, it's 2014, but who cares?  When it comes to a full system restore, reliability trumps performance every time.  I was able to get a full system restore with just one try using an old USB cable.


8GB DDR3 DIMMs on an Intel x58 Motherboard? Yep!

Sunday, March 9, 2014 at 11:11 AM
After the great RAM fiasco of 2014, I decided to test all of my RAM - even the extra sticks sitting in the drawer. 

One of my test systems is a Gigabyte GA-EX58-UD5 motherboard.  My understanding is that the x58 chipset supports up to 6x4GB DDR3 memory sticks, for a total of 24GB RAM.

Without thinking, I popped in a pair of 8GB DIMMs to test.  Lo and behold, the system found the RAM and it tested just fine!  Unfortunately, this motherboard still seems to have a "maximum" limit of 24GB total system memory.  Still nice to know that there's a little more flexibility in memory selection on that platform.  At least in this case, yes, the x58 chipset is capable of addressing 8GB DIMMs.  

Memory Errors in Memtest86+ and MemTest86 with SMP enabled

Tuesday, March 4, 2014 at 2:34 PM
Blogging because someone out there is probably banging their heads against the wall just like I did today.  I've had some "interesting" stability problems on my main desktop, an Asus P9X79 Deluxe motherboard, Intel i7-4930k CPU, and lots of g.skill 4GB sticks (32gb total).

I've had memory go bad on me before, so I figured that would be a good place to start.  I checked the basics (timing, voltage, etc.) and they were all configured properly in the BIOS. 

I had a few copies (and various versions) of Memtest86+ and MemTest86 burned to USB sticks.  I can't remember which one I started with, but both of them started spraying errors after a few tests.  I went down to a single memory stick and still had the errors.  I swapped the stick around with other sticks.  Still no luck.  All 8 sticks were erroring out.  At this point I was pretty concerned because that could mean I had motherboard or CPU problems. 

I quickly grabbed new/current versions of both utilities and tried them out.   One of them ran overnight without any issues, and the other failed as soon as I got to test 3... very perplexing.  I fiddled with timing, with ram slots, and still couldn't figure it out - although I did start seeing a pattern.  The test(s) that passed were all single-CPU.  The tests that failed were all SMP tests.  

After a little research, I ran across this gem of information.  Essentially, there are some motherboard+cpu combinations out there that exhibit CPU register corruption when used with certain versions of Memtest.  This is the reason why the single CPU tests ran overnight just fine.

With the stability problems, I wasn't happy with only testing a single CPU (in case my problem was  CPU-related).  The recommendation is to use SMP with Round Robin.
 "the work-around implemented was to change the default CPU selection mode to round robin. In this mode only one CPU is used at a time, but after each test the CPU in use is rotated. So all CPUs will still get used, but only after a longer period of time."

I'm feeling a little better about my system now, at least as far as RAM is concerned.  I have a round robin test running now and will let that go for another 24 hours... but so far so good.    

Adventures in the Home Lab: Tracking a Missing WiFi Device (iPad)

Tuesday, February 18, 2014 at 10:13 PM
My 7yr old has been pretty bummed lately.  He lost his iPad after our last trip to grandma's house.  It's been about a month or so and we still haven't found it.  It bugged me enough to do something about it today.  I offered the kids $10 if they could find the iPad.  Nope, that didn't do it.  Time to move up the stack. 

I logged into my Palo Alto Networks firewall and checked the object I had created for this iPad.  With that I had the IP address and MAC address.  Out of curiosity, I checked the traffic log to see when it was last online.  Lo-and-behold, the thing is online...today...right now!




At this point, I'm pretty stoked.  This means the iPad is still in the house somewhere!  (and super-impressed that it's still checking-in on wifi after weeks of being missing).  Now, to find it.

I fired up Backtrack Linux with with an Alfa USB 802.11b/g adapter - but it couldn't see the iPad's MAC address.  The wireless controller reported that the iPad was connected to an AP using 802.11a/5ghz.  Unfortunately, the Alfa USB adapter only supports 802.11b/g.   

I shut down the 5Ghz radios on the APs, which forced the iPad to connect to the b/g radio instead.  Now the Alfa wifi adapter could see the iPad's wireless MAC address!  From here, it was a game of hide-and-seek.  I started upstairs and worked my way around the house, waving the wifi adapter around while watching the "power levels" reported by airmon-ng.  I eventually worked my way to the basement where I found stronger power levels.  After a loop around the basement, I came to a point where the power levels were screaming at me.  Sure enough, the iPad was right there, hiding in plain sight.

Time to put "find my iphone" on this iPad so we don't have to play this game again.  Maybe I'll setup triangulation on the wifi APs too.  :)

Line Rate | Powered by Blogger | Entries (RSS) | Comments (RSS) | Designed by MB Web Design | XML Coded By Cahayabiru.com