Category Archives: Linux

Raspi Bplus-1

Fixing bash Shellshock vulnerability on Raspberry Pi

The recent bash vulnerability, a.k.a. “Shellshock”, is pretty bad, considering it might actually have been around for a very long time, maybe even dating back to the predecessor of bash. Not good.

So what about Raspberry Pi’s?
Are they vulnerable?

Turns out they are, but there is already a fix available for them and patching a Raspi is very simple. Whether your actual Raspi is vulnerable depends on what distribution you are using, and how recently you upgraded the software in it.
The Raspi used below is running IPE-R1, which is a blackout-proof version of Raspian.

First let’s find out what bash version we have:

root@raspi-2:~# dpkg -s bash | grep Version
Version: 4.2+dfsg-0.1

You can also run this little script to determine whether your Raspi is vulnerable to Shellshock

root@raspi-2:~# env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' bash --norc -c ':' 2>/dev/null;

Let’s fix this. Just refresh the repos and upgrade bash (the patched version is available in the main repos).

root@raspi-2:~# apt-get update && apt-get install --only-upgrade bash
Get:1 wheezy Release.gpg [490 B]
Get:2 wheezy Release.gpg [490 B]
Get:3 wheezy Release [10.2 kB]
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
The following packages will be upgraded:
1 upgraded, 0 newly installed, 0 to remove and 54 not upgraded.
Need to get 1,443 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 wheezy/main bash armhf 4.2+dfsg-0.1+deb7u3 [1,443 kB]
Fetched 1,443 kB in 1s (1,386 kB/s)
(Reading database ... 29754 files and directories currently installed.)
Preparing to replace bash 4.2+dfsg-0.1 (using .../bash_4.2+dfsg-0.1+deb7u3_armhf.deb) ...
Unpacking replacement bash ...
Processing triggers for man-db ...
Setting up bash (4.2+dfsg-0.1+deb7u3) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide /usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode

The installed version of bash is now +deb7u3

root@raspi-2:~# dpkg -s bash | grep Version
Version: 4.2+dfsg-0.1+deb7u3

The short test script above also returns nothing:

root@raspi-2:~# env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' bash --norc -c ':' 2>/dev/null;

You could of course also just do an “apt-get upgrade” to upgrade all packages on your Raspi, would take a bit longer but will work just as well.
Also, if you are not logged in as root you need to do a “sudo apt-get update”, of course.

How to get OS X 10.9 Mavericks and Arduino IDE to play nicely with each other

Apple tried to be smart with OS X Mavericks, developing their own FTDI drivers. Just too bad they don’t seem to work.

I have been getting nothing but “avrdude: stk500_recv(): programmer is not responding” errors when trying to upload sketches to various Arduino compatible boards.
In the end, the only thing that worked was programming the boards using a dedicated programmer (in my case an USBasp).

Some digging around forums and Apple’s support site, the following steps has solved the issue on all the OS X machines where I have tried it. In short, you need to replace Apple’s drivers with the ones from FTDI.

  1. Open a terminal
  2. cd /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns
  3. sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled
  4. sudo touch /System/Library/Extensions
  5. Restart computer
  6. Install FTDI’s virtual COM port drivers from In version 2.2.18 this package contains two executable files, I have had success with the one named FTDIUSBSerialDriver_10_4_10_5_10_6_10_7
  7. Restart again (might not be needed, good practise though after installing drivers)

Voila – The Arduino IDE can now upload sketches to all boards I have tried, both with the old/legacy bootloader and Optiboot.

Raspberry Pi won’t boot – only red power light comes on – SD card corrupt? Not so fast…

After having problems with SD cards failing after a few months in a Raspi that was supposed to be always-on, it was time to look for options.

The IPE distribution seemed like a perfect match – it effectively makes the Raspi only use a ramdisk, except possibly during boot. When needed the SD card file system can be made writeable, meaning that apt-get etc can be used as usual to install apps.

This worked great for ca 3 weeks, then this setup ALSO failed, with the same symptoms as before: at boot only the red power light would come on – nothing else. A fresh SD card with a fresh copy of IPE worked fine in the same Raspi hardware, thus not the Raspi itself that had fried (the cabinet where it lives is kind of warm, nothing too crazy though).

Now the weirdness starts for real. The failing SD card works perfectly fine when inserted in both an iMac and a Windows laptop. I spent hours and hours reformatting the card with various low-level tools, then writing the standard Raspian image to the card. Just for reference I did the same to a third SD card too, that card was identical to the failing one.

Still the same issue: that one card would still prevent the Raspi from booting.

The card in question is a Kingston 16 GB microSDHC card marked SDC4/16GB 081. It comes with an adapter that makes it usable also in large SD card connectors.

