• Content Count

  • Joined

  • Last visited

  1. Hi, Just something I have found, not sure if this is an 'issue' but it definitely caught me out and took a while to figure out and fix. I have several armbian machines (Odroid C2, BananaPi Pro) all running Jessie or Stretch and all working fine. A recent project of mine (using Armbian on a BPi Pro) was to build a Pi-Hole DNS. Some time after doing that I noticed that none of the Armbian machines would successfully run 'apt update' whilst other unix machines including a RPi running raspbian were all fine. DNS config was fine, I could see requests hit the Pi-Hole and be answered. nslookup / dig on the armbian machines all worked fine but 'apt update' reported 'could not resolve' errors trying to reach apt.armbian.com plus others. I tried all sorts of fixes and none worked except taking the Pi-Hole out of the DNS path. Then I found a comment recommending this 'apt-get -o Acquire::ForceIPv4=true update' and it worked! I realised that whilst playing with the Pi-Hole and only having an IPV4 network that I had blocked all IPV6 lookups (including IPV6 lookups within the IPV4 protocol) via iptables giving ICMP unreachable results. I removed those iptable entries on the Pi-Hole and the Armbian machines started working with apt update again. So it would appear that even though apt is querying the required domains via IPV4 (looking for both IPV4 and IPV6 results) if either comes back as unreachable then apt fails. As I said not sure if this is an 'issue' its just noticeable that other flavours of linux I use (raspbian, linux mint) do not do the same. edit: just to be clear, I am aware that the standard is to query IPV6 and IPV4 simultaneously (even when IPV6 itself is disabled and as a result the IPV6 query is via IPV4), it just seems that with armbian if the IPV6 answer comes back as unreachable then the IPV4 answer even though valid is not used. This is what appears to be different to my other distros. Also changing the Pi-Hole iptable rules to drop the AAAA requests instead of rejecting also allows apt update to work but with a noticeable delay from the AAAA request timing out.
  2. So is the issue with power (in general) the abilitiy of the power adapters to generate it, the micro USB cable / connector / port to deliver it or just a general inability of the design ? Do you use a normal 5V xAmp USB power supply and reterminate the USB cable to the GPIO or a a different, higher rated supply altogether ?
  3. Thanks for the reply. I realised after posting that the file date on the download image was still 25th November. Commenting out the MAC address line manually definitely worked as a fix.
  4. This didnt work for me, Installed fresh copy of Armbian 5.35 Odroid c2 Debian jessie 3.14.79 to known good SD card Booted ok with network. apt update && apt upgrade all worked apt update again just to to check, all up to date reboot and no network. This thread starts by talking about file corruption but is actually about network. This seems identical to the thread titled No IP-assignment with C2 and 3.14.79-odroidc2 as both have now proposed the solution of commenting out the MAC address entry in interfaces I will have a look at that and see if it fixes it / will let me apply the change after first boot but before reboot and be retained. The fix mentioned above of update / upgrade was supposed to 'fix' the mac address issue, did I miss a step ?