f-log

Just for my sanity I downloaded the latest Firefox release 36.0b from the nightlies and ...

It still leaks :(

I was really hoping this problem was going to go away on its own.
previously

Here are more tales of computing woe from this Christmas:
A friend got an Apple TV for Xmas and asked me to install it and set it up. The Apple TV is yet another video streaming device for HDMI TVs. Fully compatible with IPhone/Pads with Apple ready to take every penny when you want to buy/rent a movie.

This should have been the simplest setup ever but, Apple deliberately make it more difficult than it has to be.

Step one; get MAC address to add it to the WiFi, nothing on/in the box or device, surely it will be in the settings when we turn it on. Like hell it is!

Step two; turn on the Apple TV. All you have to do is place a compatible Apple device on top of the box and NFC transfers the Apple account and wifi security information. Awesome idea but we got a big fat CONNECTION ERROR.

AGHHHhhh...!! I know you cannot connect, just give me the MAC address and I will allow you to connect!

Not to worry it has a classic ethernet port. Find a cable plug it in and box works fine, but there is a big cable on the floor that a) shouldn't be there and b) is needed elsewhere.

The box is happy we are not. Just go in to the settings and find the elusive WiFi MAC address ... but its NOT there!

Seriously there are no WiFi options in any of the settings! How can this be? It's billed as a wireless device.

Much hunting through the forums and it turns out that the Apple TV hides WiFi settings when an ethernet cable is attached. That's right, some bright spark deliberately added the extra programming work to remove the one piece of information I need, and only when I connect in the only way possible.

Now the box is setup, the ethernet cable can be unplugged and the box restarted all to get to the Wifi settings to get the MAC address, which for all other manufacturers is on the box or the device.

Why lock down the WiFi via MAC filtering? Well its an ADDITIONAL step on top of other security layers and if it is easier to break into a non MAC filtered access point two doors down then that's what the thief/opportunist will do.

And now the thrilling conclusion to "Copying a Hard drive, a perfect storm"

Let me start with stating again the very few humans will ever come across this bit of pain, but if you have an older ASUS motherboard M4N68T-M LE V2 this tale should be read to conclusion.

Now if you remember from last time I had successfully created a Clonezilla live USB stick. Unfortunately that was just pure luck, I went on to try and create a gparted bootable usb key with unetbootin but on booting got
SQUASHFS error

I also tried to build the USB drives with Tuxboot and rufus which each had there own strengths and weaknesses but were really interchangeable for what I was trying to do. For instance Tuxboot looks the same as unetbootin but has a gparted menu entry.

4hrs later and the original flash drive (1GB ocz) still works but all the myriad of others all fail some in different ways than others.
Included in my assortment of old USB drives from various manufacturers are 256MB, 512MB, 1GB, 4GB and my favourite a 4GB micro drive. That's right, a tiny 2"x2.5"x0.5" black box that houses a spinning disk. Back in the olden days it was strongly believed that USB keys could not be used for anything other than occasional access due to the limited RW cycles allowed. Now we know that even with continuous use those numbers of cycles are rarely reached.

Now I had read a few very old posts noting that USB keys are sometimes set with a "DRIVE/DISK" flag that indicates it can be used for booting, but apart from rumours I found no way of accessing this flag. Then I had idea to search for other users of ASUS motherboards/BIOS having similar issues. Rather worryingly the first hit was my exact motherboard and version. There was no solution but it did make me look again at the BIOS settings.

BIOS ASUS motherboard M4N68T-M LE V2 with AMI BIOS

If I look at the working USB stick in the BIOS it reports it as
Flash Drive AU_USB2
and none of the others report "Drive"

Found a few settings in the BIOS under "Advanced" - "USB Configuration"
Legacy USB support was [AUTO] changed to [Enabled]
also the "USB Mass Storage Device Configuration" - "Emulation" type was [Auto]

I tried changing it to
[Floppy] - got a new error "Boot Error" or nothing(HP 4gb only)
[Forced FDD] - HP stick tested worked fine!!! the others still gave boot error
[Hard Disk] - Reported no boot media (micro drive), some of the other usb drives now worked, but previously working ones did not.
[CDROM] - Nothing seemed to work.