Photo on 11-09-14 at 06.52 #2

Finally, and I of course should have thought of this sooner, I tried swapping the two different microSD to SD adaptors. And of course… the solution was simple. It was not the SD card that had failed, it was the adapter. For some reason (heat? just poor quality?) the adapter had a small crack in its plastic housing, and as a result most likely some poor connection inside, between the microSD card itself and the surrounding adapter. When inserted into a proper computer, there was probably enough pressure on the adapter to squeeze it against the actual microSD card, while the SD card holder on the Raspi is kind of flimsy, and did not provide the needed pressure. When using a working adapter all three microSD cards work flawlessly in the Raspi.

Note to self: Use full sized SD cards in Rasperry Pis….





ReadyNAS RN312 + 8GB RAM = FAIL

My RN312 has worked flawlessly since the upgrade from the standard 2 GB RAM to 4 GB ditto. I would however like to run some memory intensive applications on the NAS, so an upgrade to 8GB would be nice. Turns out this is not as easy – might not even be possible.

I have tried both a Kingston KVR1333D3S9/8G, and a DDR3 1600 from my iMac – no luck. Guess the RN312 just does not support 8GB – too bad.

By the way, the 4GB SODIMM that does work is a Hynix HMT351S6BFR8C.

Burning ISOs to USB sticks on Mac / OS X

For some reason i cannot get the easy-to-use tools out there for burning ISOs to work… Command line to the rescue:

First, make sure Homebrew is installed. It is strictly not needed for the burning-to-thumb-drive process, but will enable the progress indicators, which are quite nice to have for long running tasks. Now install Pipe Viewer from Homebrew:

$ brew install pv

Now we need to figure out the device name of our USB drive. In a terminal window (you are using iTerm2 – right? Infinitely better than OS X built in Terminal app):

$ diskutil list

 0: GUID_partition_scheme *251.0 GB disk0
 1: EFI EFI 209.7 MB disk0s1
 2: Apple_HFS Macintosh HD 250.1 GB disk0s2
 3: Apple_Boot Recovery HD 650.0 MB disk0s3
 0: GUID_partition_scheme *320.1 GB disk1
 1: EFI EFI 209.7 MB disk1s1
 2: Apple_HFS SSD backup 180.0 GB disk1s2
 3: Apple_HFS Temp 139.6 GB disk1s3
 0: GUID_partition_scheme *1.0 TB disk2
 1: EFI EFI 209.7 MB disk2s1
 2: Apple_HFS Macken_Ext Backup 999.9 GB disk2s2
 0: FDisk_partition_scheme *8.0 GB disk3
 1: DOS_FAT_32 WHEEZY 8.0 GB disk3s1

/dev/disk3 is the USB thumb drive. I previously had another Wheezy image on it, thus its name.

Now unmount it:

$ diskutil unmountDisk /dev/disk3
Unmount of all volumes on disk3 was successful

Nice. Now let’s write the ISO to the drive:

$ pv -petr ~/Desktop/debian-7.2.0-amd64-DVD-1.iso | sudo dd of=/dev/disk3 bs=128k
0:00:38 [4.94MiB/s] [====>                  ] 3% ETA 0:16:55

Now let’s wait. Looks like it will take approximately another 17 minutes..

When done, just eject the thumb drive as usual, remove it and you have a bootable Debian install drive. Mission accomplished.

Netgear RN312 firmware upgrade 6.0.8 to 6.1.2

RN312 6_1_2 available

Seems Netgear just released firmware version 6.1.2 for those products that support the new UI (I believe UltraNAS and other non-Intel based devices does not get the benefits of the new version 6 and above firmware – or maybe they have reconsidered – not sure).

Updating is always a bit scary when you have a smoothly running system, but after reading the release notes they mainly covered more high end devices (as compared to the RN312 that I have), so why not..

I believe the upgrade went well, all the applications I have installed myself (CrashPlan, Monitorix etc) seems to be work ok.

RN312 6_1_2 installed.png




Moving CrashPlan cache and log directories to new locations

As discussed in a previous post, the ReadyNAS might run out of disk space on the 4 GB root partition if you install software other than that provided by NetGear.

In my case it was CrashPlan’s cache and log files that were filling up the root partition, with warning emails every 10 minutes that 81% of the root partition was used, 82%… 83%…, so they needed a new home. Turns out it is not too hard:

ssh into the NAS, then su to become root. Stop CrashPlan (if it is running):

root@RN312:/home/admin# service crashplan stop
 Stopping CrashPlan Engine ... OK

Make a copy of CrashPlan’s configuration file, in case something goes wrong:

