dispo

Failed - Get:6 https://minio.k-space.ee/armbian/apt buster/main arm64 Packages [758 kB] Ign:6 https://minio.k-space.ee/armbian/apt buster/main arm64 Packages Get:7 https://minio.k-space.ee/armbian/apt buster/main armhf Packages [645 kB] Ign:7 https://minio.k-space.ee/armbian/apt buster/main armhf Packages Worked - Get:6 https://us.mirrors.fossho.st/armbian/apt buster/main armhf Packages [646 kB] Get:7 https://us.mirrors.fossho.st/armbian/apt buster/main arm64 Packages [762 kB] edit: Same machine, minutes apart but to a different mirror. The file sizes are the same as yesterday in each case. I'm wondering where the failing mirror is getting the incorrect 645/758 from instead of the correct 646/762. I've tried to find detail of how this process work but didnt get very far. I have been avoiding searches via google though It also always appears to be 'main armhf Packages' that fails and occassionally 'main arm64 Packages'

One thing I noticed - When it failed Hit:1 http://security.debian.org buster/updates InRelease Hit:2 http://deb.debian.org/debian buster InRelease Hit:3 http://deb.debian.org/debian buster-updates InRelease Hit:4 http://deb.debian.org/debian buster-backports InRelease Get:5 https://armbian.systemonachip.net/apt buster InRelease [18.3 kB] Get:6 https://armbian.systemonachip.net/apt buster/main armhf Packages [645 kB] Ign:6 https://armbian.systemonachip.net/apt buster/main armhf Packages Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Get:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages [758 kB] Ign:7 https://armbian.systemonachip.net/apt buster/main arm64 Packages Get:16 https://armbian.systemonachip.net/apt buster/main arm64 Contents (deb) [11.2 MB] Ign:16 https://armbian.systemonachip.net/apt buster/main arm64 Contents (deb) Ign:16 http://apt.armbian.com/region/EU buster/main arm64 Contents (deb) Get:7 https://minio.k-space.ee/armbian/apt buster/main arm64 Packages [758 kB] Err:7 https://minio.k-space.ee/armbian/apt buster/main arm64 Packages File has unexpected size (761502 != 758434). Mirror sync in progress? [IP: 193.40.103.4 443] When it worked - Hit:1 http://security.debian.org buster/updates InRelease Hit:2 http://deb.debian.org/debian buster InRelease Hit:3 http://deb.debian.org/debian buster-updates InRelease Hit:4 http://deb.debian.org/debian buster-backports InRelease Get:5 https://mirrors.netix.net/armbian/apt buster InRelease [18.3 kB] Get:6 https://mirrors.netix.net/armbian/apt buster/main arm64 Packages [762 kB] Get:7 https://mirrors.netix.net/armbian/apt buster/main armhf Packages [646 kB] Get:8 https://mirrors.netix.net/armbian/apt buster/main arm64 Contents (deb) [11.2 MB] Get:9 https://mirrors.netix.net/armbian/apt buster/main armhf Contents (deb) [17.3 MB] Get:10 https://mirrors.netix.net/armbian/apt buster/buster-utils arm64 Packages [6,789 B] Get:11 https://mirrors.netix.net/armbian/apt buster/buster-utils armhf Packages [6,801 B] Get:12 https://mirrors.netix.net/armbian/apt buster/buster-utils armhf Contents (deb) [8,535 B] Get:13 https://mirrors.netix.net/armbian/apt buster/buster-utils arm64 Contents (deb) [8,531 B] Get:14 https://mirrors.netix.net/armbian/apt buster/buster-desktop armhf Packages [22.8 kB] Get:15 https://mirrors.netix.net/armbian/apt buster/buster-desktop arm64 Packages [20.9 kB] Get:16 https://mirrors.netix.net/armbian/apt buster/buster-desktop arm64 Contents (deb) [32.9 kB] Get:17 https://mirrors.netix.net/armbian/apt buster/buster-desktop armhf Contents (deb) [96.1 kB] Fetched 29.9 MB in 52s (571 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date. It no longer reported IGN for get 6 and get 7 and the file sizes were different. Can you tell if a mirror sync was happening at the time ?

working now - thank you