Rather bizarrely the USB sticks would not work even with the different emulation types unless I force the boot selector to appear and selected the USB drive.

So I now had the method of booting from USB but just for fun the GParted live cd then failed on default GFX settings.

tried "GParted Live (Safe graphic settings, vga=normal)" from the GParted boot menu, and then set the resolution to 800x600 16 colours VESA and got a garbled X
again with 640x480 16 colour VESA = garbled
1024x768 24 colour ATI no X
switch to second tty and killall xinit
tried VESA with all resolutions and 8 colours, few garbled results and one that looked like it was melting the screen
tried ATI with all resolutions and 8 colours, not even a garbled result
also tried with radeon.modeset=0
radeon.modeset=1
out of luck, so i downloaded the sysresccd ISO that comes with GParted

and same unsupported video mode :(
even parameters doxdetect forcevesa
but I do have an old LCD tv as my monitor maybe it is at fault!

Managed to pinch a standard vga monitor and it worked, then the sysresccd did not have an icon GParted but running it from the command line worked and ...
in less than 2 mins the partition was resized. re-setup the BIOS to boot from the new SSD and finally a new 120GB drive working in place of my old 40GB.

I hate to think how many hours this "simple" task took, but next time I will be prepared!

I had a 40GB SDD as my main drive after a 60GB SSD failed miserably. Having a smaller drive had its advantages, I could do a complete backup to USB key.

Of course over time 40GB became a little bit small. I only started to run out of space when doing many Firefox builds, trying to resolve my ongoing issue. So I got a nice new 120GB Intel SSD for Xmas and installed it. Great time to make a backup before installing the new drive and hoovering the case fans(urck!)

BIOS found the new drive no problem, all I had to do was copy everything over...

Now this is where things start to go all pear shaped. Not to worry, lots of people were exclaiming how easy it was, there is even a live CD based GUI tool...

Clonezilla, installed it to a neglected 1GB usb key via unetbootin. Booted, followed all the clonezilla instructions, checked again and again I was copying the small drive to the big and selected local drive copy then accepted all the defaults (there were big warnings that these should not be changed) and let it run.

Shutdown, physically swapped drives, booted and got
GRUB

hmmmm, not good.

Removed all the drives except the new one and booting got
error: file '/grub/i386-pc/normal.mod' not found.
grub rescue>

and nothing seemed to work(should have been a matter of TAB selecting the defaults).

rebooted to Clonezilla after putting the drives back
exited to shell when offered and ran
sudo -s
fdisk /dev/sda

made sure it said
Disk /dev/sda:40.0 GB

then
fdisk /dev/sdb

made sure it said
Disk /dev/sdb:120.0 GB

and I typed
dd if=/dev/sda of=/dev/sdb

and then I found
http://unix.stackexchange.com/questions/144172/full-dd-copy-from-hdd-to-hdd

which states cat is a better option
date;time cat /dev/sda > /dev/sdb
date;
just shows the date and time and then executes the next command

time
will 'time' the following command
cat /dev/sda
will stream each byte of /dev/sda (remember all block devices are files in Linux)
> /dev/sdb
will take that stream and send it to the /dev/sdb block device.

in total it took just over 5 minutes. I removed the old drive and set the new one in its place...

and it worked, perfectly. Except maybe one minor problem, the partition table copied from the old drive was reporting a drive capacity 40GB not 120GB.

Created a gparted bootable usb key and although it stuck at
modprobe: module swap not found in modules.dep
and then errored for ages, it did allow me to resize the partition.

I am skipping over a painful bit that I doubt anyone else will ever encounter, but for my own reference I will detail it in the next post.

Someone at work gave a me a nice old LCD VGA monitor after I enquired about purchasing a slightly damaged one. This was great because I had got another HDMI->VGA for Xmas.

"Another one" you say? Yep, I am up to three now. The kids have a 21" CRT monitor each for the Raspberry Pis they were either given or won. The passive and very cheap adaptors have worked perfectly every time with these behemoths(about 20kg each).

So I happily plug in my new acquisition and the screen turns on and the text starts scrolling and then... the screen goes off... and then the red LED on the Pi starts flashing. This is a Model B+ and flashing red means power problems :(

After reading numerous thread where the decree is laid down "Passive HDMI->VGA adaptors do not work with the Pi" I was ready to throw in the towel, but I know that's not true, never had a bad day with the CRTs.

The Model A I used for the USB->Ethernet adaptor was still connected and running and was being powered by the PiHUB, I wonder. So I powered it down and connected the B+ and low and behold IT WORKED! The PiHUB seems to be better able to supply the consistent current required.

FYI the PiHUB also had a keyboard and mouse attached as well as powering the Pi and the USB->Ethernet adaptor.

PiHUB for the WIN!

I want to revisit the Kernel build with dm9601 patch to a) remove unnecessary steps and b) see if it could be done on a 4GB SD card.

