Saturday, December 19, 2015

Repairing a Moenstone Composite Granite Sink

A few years ago we remodeled our kitchen and went with an undermount Moenstone sink.

This Thanksgiving I noticed a hairline crack in the bottom. We called Moen and they were willing to give us money or a new sink as part of the warranty (which is great!), but the sink is undermounted. We'd probably need to remove the entire countertop to put a new one in, and Moen no longer makes them.

Our choices were either to repair it, install a drop in sink, or maybe find another undermount sink with a similar profile. A new undermount probaby requires taking off the countertop and recutting.  A drop-in requires recutting the counter.  Ugh!

So... I researched how to repair composite granite sinks.  I didn't find a whole lot of information. Some people suggested epoxy.

We are one day (2015-12-19)  into our repair, still waiting for the glue to set, but I wanted to document my process. The foundation for our repair is a Simpson Strong-Tie product I found for repairing cracks in cement, CRACK-PAC. It has the viscosity of room temperature syrup, which I thought was ideal for trying to work into a hairline crack.

Here are materials & tools I used:
You will only use a small amount of the CRACK-PAC, so you might scout out ahead of time for cracks in your driveway to fill when you are done.  The epoxy has about 1 hour of working time.  It will get hot as it cures, which will be noticeable if you leave it in the tube.
  • Clean the crack as best you can. Hopefully you caught it early enough it doesn't have a lot of goop in it.  Use hydrogen peroxide and/or the alcohol to try to clean out the crack.  Use the alcohol last as it evaporates better than water.  DO NOT USE SOLVENTS.  As best I can tell, the sink is a mixture of acrylic resin and granite.  ACETONE EATS ACRYLIC!  TAP plastics even cautions against isopropyl and acrylic, but I didn't think it would harm it for a short application. Moen cautions "DO NOT USE: Abrasive cleansers or materials; abrasive scrub pads; alkali cleaners such as ammonia; concentrated solutions of chemical descaling agents; lacquer thinner; steel wool or soap filled steel wool scrub pads; undiluted bleach; drain unblocking chemicals that recommend filling the sink with water. Do not pour paint or paint cleaning materials in sink"
  • Dry the sink.  Use the hair dryer and/or the 500 watt light.
  • Once the sink is super dry, mask the crack with the tape, leaving about 1/2" on either side of the crack.  The masking tape will make a shallow channel that helps keep the epoxy in place as you work it in.
  • Mix the CRACK-PAC according to Simpson's instructions.  (Our tube leaked a little around the valve even with the rubber cap, so be careful.)
  • Using the caulking gun, apply some CRACK-PAC to the length of the crack
  • Work the glue into the crack as best you can with the putty knife -- observe under the sink to see if any is leaking through (you put down a towel, right?)
    • You can also try to suck some glue down through with the vacuum.  Note: This may get glue into your vacuum!
    • I did this step for about 15 minutes -- just scraping over the crack with the knife trying to push the glue into the crack.  
    • I was not able to see it leaking through the entire crack -- only in the middle.
  • Once done, pull up the tape and wipe up the excess glue with your dry cotton rags.
  • Now, go fill in cracks in your driveway.
  • As a backup measure, we also used the masonry epoxy.  I used about 1/3rd of each jar to epoxy the crack from the back side.  It isn't pretty but may help.
  • Now wait.  CRACK-PAC suggests 24 hours.  Since it changes color in a couple days more than that, you might want to wait longer.  (I'm not sure how long we'll wait.)
  • An additional step we did was to support the garbage disposal with blocks of wood from below.  We hope that this extra support from the bottom would help keep the crack from spreading further.
  • Turn the water off at the sink for at least 24 hours.  Don't put anything in the sink until you are sure the epoxy has fully cured.
I'll post periodic updates on our fix... please let me know if this was helpful!



  • 2015-12-20 - We've turned the water back on again and are allowing the sink to get wet.  Right now we are avoiding putting anything else in the sink.  When the CRACK-PAC dried I noticed a raised ridge along the length of the crack.  I'm guessing this means the epoxy expands a slight amount, which is actually ideal.  The slight ridge doesn't bother me and has the advantage that I can track any future crack growth.