Sadly that didn't work for me - thank you for your efforts though. I have one machine (NanoPi Neo2) that was built yesterday, running buster (Armbian_20.11.3_Nanopineo2_buster_current_5.9.14) that downloads 5 files under apt update and says all up to date. [I had successfully updated the machine already] I have a second machine (NanoPi Neo2) that was built today using the same image which fails. I have tried the default and regional mirrors and get a mix of errors. The EU is an odd one as it says the mirror is not signed (seperate issue ?). I'm assuming that NA is also the default as it's the same IP address. apt-get -o Acquire::ForceIPv4=true -o Acquire::CompressionTypes::Order::=gz -o Acquire::http::No-Cache=true -o Acquire::BrokenProxy=true -o Acquire::http::Pipeline-Depth=0 update ... Reading package lists... Done E: Failed to fetch http://apt.armbian.com/dists/buster/main/binary-armhf/Packages.gz File has unexpected size (645768 != 645022). Mirror sync in progress? [IP: 193.40.103.4 443] E: Failed to fetch http://apt.armbian.com/dists/buster/main/binary-arm64/Packages.gz File has unexpected size (761502 != 758434). Mirror sync in progress? [IP: 193.40.103.4 443] E: Failed to fetch http://apt.armbian.com/dists/buster/main/Contents-arm64.gz File has unexpected size (11237461 != 11236778). Mirror sync in progress? [IP: 193.40.103.4 443] E: Failed to fetch http://apt.armbian.com/dists/buster/main/Contents-armhf.gz File has unexpected size (17272323 != 17272310). Mirror sync in progress? [IP: 193.40.103.4 443] E: Some index files failed to download. They have been ignored, or old ones used instead. apt-get -o Acquire::ForceIPv4=true -o Acquire::CompressionTypes::Order::=gz -o Acquire::http::No-Cache=true -o Acquire::BrokenProxy=true -o Acquire::http::Pipeline-Depth=0 update ... Reading package lists... Done E: Failed to fetch http://apt.armbian.com/region/NA/dists/buster/main/binary-arm64/Packages.gz File has unexpected size (761502 != 758434). Mirror sync in progress? [IP: 193.40.103.4 443] E: Failed to fetch http://apt.armbian.com/region/NA/dists/buster/main/binary-armhf/Packages.gz File has unexpected size (645768 != 645022). Mirror sync in progress? [IP: 193.40.103.4 443] E: Failed to fetch http://apt.armbian.com/region/NA/dists/buster/main/Contents-armhf.gz File has unexpected size (17272323 != 17272310). Mirror sync in progress? [IP: 193.40.103.4 443] E: Failed to fetch http://apt.armbian.com/region/NA/dists/buster/main/Contents-arm64.gz File has unexpected size (11237461 != 11236778). Mirror sync in progress? [IP: 193.40.103.4 443] E: Some index files failed to download. They have been ignored, or old ones used instead. apt-get -o Acquire::ForceIPv4=true -o Acquire::CompressionTypes::Order::=gz -o Acquire::http::No-Cache=true -o Acquire::BrokenProxy=true -o Acquire::http::Pipeline-Depth=0 update ... Reading package lists... Done W: GPG error: https://minio.k-space.ee/armbian/apt buster Release: The following signatures were invalid: BADSIG 93D6889F9F0E78D5 Igor Pecovnik (Ljubljana, Slovenia) <igor.pecovnik@gmail.com> E: The repository 'http://apt.armbian.com/region/EU buster Release' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.

Same issue with Packages.bz2 but for buster Get:6 https://armbian.systemonachip.net/apt buster/main armhf Packages [591 kB] Err:6 https://armbian.systemonachip.net/apt buster/main armhf Packages File has unexpected size (591174 != 590754). Mirror sync in progress? [IP: 51.75.2.52 443] E: Failed to fetch https://armbian.systemonachip.net/apt/dists/buster/main/binary-armhf/Packages.bz2 File has unexpected size (591174 != 590754). Mirror sync in progress? [IP: 51.75.2.52 443]

I seem to have kicked a hornets nest with this one - not my intent :| For anyone interested I have implemented a quick fix which I will run via cron, the core of which is RELEASE=$(uname -v | awk '{print substr($1, 2, length($1)-1)}') sed -i '/VERSION/c\VERSION='$RELEASE'' /etc/armbian-release

