PiAware .img does not produce working RPi 2 B

Yesterday, I decided to upgrade to a Raspberry Pi 2 B model for my FlightAware ADS-B feeder. I figured I would just use the .img file from the website because I don’t plan on using this Pi for anything else anyways. I downloaded the zip file and wrote the .img file to a shiny new SD card. I used the prescribed program (Win32DiskImager), which I have used before with my other Raspberry Pi’s (I have five). Win32DiskImager said the write to the SD card was successful.

All was well and I started the Raspberry Pi with the newly minted SD card. The activity light made it seem like all was well. I went to the “Claim and Link…” page to hopefully see my new feeder show up. I mashed the “Check again…” button and there was nothing. 10 minutes - nothing. Half an hour - nothing.

From the “Claim and Link…” page, I then proceeded to click on the “Setup Manually…” link. While using this method, everything seemed to be alright. Raspbian appeared to be happy. The command to input my username was recognized. I was prompted for a password (which I was darn sure I entered correctly). I restarted the process, which was successful. I followed the instructions to the letter. All seemed to be well. I then went to my feeder page and waited for the new Pi to show up. Again - nothing happened.

I then started to do some sleuthing. I went to my router to see if the Pi had been assigned an IP address (it is connected via a cable). It had, so I tried to connect to port :8080. I don’t know for sure if the PiAware .img supports the little webpage server that I’m used to on :8080 but I figured I would give it a shot. Funny thing is, I was able to connect to port 8080. All I got was a webpage with the words “PRESENTATION PAGE” on it. Is it supposed to do that…or…is it a sign that the current .img file out there is defective? Was this a debug version? And/or is it somehow not meant for the Raspberry Pi 2 (even though the suggested hardware above the .img file link is a Raspberry Pi 2)? Honestly, this is my first Pi model 2 so I’m not an expert on the differences between an original model B and a model 2 B.

I repeated this process with the SD card three times. I even downloaded a fresh copy of the zip file to make myself feel better. Nothing has changed. In fact, right now, the Pi is hooked up and I have the “Claim and Link…” page open hoping for a miracle.

I am not opposed to using the manual process to get this Pi 2 up and running, but I am set on having the latest and greatest PiAware software running. I would like to get some multilat action going here!

Thank you for any help you can give,


By any chance did you just try pulling the SD out of the old Pi and trying it in the Pi2? That’s what I did, and had no problems getting the 2 up.

How about SSHing into the Pi2 and running piaware-status?

Have you checked from pi command line to see what ip has been assigned in the new pi ($ ifconfig)

How are you confirming that you have the IP address of the Pi and not something else?

I’ve just confirmed that an unmodified 2.1-2 sdcard image boots and runs OK on a Pi 2. So I don’t think it’s a bad image that’s the problem here.

I’ve swapped the same image card between a Pi B+ and Pi 2 without problems. I now only have one backup to cover two machines. The only feeder I’ve found that has separate ARM6 and ARM7 versions is the FR24 one, the ARM6 version still runs on a Pi 2 though.

Thanks for the feedback, everyone. The most important thing I did was to run ifconfig. This told me that the IP address of the Pi was not what I had previously thought (totally my fault). However, the Pi was running the junk IP address of This meant that DHCP was either not configured correctly (keeping in mind I had changed nothing) or had somehow failed. I checked my router and there is plenty of DHCP slots available.

So, I went to /etc/network/interfaces and think I found something.

iface eth0 inet manual

I have never seen this line set to manual. Anyways, I changed it to:

iface eth0 inet dhcp

And things seem to be ok now, although I do not see any aircraft displayed at port 8080, but at least the map is there. Due to my setup, it is extremely unusual to have no aircraft at all displayed.


I downloaded the image a couple days ago and had similar dhcp issues. I thought I might have had a bad nic so I tried a wireless EdiMax. When I went to edit /etc/network/interfaces to use wlan0 I noticed ‘iface eth0 inet manual’ and changed it to dhcp. Prior to that I was getting a 169.x.x.x address.

After editing both eth0 and wlan0 are getting IP addresses assigned via DHCP.

My test install has the same config, but it happily obtains a DHCP address. Looks like it is using dhcpcd.

Update, still no positions reported a few hours later. Good to see someone else has had a similar issue. Is there a chance that there was - and possibly still is - a bad release out there?

The md5 hash (courtesy of Win32DiskImager) for the .img file I downloaded is: 2e1481a8d139768a4f531a493f641486

Are the people with working copies using the .img file with this hash also?

The image I tested is the same one:

$ md5sum ~/Downloads/piaware-sd-card-2.1-2.img
2e1481a8d139768a4f531a493f641486  /home/oliver/Downloads/piaware-sd-card-2.1-2.img

I wonder if it is something like standalone dhcpcd has problems with some DHCP servers, but the different path triggered by “iface eth0 inet dhcp” is OK.

I think you need to log in to your problem system and work out what’s going on. Trying to diagnose it by proxy by seeing if positions turn up in flightaware or not just bundles too many possible problems together.

I think everything is working now. I did a sudo reboot and the airplanes started showing up. I guess the only issue was the /etc/network/interfaces table. Thanks for the help.


I have confirmed the newest version of Raspian as well as piaware does NOT have DHCP enabled by default on eth0… A step backwards in my opinion.


I think dhcpcd is configured, so if you look at /etc/network/interfaces, DHCP will appear to be disabled, but it isn’t.

Eth0 is set to manual not dhcp. That is the issue.


I think this is the stock raspbian config, actually. If no interfaces are explicitly configured for dhcp, then dhcpcd is started and handles them all. It works fine here.

This is /etc/network/interfaces from latest FA image

pi@piaware ~ $ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto wlan0
allow-hotplug wlan0
iface wlan0 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

auto wlan1
allow-hotplug wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

eth0 would NOT acquire a DHCP address FROM MY ROUTER until I changed it to “iface eth0 inet dhcp”


Right, so we are back to it being a problem with some routers. Would you be willing to dig into why the default configuration doesn’t work with your router?

The default configuration uses dhcpcd instead of dhcpd. Note the spelling difference.

eth0 should be set to manual in /etc/network/interfaces when dhcpcd is being used.

You have forced it to use the older dhcpd instead of the newer dhcpcd. The question is, why did you need to do that?

Have you disabled dhcpcd? Is it incompatible with your DHCP server for some reason?

It looks like the May 2015 Raspbian release added the raspberrypi-net-mods package and that’s what has changed the /etc/network/interfaces configuration. (This is an upstream change, not something FA has added.)

The new configuration uses the manual keyword and then dhcpcd to grab an address. I believe the old way was with the dhcp keyword along with isc-dhcp-common. (And ifplugd is still in the mix which can cause problems if you are using wireless and eth0 at the same time.)

FWIW, I just imaged a new card and put it in a Pi 2 and it looked to hear the RA’s from my router and it solicited the correct address.