dispo

  • Posts

    20
  • Joined

  • Last visited

dispo's Achievements

  1. 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'
  2. 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 ?
  3. 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.
  4. 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]
  5. 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
  6. 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
  7. 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 ?
  8. 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.
  9. 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
  10. 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
  11. 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.
  12. 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 )
  13. 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.
  14. 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. :|