Andrew's blog

I found to make all this work I had to piece together a bunch of information from different locations. This fills in some of the blanks from the official Raspberry Pi documentation. See here, here, and here.

Image

Download the latest raspbian image from https://www.raspberrypi.org/downloads/raspbian/ and unzip it. I used the lite version as I'll install only what I need later.

To extract the files from the image we need to jump through some hoops. Inside the image are two partitions, we need data from each one.

 # Make it easier to re-use these instructions by using a variable
 IMG=2017-04-10-raspbian-jessie-lite.img
 fdisk -l $IMG

You should see some output like:

 Disk 2017-04-10-raspbian-jessie-lite.img: 1.2 GiB, 1297862656 bytes, 2534888 sectors
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disklabel type: dos
 Disk identifier: 0x84fa8189
 
 Device                               Boot Start     End Sectors  Size Id Type
 2017-04-10-raspbian-jessie-lite.img1       8192   92159   83968   41M  c W95 FAT32 (LBA)
 2017-04-10-raspbian-jessie-lite.img2      92160 2534887 2442728  1.2G 83 Linux

You need to be able to mount both the boot and the root partitions. Do this by tracking the offset of each one and multiplying it by the sector size, which is given on the line saying "Sector size" (typically 512 bytes), for example with the 2017-04-01 image, boot has an offset of 8192, so I mount it like this (it is VFAT):

 mount -v -o offset=$((8192 * 512)) -t vfat $IMG /mnt
 # I then copy the data off:
 mkdir -p /data/diskless/raspbian-lite-base-boot/
 rsync -xa /mnt/ /data/diskless/raspbian-lite-base-boot/
 # unmount the partition now:
 umount /mnt

Then we do the same for the root partition:

 mount -v -o offset=$((92160 * 512)) -t ext4 $IMG /mnt
 # copy the data off:
 mkdir -p /data/diskless/raspbian-lite-base-root/
 rsync -xa /mnt/ /data/diskless/raspbian-lite-base-root/
 # umount the partition now:
 umount /mnt

DHCP

When I first set this up, I used OpenWRT on my router, and I had to patch /etc/init/dnsmasq to support setting DHCP option 43. As of the writting of this article, a similar patch has been merged, but isn't in a release yet, and, well, there may never be another release of OpenWRT. I'm now running LEDE, and the the good news is it already has the patch merged (hurrah!). If you're still on OpenWRT, then here's the patch you'll need:

https://git.lede-project.org/?p=source.git;a=commit;h=9412fc294995ae2543fabf84d2ce39a80bfb3bd6

This lets you put the following in /etc/config/dnsmasq, this says that any device that uses DHCP and has a MAC issued by the Raspberry PI Foundation, should have option 66 (boot server) and option 43 set as specified. Set the IP address on option 66 to the device that should be used for tftp on your network, if it's the same device that provides DHCP then it isn't required. I had to set the boot server, as my other network boot devices are using a different server (with an older tftpd-hpa, I explain the problem further down).

 config mac 'rasperrypi'
         option mac 'b8:27:eb:*:*:*'
         option networkid 'rasperrypi'
         list dhcp_option '66,10.1.0.253'
         list dhcp_option '43,Raspberry Pi Boot'

tftp

