odroid-wheezy-base (new image) & odroid-wheezy-retro release update

Time for release! A bugfix release for odroid-wheezy-retro and a new image, even smaller! :)

The new base image, odroid-wheezy-base, contains:

• debootstrapped Debian root filesystem
• wired network configured for DHCP
• SSH
• configured serial login on UART
• nothing else!

Download odroid-wheezy-base

This is ideal to setup a Debian server with your ODROID, or to kickstart any other customization project you might have. To name only a few: (web)servers, robotics, domotics, top-boxes, you name it!

Release update for odroid-wheezy-retro

The nasty network issue is solved in 0.7.2:

Download odroid-wheezy-retro 0.7.2 

The wildness of the network issue

Some users have reported network issues, however I was never able to reproduce them. At some point I did, and the nature of this issue manifested itself as a very nasty heisenbug.

On first boot the ethernet MAC address was randomly generated and the SSH keys regenerated; it turns out that some randomly generated MAC addresses would make the ethernet never come up, with an error like:

RTNETLINK answers: Cannot assign requested address
Listening on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on LPF/eth0/xx:xx:xx:xx:xx:xx
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
send_packet: Network is down
receive_packet failed on eth0: Network is down

Correlation is not causation

However, getting to the above conclusion was not easy because last week I observed the following and made wrong correlations:

1. downscaling issue with one of my customized wheezy-retro SD images (no reason yet verified for this issue, although it is specific that SD image)
2. network issue with the dedicated wheezy-retro SD image (this was due to the smsc95xx_mac_addr file), letting me for the first time verify the issue of users
3. found some corrupt (all null bytes) files in the dedicated wheezy-retro SD image

Since file corruption can "taint" everything it touches, I assumed that both the downscaling and network issue were correlated and caused by the first-time observed file corruption.

The lesson is that these issues should instead be considered separate (except 1 and 3 that still need to be verified for correlation), and I have applied mitigation (rsync checksum verification) for (3).