Tuesday, January 7, 2014

Keeping a cd history in the Bash shell

Often I find myself wanting to cd back to a directory -- but never the exact previous one I was already in (i.e., cd -)!  It is usually the directory I was in just a few of cd's ago.

I was considering writing a bash shell function that more or less aliased cd to pushd with some cleanup to keep the stack only about 10 levels deep. But I found someone else (Petar Marinov) beat me to this back in 2004:

Add this code to your login shell and the last 10 directories you were in will be saved in a stack. Listing the previous directories is as easy as 'cd --' and going to a previous one is simple: 'cd -#' where # is the number in the history:

[centos6:/tmp/ssh-ZhqNv10269]$ cd /tmp
[centos6:/tmp]$ cd cow
[centos6:/tmp/cow]$ cd fox
[centos6:/tmp/cow/fox]$ cd fish
[centos6:/tmp/cow/fox/fish]$ cd elephant/
[centos6:/tmp/cow/fox/fish/elephant]$ cd rhino/
[centos6:/tmp/cow/fox/fish/elephant/rhino]$ cd zebra/
[centos6:/tmp/cow/fox/fish/elephant/rhino/zebra]$ cd --
 0  /tmp/cow/fox/fish/elephant/rhino/zebra
 1  /tmp/cow/fox/fish/elephant/rhino
 2  /tmp/cow/fox/fish/elephant
 3  /tmp/cow/fox/fish
 4  /tmp/cow/fox
 5  /tmp/cow
 6  /tmp
 7  /tmp/ssh-ZhqNv10269
[centos6:/tmp/cow/fox/fish/elephant/rhino/zebra]$ cd -3
[centos6:/tmp/cow/fox/fish]$ cd -7
[centos6:/tmp/ssh-ZhqNv10269]$ cd -1

If you incorporate this code, know that the conditional around the bind is broken, so just remove the conditional if you want the bind.

Wednesday, November 20, 2013

Finally solved my Wii-U eShop error issue!

We've been trying to purchase the Pikmin 3 DLC for the last week or so. Everytime we get through about half way through the eShop purchase, the eShop app gets an error code (useless!) and exits.  Sometimes we get further than other times, and once it fails, it seems to fail faster.

Using the Nintendo Wii-U eShop seems to be a common problem found on the Nintendo forums. Originally it was an issue with the Wifi reception. But there still seems to be a few cases here and there, and we use a wired connection. I was stumped. It didn't seem to matter what time of day either.

So today I was looking at my firewall logs and noticed:
[4582372.494624] iptables drop ratelimit: 
IN=eth0 OUT= MAC=... SRC= DST=... LEN=93 TOS=0x00 PREC=0x20 
TTL=59 ID=27348 DF PROTO=TCP SPT=443 DPT=4040 WINDOW=18666 RES=0x00 ACK PSH URGP=0 
A lot of those.  That's weird.  That IP is an akamai address.  And I seem to get a lot from them from akamai's port 443 to a random port on my system.

Akamai says:
Our firewall has detected that Akamai-controlled IP addresses are attempting to access our IP address via a number of different ports. This seems to be an attack. What is going on? 

The messages you see indicate that users behind your firewall are running the Akamai NetSession Interface. The Akamai NetSession Interface is a download manager client that is used on behalf of an Akamai customer to download software or other digital content. The Akamai NetSession Interface uses both TCP and UDP based protocols to download content and facilitate connectivity through network devices such as proxies, firewalls & NAT (network address translation) devices.
Huh! I wonder if Nintendo is using a similar download manager protocol in the eShop for the interface.  Or maybe I have downloads downloading in the background that is triggering a firewall rule.

Now about that rule -- the rule I have is that if you send me enough packets that I decide to drop, I blacklist the IP:
-A INPUT_FORWARD_FW -i eth0 -j DROP -m recent --set --name badguys     
 Combined with the following to just drop all of their packets:
-A INPUT_FORWARD_FW -i eth0 -m recent --rttl --name badguys --update --seconds 60 -j DROP        
Once I removed the first rule, I was immediately able to complete an eShop transaction.

So I wonder how many people out there who are having trouble with the eShop are having trouble from smart firewall routers (mine is Linux) that blacklist IP addresses if they try to contact blocked ports too often.

...And tomorrow we shall try out the new Pikmin levels!  :)

Saturday, October 5, 2013

Western Digital Green Drives and Linux - They're dying!

The last time I swapped the drives out in my home built NAS, I bought Western Digital Green drives.  They sounded great!  Low power, low heat, low noise...

Unfortunately, they appear to not have been built for this particular application.  They auto park and the timer is set too low for Linux filesystems.  (I believe the default may be 8 seconds!

My drives began to give me trouble (thankfully) even before the warranty ran out.  I found the load cycle count on my drive to be extremely high - 10's or 100's of thousands.  This is way beyond the expected count.

Here's how to query for it:

# smartctl -A /dev/sdX | grep ^193
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       XXXXXXX

Luckily there is a solution -- run this tool to either turn off the feature, or set the timeout much higher:

Make sure you follow the instructions closely -- you must power cycle the drives!

Now every time I boot, I run this script as part of the boot, just in case I forget if I put a new WD Green in.

for dev in /dev/sd[a-z]
   if ! hdparm -i $dev | grep Model=.*SSD
       if hdparm -i $dev | grep -q Model=WDC
           echo Disabling western digital 8sec park
           /opt/idle3-tools/sbin/idle3ctl -d $dev
       echo Setting timeout for non SSD drive
       hdparm -S 251 $dev

(WD has been mostly sending me back WD Red Drives, which is great as I believe they are marketed for NAS.)

SATA errors on Linux with Samsung SSD 840 Series with Asus M2N-E

This problem had been driving me crazy for weeks.  I run a home linux server (currently Fedora Core 18) as a NAS and various other services.   Ever since I upgraded the OS disks to SSD I began getting SATA errors in my kernel logs:

Jul 31 00:02:26 kernel: [20859.208310] ata3:EH in SWNCQ mode,QC:qc_active 0x7E sactive 0x7E
Jul 31 00:02:26 kernel: [20859.208371] ata3: SWNCQ:qc_active 0x3E defer_bits 0x40 last_issue_tag 0x5
Jul 31 00:02:26 kernel: [20859.208482] ata3: ATA_REG 0x41 ERR_REG 0x84
Jul 31 00:02:26 kernel: [20859.208533] ata3: tag : dhfis dmafis sdbfis sactive
Jul 31 00:02:26 kernel: [20859.208585] ata3: tag 0x1: 1 0 0 1
Jul 31 00:02:26 kernel: [20859.208636] ata3: tag 0x2: 1 0 0 1
Jul 31 00:02:26 kernel: [20859.208697] ata3: tag 0x3: 1 0 0 1
Jul 31 00:02:26 kernel: [20859.208748] ata3: tag 0x4: 1 0 0 1
Jul 31 00:02:26 kernel: [20859.208800] ata3: tag 0x5: 0 0 0 1
Jul 31 00:02:26 kernel: [20859.208860] ata3.00: exception Emask 0x1 SAct 0x7e SErr 0x0 action 0x6 frozen
Jul 31 00:02:26 kernel: [20859.208914] ata3.00: Ata error. fis:0x21
Jul 31 00:02:26 kernel: [20859.208967] ata3.00: failed command: READ FPDMA QUEUED
Jul 31 00:02:26 kernel: [20859.209049] ata3.00: cmd 60/08:08:e8:23:bb/00:00:04:00:00/40 tag 1 ncq 4096 in
Jul 31 00:02:26 kernel: [20859.209251] ata3.00: status: { DRDY ERR }
Jul 31 00:02:26 kernel: [20859.209303] ata3.00: error: { ICRC ABRT }
Jul 31 00:02:26 kernel: [20859.209354] ata3.00: failed command: READ FPDMA QUEUED
Jul 31 00:02:26 kernel: [20859.209410] ata3.00: cmd 60/08:10:d8:26:bb/00:00:04:00:00/40 tag 2 ncq 4096 in
Jul 31 00:02:26 kernel: [20859.209605] ata3.00: status: { DRDY ERR }
Jul 31 00:02:26 kernel: [20859.209675] ata3.00: error: { ICRC ABRT }
Jul 31 00:02:26 kernel: [20859.209734] ata3.00: failed command: READ FPDMA QUEUED

Since the spinning SATA disks I replaced also gave me errors (I assumed they were dying...), it was a bit of a mystery.  Is the SATA controller dying?  The errors did seem to correlate with greater disk utilization.

I swapped the cables.  I swapped the port.  For a day I convinced myself the problem was associated with the port.  I forced the kernel to throttle the SATA to 1.5Gb/s (libata.force=1.5G).  I tried libata.noacpi=1.

Finally I found the answer: libata.noncq

It's even a bit obvious now in the log messages: SWNCQ

Apparently newer drives let the kernel offload the write ordering to the drives.  After all, the drive knows its physical properties better than the kernel:
I did file a bug:

Now that I've added libata.nonncq to the kernel command line, my errors have gone away.  I'll try removing it someday when I upgrade the motherboard or OS.  I suspect it is the sata controller on the motherboard.

When to ask for help when stuck on a technical problem

I thought this blog post by +Matthew Ringel was a concise and useful summary of how (and when) to ask for help when stuck on a technical problem:
I often find coworkers skipping step #1: working at the problem a little longer and documenting/recording/reviewing what you've already tried.

When I do step #1 I often solve the problem myself.  I might be in the middle of an email explaining what the problem is.  I owe it to them to explain what I've tried, what results I got, etc.  Most of the time the solution then presents itself!  I then just delete the email draft and keep plugging away.

But then sometimes I wait too long for step #3 - going and asking for help.

And then sometimes, I just need a rubber duck:

Removing Embedded JPGs from Nikon NEF Files with Exiftool

I've been migrating away from Capture NX2 to Lightroom for editing my raw NEF's.  But I'm not quite ready to convert completely from NEF to DNG (Digital Negatives.)  I still might want to edit the photo in Capture - the control points are just too useful.  One tempting advantage of DNG is that they are reportedly a little smaller than NEF.

Why are the DNGs smaller?  I believe it is due to the NEF's embedded jpgs.  But Lightroom doesn't really need the jpeg rendering that is stored in the NEF and I could always recreate them later.  So how can I drop them?


+Jeffrey Friedl's blog post at put me on the right track, but I think his information is out of date now.  I found that my NEF had three jpgs:
  • JpgFromRaw (Full Size!)
  • OtherImage (Fairly large!)
  • PreviewImage (Thumbnail-ish)
Let's see how big the are in an NEF that is 44133771 bytes:

$ exiftool -list D8H_2754_20131001_183719.NEF  | egrep Binary\ data
Jpg From Raw                    : (Binary data 3492514 bytes, use -b option to extract)
Other Image                     : (Binary data 858341 bytes, use -b option to extract)
Preview Image                   : (Binary data 99052 bytes, use -b option to extract)&nbsp

I first attempted to just replace the JpgFromRaw with the PreviewImage.  That worked, but then I would be just duplicating the jpg -- but here is how you do it:

$ exiftool -v -JpgFromRaw\<PreviewImage 2754_20131001_183719.NEF
$ exiftool -v -OtherImage\<PreviewImage 2754_20131001_183719.NEF

So how do I just delete them?  Just delete the tags:

$ exiftool -JpgFromRaw= -OtherImage= -overwrite_original_in_place -P 2754_20131001_183719.NEF

(I'm leaving the smallest (~100KB) PreviewImage)

I ran this on a folder of about 11GB of NEFs and when done, the folder was 9.1GB.  That's 17% smaller!

I'm going to limit it to this folder for now, but will expand this to other parts of my archives as I gain more confidence that I really don't need the embedded jpgs.

Update:  This requires exiftool 9.03 -> Topic: "Otherimage" in NEFs of D800