Initially I used a version of tftpd that was too old and didn't support how the RPi tried to discover if it should use the serial number based naming scheme. The version of tftpd-hpa Debian Jessie works just fine. To find out the serial number you'll probably need to increase the logging of tftpd-hpa, do so by editing /etc/default/tftpd-hpa and adding "-v" to the TFTP_OPTIONS option. It can also be useful to watch tcpdump to see the requests and responses, for example (10.1.0.203 is the IP of the RPi I'm working with):

  tcpdump -n -i eth0 host 10.1.0.203 and dst port 69

This was able to tell me the serial number of my RPi, so I made a directory in my tftpboot directory with the same serial number and copied all the boot files into there. I then found that I had to remove the init= portion from the cmdline.txt file I'm using. To ease debugging I also removed quiet. So, my current cmdline.txt contains (newlines entered for clarity, but the file has it all on one line):

idwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs
nfsroot=10.1.0.253:/data/diskless/raspbian-lite-base-root,vers=3,rsize=1462,wsize=1462
ip=dhcp elevator=deadline rootwait hostname=rpi.etc.gen.nz

NFS root

You'll need to export the directories you created via NFS. My exports file has these lines:

/data/diskless/raspbian-lite-base-root	10.1.0.0/24(rw,no_root_squash,sync,no_subtree_check)
/data/diskless/raspbian-lite-base-boot	10.1.0.0/24(rw,no_root_squash,sync,no_subtree_check)

And you'll also want to make sure you're mounting those correctly during boot, so I have in /data/diskless/raspbian-lite-base-root/etc/fstab the following lines:

10.1.0.253:/data/diskless/raspbian-lite-base-root   /       nfs   rw,vers=3       0   0
10.1.0.253:/data/diskless/raspbian-lite-base-boot   /boot   nfs   vers=3,nolock   0   2

Network Booting

Now you can hopefully boot. Unless you into this bug, as I did. Where the RPi will sometimes fail to boot. Turns out the fix, which is mentioned on the bug report, is to put bootcode.bin (and only bootcode.bin) onto an SD card. That'll then load the fixed bootcode, and which will then boot reliably.

It seems that the iLiad might be really nice eBook reader. It supports PDF, allows you to annotate documents using a touchscreen and lots of other fancy things.

Nice.

Now if only it cost less than AUD$1,000...

What do you do if the back of your stereo cabinet is a mess and you've been a network monkey in the past?

Simple, you grab some cable management brackets from your good junk pile[1], some bits of MDF and you hack your stereo cabinet.

I think it came out much tidier, and now I can safely push it back without risking damaging cables!

If you're wondering why some of the power cords aren't plugged in, they belong to devices we don't use very much, why have them plugged in and drawing power if we aren't actually using them?

[1] "Good junk pile" every geek should have one, it is that collection of odds and sods that you don't really need, but which - just might, one day - come in handy. It should be noted however that they don't tend to have a very high Wife Approval Factor.

Why doesn't hardware have changelogs?

Perhaps I've been using open source software for too long, but I like to scan through the changelogs (a log of changes that the authors have made before releasing a new version) to see what has changed. This can give me hints to new features to checkout, or changed behaviour that it would be helpful to know about.

But hardware (and closed source software) typically don't have changelogs. An example is my Brand New Replaced Under Warranty D-Link DGS-1008D. The old one was hardware revision C3. The new one is C4. What has changed? Will it not brick itself like the old one did after a years usage? Is this one going to be faster because they've improved the code or silicon in some fashion?

I'll never know...

One of the projects I've been following quite closely is the OLPC project for the last couple of years. At Catalyst
we have an A-test board. Unfortunately I haven't much of a chance to play with it (although I would like to).

Last night one of karora's sons ran over and told us "Daddy there is a grownup over there using a kids computer!". Turns out that the Please Send Us To linux.conf.au students from Oregon State University had a OLPC out and were playing with it.

Susanne and I headed over to check it out. It is a really amazing device, even more amazing to see it in the flesh. It is very small, quite light and looks pretty darn cool. There is a video of us checking it on YouTube.

I can see why the hype has increased even more now that all the components have been put together and the working screen is in it.

Oh, and Susanne now really wants one.

Lenovo seem to be just another company that is completely USA centric.

I wanted to price out a Lenovo notebook, as I've used a number of IBM ThinkPads over the years and always found them to be very good notebooks. I had a look at their website and found the Z61t that seems pretty nifty. I did a few web searches using Google and found people talking about customising it, by adding a higher resolution screen, the 7 cell battery and things like that.

So I try cusomising the notebook on the Lenovo website (after telling it I'm in NZ). You can't. No customisation possible. You can order an additional battery (which is 7 cells) but you still get (and pay for) the 4 cell battery. So I call the 0800 number and talk to a woman at their call centre. She informs me that the package is the package, no customisation, no upgrades for batteries, nothing. I thank her and hang up somewhat disappointed.

Out of curiosity I tell the Lenovo website I'm in the USA. Wow. You can totally customise the notebook. Specify the CPU, RAM, batteries whatever. Although there is no option for a higher resolution screen.

Sigh...