New 4GB SD card with Raspbian (2014-12-24-wheezy-raspbian.img)

sudo apt-get -y update
sudo apt-get -y dist-upgrade
sudo apt-get -y install gcc make bc screen ncurses-dev

df -h
Filesystem     Size Used Avail Use% Mounted on
rootfs         3.6G 2.4G 985M 72% /
/dev/root     3.6G 2.4G 985M 72% /
devtmpfs        215M     0 215M 0% /dev
tmpfs            44M 208K 44M 1% /run
tmpfs         5.0M     0 5.0M 0% /run/lock
tmpfs            88M     0 88M 0% /run/shm
/dev/mmcblk0p1 56M 9.7M 47M 18% /boot

time to do some spring cleaning.
sudo apt-get -y install deborphan
sudo apt-get -y autoremove --purge libx11-.* lxde-.* raspberrypi-artwork xkb-data omxplayer penguinspuzzle sgml-base xml-core alsa-.* cifs-.* samba-.* fonts-.* desktop-* gnome-.*
sudo apt-get -y autoremove --purge $(deborphan)
sudo apt-get -y autoremove --purge
sudo apt-get -y autoclean

df -h
Filesystem     Size Used Avail Use% Mounted on
rootfs         3.6G 849M 2.5G 25% /
/dev/root     3.6G 849M 2.5G 25% /
devtmpfs        215M     0 215M 0% /dev
tmpfs            44M 208K 44M 1% /run
tmpfs         5.0M     0 5.0M 0% /run/lock
tmpfs            88M     0 88M 0% /run/shm
/dev/mmcblk0p1 56M 9.7M 47M 18% /boot

Get the repositories and patch the Kernel.
git clone --depth 1 git://github.com/raspberrypi/linux.git
git clone https://github.com/kmtaylor/rpi_patches.git
cd linux
patch -p1 < ../rpi_patches/dm9601-bug.patch

Prepare Kernel config
KERNEL_SRC=/home/pi/linux/
make mrproper
zcat /proc/config.gz > .config
make oldconfig

and the 11hr bit.
make

build the modules.
sudo make modules_install

finally copy the newly built Kernel to the boot partition.
sudo cp arch/arm/boot/zImage /boot/kernel.img

Last check after rebooting with the DM9601 USB->Ethernet adaptor and WORKS!!

For various reasons the following was performed on a Raspberry Pi (model B+) instead of cross compiling it on a more capable machine.

It took over 10hrs to build, all fool me!

All links about building the Kernel on the Pi lead to
http://elinux.org/RPi_Kernel_Compilation

but it is either out of date or just plain wrong, these are the steps I took...

What Kernel version was the Pi currently running?
uname -a
Linux raspberrypi 3.12.35+ #730 PREEMPT Fri Dec 19 18:31:24 GMT 2014 armv6l GNU/Linux

git init
git clone --depth 1 git://github.com/raspberrypi/linux.git
cd linux

That got the latest Kernel, that I confirmed with

head linux/Makefile

VERSION = 3
PATCHLEVEL = 12
SUBLEVEL = 36
EXTRAVERSION =
NAME = One Giant Leap for Frogkind

sudo apt-get -y update
sudo apt-get -y dist-upgrade
sudo apt-get -y install gcc make bc screen ncurses-dev
(notice the "-y"? that says yes to everything, dangerous if you are not sure what you are doing!)

KERNEL_SRC=/home/pi/linux/
git clone https://github.com/raspberrypi/tools