So these are the files - but should they be automatically updated when the firmware is updated ? (as they are both now out of date). This is a minor thing, I just spotted the difference after upgrading firmware and thought that it hadn't worked - then realised it was just the banner. I can manually edit the file (if I can be bothered) but it felt like the version info in the banner was useful info when connecting to a box. Are these files used for anything meaningful by the system - such as setting system variable / hardware dependencies or are they just details from the initial install ? Should this file be updated during a reboot ? (such as after a firmware update requiring one). Looking at the files the only line that would actually change is the version number, everything else is hardware. $ more /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=nanopineo2 BOARD_NAME="NanoPi Neo 2" BOARDFAMILY=sun50iw2 VERSION=5.73 LINUXFAMILY=sunxi64 BRANCH=next ARCH=arm64 IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image $ more /etc/armbian-image-release # PLEASE DO NOT EDIT THIS FILE BOARD=nanopineo2 BOARD_NAME="NanoPi Neo 2" BOARDFAMILY=sun50iw2 VERSION=5.69 LINUXFAMILY=sunxi64 BRANCH=next ARCH=arm64 IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image IMAGE_UUID=9bae9d2c-efac-44b0-a948-2f8a60118113

I have various boards running Armbian and all have the very useful banner on login _ _ ____ _ _ _ ____ | \ | | __ _ _ __ ___ | _ \(_) | \ | | ___ ___ |___ \ | \| |/ _` | '_ \ / _ \| |_) | | | \| |/ _ \/ _ \ __) | | |\ | (_| | | | | (_) | __/| | | |\ | __/ (_) | / __/ |_| \_|\__,_|_| |_|\___/|_| |_| |_| \_|\___|\___/ |_____| Welcome to ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.20-sunxi64 However uname -a Linux npi-neo2 4.19.20-sunxi64 #5.75 SMP Fri Feb 8 10:29:25 CET 2019 aarch64 GNU/Linux A minor thing but it confused me slightly as I did a firmware upgrade but the banner did not change. I was thinking it was dynamically created but in fact it appears to be a static text file. Should the Armbian version numbers get updated when the firmware is upgraded or is it expected to be a manual process ?

yes, that's me. I'll try again and see what happens. As you say it's their code that has the issue by the look of it. .email is definitely a valid TLD.

Hi, Not sure where to post this so apologies if this is the wrong place. I currently have a .me.uk email domain and I can confirm addresses if I change them. However I am in the process of migrating to a .email domain and the confirmation emails never arrive. I am running into minor issues with this domain so this is not unique to Armbian forums. The vast majority of sites work ok but a rare few claim my email address is invalid or (as with the armbian forum) I never receive anything. The only way I have been able to post this was to change my email back to .me.uk and confirm via that. Is it possible to check if the software used for the forums is able to cope with .email addresses? This is the TLD so my email address is of the form john@doe.email Searching here found nothing but searching google found articles dating from 2017 stating the regex used by some sites to determine if the email was valid used the criteria of 2-4 characters for the TLD which obviously is one way that .email might be deemed invalid. Many thanks

what boards are you using for this ? It might be something I play with - such as 1st wifi as uplink to hotel, 2nd wifi for hotspot but then also layering on openvpn client out over wifi 1 to isolate / protect / encrypt my hotspot sourced traffic. Are you playing with boards with dual wifi built in or adding wifi to a board via usb ? Loving the idea of a portable one-box solution that I can build on as I want as I control the OS and have the power/ram to run extra functions

So not exactly an answer as you are running ubuntu but the armbian image for the neo2 does have /dev/watchdog and it can trigger a reboot. I found a page describing basic watchdog stuff and cat >> /dev/watchdog followed by a couple of carriage return and waiting = reboot which indicates its reachable and usable.

Hi, I've been trying to figure out why my logging was so active and just found this thread so thank you. Not hard to spot the issue but nice to find a solution detailed for me Just an extra note on this, the getty ttyS0 spam appears to be triplicated, in /var/log/auth.log, daemon.log and syslog so fixing it removes tons of log spam from all three files. All I need to do now (another issue entirely and not trying to hijack this thread) is fix SNMPD's ridiculous logging which appears to ignore any settings except via directly editing the snmpd.service file )

HI, I have the following NanoPi Neo 2 boards, hardware v 1.1, model 1711 with 1Gb RAM Linux 4.19.13-sunxi64 #5.70 SMP Sat Jan 12 17:41:57 CET 2019 aarch64 GNU/Linux I have noticed that various network related tasks fail at boot apparently at eth0 is not yet ready This includes network mounts via /etc/fstab and disabling IPv6 via /etc/sysctl.conf My current solution (which I feel is a complete bodge) is to have extra commands in /etc/rc.local that after a 5 second sleep issue a 'mount -a' and 'sysclt -p' I have tried solutions for 'wait for network' on boot but neither work. systemctl enable NetworkManager-wait-online.service systemctl enable systemd-networkd-wait-online.service Looking at the armbianmonitor output I see this. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet XXX.XXX.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 02:01:43:0c:2e:f7 brd ff:ff:ff:ff:ff:ff I have not edited the network config and /etc/network/interfaces is the standard # Network is managed by Network manager auto lo iface lo inet loopback IP address allocation is via DHCP, however these have pihole installed which I believe change this to static, albeit to match whatever they were getting via DHCP. Is anyone else seeing this, have any thoughts or have a 'better' solution ? edit: just spotted this at the bottom of the log [ 9.905128] RTL8211E Gigabit Ethernet 0.2:07: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=0.2:07, irq=POLL) [ 9.907509] dwmac-sun8i 1c30000.ethernet eth0: No Safety Features support found [ 9.907527] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available [ 9.907535] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW [ 9.907998] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 15.011046] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 15.011101] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 15.107488] FS-Cache: Loaded [ 15.176939] FS-Cache: Netfs 'cifs' registered for caching [ 15.177411] Key type cifs.spnego registered [ 15.177427] Key type cifs.idmap registered [ 15.178533] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. [ 15.611651] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 15.648915] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 15.655164] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 15.655183] cfg80211: failed to load regulatory.db [ 20.150078] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. It would be interesting to know what is happening between 9.907 and 15.01 where the network finally comes up. I would guess that the CIFS mount at 15.17 is the OS reading fstab, which appears to fail, then the second mount at 20.15 is rc.local running mount -a but I'm not 100% sure. I can't tell / don't know enough to see where in the boot sequence /etc/sysctl or /etc/fstab are invoked.

thanks for that - mmc0 did work, I must have missed it or used a poor test. none of the cpu variants seem to though which is a shame as I usually use those to confirm the box is alive and active. currently these are running pihole which doesnt generate much disk traffic with most of the activity in ram / ramdisk so the led activity is low at best. even creating a .tgz and setting the led to any cpu generates no light. :|

Hi, I have just received some shiny new NanoPi Neo 2 boards, hardware v 1.1, model 1711 with 1Gb RAM. I have installed Armbian Stretch mainline kernel 4.19.y with no issues at all however I have noticed that the green LED is pretty well ignoring anything I ask of it. ls -la /sys/class/leds/ total 0 drwxr-xr-x 2 root root 0 Jan 25 16:14 . drwxr-xr-x 52 root root 0 Jan 1 1970 .. lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status lrwxrwxrwx 1 root root 0 Jan 1 1970 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr cat /sys/class/leds/nanopi:green:status/trigger none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport usb-gadget usb-host disk-activity disk-read disk-write ide-disk mtd nand-disk [heartbeat] cpu cpu0 cpu1 cpu2 cpu3 default-on panic mmc0 0.2:07:link 0.2:07:1Gbps 0.2:07:100Mbps 0.2:07:10Mbps rfkill-any rfkill-none Of the above only 'none' heartbeat' and 'default-on' seem to work, all others are just off / no activity. I didn't try the kbd / usb related ones etc. as I don't have one attached. There was a comment in Nanopi NEO 2 dated May 2017 that this was seen and may get looked at so was just wondering if this is still as expected ? From the date and the colours mentioned I am also assuming that the original thread and comments covered the v1.0 hardware. All that aside, gotta say - Love your work.

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.

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 ?

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.

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 ?