root@RN312:/home/admin# cp /usr/local/crashplan/conf/my.service.xml /usr/local/crashplan/conf/my.service.xml.orig

Take a look at CrashPlan’s cache directory:

root@RN312:/home/admin# ls -lah /usr/local/crashplan/cache/
 total 40M
 drwxr-sr-x 1 root staff  106 Sep 25 03:00 .
 drwxr-sr-x 1 root staff  258 Sep 25 21:31 ..
 drwxr-sr-x 1 root staff  170 Sep 25 21:31 42
 -rw-r--r-- 1 root staff 8.4K Sep 25 21:31 cpft1_42
 -rw-r--r-- 1 root staff 1.9K Sep 25 21:31 cpft1_42i
 -rw-r--r-- 1 root staff 2.1K Sep 25 21:31 cpft1_42x
 -rw-r--r-- 1 root staff  23M Sep 25 21:31 cpgft1
 -rw-r--r-- 1 root staff 8.8M Sep 25 21:31 cpgft1i
 -rw-r--r-- 1 root staff 7.9M Sep 25 21:31 cpgft1x
 -rw-r--r-- 1 root staff  986 Sep 25 03:02 cpss1

Create cache directory in new location:

root@RN312:/home/admin# mkdir /home/admin/from_root/crashplan/cache

Change the config file to point to the new location (using your favourite editor, vim used here):

root@RN312:/home/admin# vim /usr/local/crashplan/conf/my.service.xml


(Adjust as needed if you have selected some other place for the CrashPlan files.)

Now move the cache files:

root@RN312:/home/admin# mv /usr/local/crashplan/cache/* /home/admin/from_root/crashplan/cache/

Time to move CrashPlan’s log files. They are originally stored in /usr/local/crashplan/log/, let’s move them to /home/admin/from_root/crashplan/log.

root@RN312:/home/admin# ls -lah /usr/local/crashplan/log/
 total 111M
 drwxrwxrwx 1 root staff  346 Sep 23 04:41 .
 drwxr-sr-x 1 root staff  258 Sep 25 21:31 ..
 -rw-r--r-- 1 root root   33K Sep 25 21:31 app.log
 -rw-r--r-- 1 root root   23M Sep 25 21:31 backup_files.log.0
 -rw-r--r-- 1 root root   26M Jul 12 19:50 backup_files.log.1
 -rw-rw-rw- 1 root root     0 Aug 15 15:21 engine_error.log
 -rw-r--r-- 1 root root  6.4K Sep 25 21:31 engine_output.log
 -rw-r--r-- 1 root root  180K Sep 25 21:31 history.log.0
 -rw-r--r-- 1 root root  501K Sep 17 13:47 history.log.1
 -rw-r--r-- 1 root root  501K Aug 25 08:10 history.log.2
 -rw-rw-rw- 1 root root     0 Aug 15 15:24 restore_files.log.0
 -rw-r--r-- 1 root root   13M Sep 25 21:31 service.log.0
 -rw-r--r-- 1 root root   26M Sep 23 04:41 service.log.1
 -rw-r--r-- 1 root root   26M Sep 17 14:35 service.log.2
root@RN312:/home/admin# mkdir /home/admin/from_root/crashplan/log

Find the fileHandler tags (there are 4 of them dealing with log files), modify them so they point to the new log directory. So, once again edit /usr/local/crashplan/conf/my.service.xml.orig, part of mine looks like this after moving the log files. Change the paths as neeed for your choice of new directories:

     <fileHandler append="true" count="2" level="ALL" limit="26214400" pattern="/home/admin/from_root/crashplan/log/service.log"/>
     <fileHandler append="true" count="10" level="ALL" limit="512000" pattern="/home/admin/from_root/crashplan/log/history.log"/>

Start CrashPlan again:

root@RN312:/home/admin# service crashplan start
 Stopping CrashPlan Engine ... OK

And finally check free disk space on /:

root@RN312:/usr/local/crashplan/log# df -h
 Filesystem      Size  Used Avail Use% Mounted on
 rootfs          4.0G  1.7G  1.8G  49% /
 tmpfs            10M  4.0K   10M   1% /dev
 /dev/md0        4.0G  1.7G  1.8G  49% /
 tmpfs           2.0G     0  2.0G   0% /dev/shm
 tmpfs           2.0G  5.8M  2.0G   1% /run
 tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
 tmpfs           2.0G     0  2.0G   0% /media
 /dev/md127      2.8T  1.1T  1.7T  39% /data
 /dev/md127      2.8T  1.1T  1.7T  39% /home
 /dev/md127      2.8T  1.1T  1.7T  39% /apps

49% – nice!