and promptly ran out of space on my 4gb SD card :(

New 8gb SD card with Raspbian and we are off again, repeated all the above steps and ...

CCPREFIX=/home/pi/tools/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi-

sets the path to the tools for the Pi's chipset so we can continue

make mrproper
gunzip -c /proc/config.gz > .config

that will copy the current running kernels config settings.

ARCH=arm CROSS_COMPILE=${CCPREFIX} make oldconfig

preps the build with the old settings
and if you want to change any of the setting use

ARCH=arm CROSS_COMPILE=${CCPREFIX} make menuconfig

but that was not my goal so onwards.

now the long bit.

make
Started Fri Jan 16 21:36:07 UTC 2015
Ended Sat Jan 17 08:00:58 UTC 2015
Thats right, almost eleven hours

But all was well so I continued.

sudo make modules_install
which thankfully only took a few minutes.

sudo cp arch/arm/boot/zImage /boot/kernel.img
Which copies the new Kernel into place and rebooted with
sudo shutdown -r now

When the Pi was up and running again

uname -a

now gives

Linux raspberrypi 3.12.36+ #1 PREEMPT Sat Jan 17 07:23:18 UTC 2015 armv6l GNU/Linux

the transplant has worked!!

Now to apply the fix from

https://github.com/kmtaylor/rpi_patches/blob/master/dm9601-bug.patch

edit "/drivers/net/usb/usbnet.c"

change line 476 from
- skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
to
- skb = __netdev_alloc_skb_ip_align(dev->net, size * 2, flags);

make

Only 9mins this time, it just builds the changed file and its dependencies.

another

sudo make modules_install
sudo cp arch/arm/boot/zImage /boot/kernel.img
sudo shutdown -r now

test one ssh:passed
test two update: scary pauses but ... WORKS!

FYI When I got stuck with
Syntax error: word unexpected (expecting ")")
I found this post helped

https://github.com/raspberrypi/linux/issues/437#issuecomment-28938920
By "notro"

I wonder how difficult it would be to make this fix, a kernel boot parameter?

One of the Raspberry Pi model A's main features is its lack of Ethernet adaptor(part of keeping the price down) and every now and then I really miss being able to ssh into it without messing about with Wifi.

Come Christmas 2014 I had over 200 items in my Amazon wish-list including one
MOGOI(TM) White USB 2.0 to RJ45 Port Lan Ethernet Network Adapter Converter For PC/Mac/Win7 With MOGOI Accessory Wire Winder

Which at the time was less than £3

Xmas day and I got various items mostly from my wish-list including this USB->Ethernet adaptor. Plugged it in to the Raspberry Pi and was amazed that I could just run nmap and find the Pi. Then I ssh'd in and as it all worked I left a glowing review on Amazon.

But all was not well. I tried to update the Pi with the usual
sudo apt-get update
and was surprised to get a Kernel panic, stopping the Pi dead in its tracks. Puzzled I went through two more SD cards and switched power supplies thinking that was where the problems lay. But no, each time I tried to update, Kernel panic.

Googling around for apt-get Kernel panic immediately showed other users of this type of USB->Ethernet adaptor having exactly the same problem.

lsusb
...
Bus 001 Device 004: ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter
...

It is also know for claiming to be a USB2.0 device but is really USB1.1
sudo lsusb -d 0fe6:9700 -v
Bus 001 Device 004: ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB             1.10
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0        64
idVendor         0x0fe6 Kontron (Industrial Computer Source / ICS Advent)
idProduct         0x9700 DM9601 Fast Ethernet Adapter
bcdDevice            1.01
iManufacturer         0
iProduct                2 USB 2.0 10/100M Ethernet Adaptor
...


note the bcdUSB field is 1.10, that's USB1.1 and its throughput is limited to 12 Mbps.

so all is lost and I have a new paper weight?

No, there was hope, someone had created a Kernel patch that doubled the buffer size and stopped the panic.
https://github.com/kmtaylor/rpi_patches/blob/master/dm9601-bug.patch

and the that patch was to simply change line 476 from
- skb = __netdev_alloc_skb_ip_align(dev->net, size, flags);
to
- skb = __netdev_alloc_skb_ip_align(dev->net, size * 2, flags);

but there was a small problem, this was not a simple binary module download or even a module source build...

I needed to build the entire Kernel !!!