Quanta

Dennis I apologize for calling you Denny. It wasn't intentional. It was done in haste. I *always* check with the person for a preference before doing such a thing. I am not clear just how to do this. What file has bytes? What form (binary? Ascii? ) How to ID bytes I want etc. .....Deleted I worked for a while trying to express more questions and observations, verify what I think I have seen etc. I wonder if it is possible I have stumbled on the source of the problem - usb to serial console adapter. Is it possible that it is messing with power? I am using the FA adapter sold with the boards. I use the FA power dock to power the board from a compact form factor PC supply 12V buss. In order to see boot, I leave serial adapter connected to console, powered and connected to Putty. I usually issue shutdown, toggle power switch on dock for some seconds and then re-power. [I have observed in the past that after issuing shutdown the board does go through the routine but will get / stay warm -even hot long after if I don't shut of dock. Seems I read shutdown doesn't work like it ought to for early boards - possibly related? ] When board acts up I cannot do what I normally do in remote context (reboot now). I have a warning that comes up instead of shutdown when I issue that command without explicit path because normally I won't be there to power cycle. Also, in the remote context, I never have the console port connected. So the greatest potential for this possible problem to appear would be when the board is on the bench and I have removed sd card to image, and then re-install while using console port to monitor. ... A little more testing. I have some trouble with the usb cable to the serial adapter dropping out if I move it so this complicates the testing some but it looks like this is part of the problem at least. There are times when with serial adapter connected, and the power dock switched off, cpu power remains up. I see it on a protobard connected to the B side of the power dock (has a power LED). Removing usb extinguishes of course. Also when reconnecting USB, the led on adapter indicating either TD or RD (or both) activity {don't recall} will light dimly. Another observation today is that with no SD card I get nothing from console now. I think this is different from earlier. I made no changes to on board mmc. I am fairly sure the serial adapter is ok when this happens but I need to look at this a little deeper. Hopefully all this means that I have reliable boot so long as there is only one possible source for power. I have yet to test a backup image. Perhaps later today. Thanks to all and I hope I have added something useful. I will report back with more if I have something helpful. Should I start a new thread? Q

Thanks for this post Denny. Armbianmonitor: http://ix.io/2cPw Can you or anyone actually, point me to a solution? I have a NEO 2 that will not reliably boot (now). Your solution looks like you boot SD card and then, using the booted system, fix the MMC boot process. I can't get board to boot with valid SD image. This board and image were working fine and I know of nothing I did that would break it. The same card/image works on a NEO 2+ just fine. Both are earlier HW revs I think but have been working reliably through many power cycles and shutdowns. I see that no DTB is found now on my non booting board when it won't boot according to the console but unclear how to fix in this case. I don't want to break the SD card - I spent a lot of time getting it set up and was trying to backup card and ran afoul of this problem. In my case I don't want to use mmc because I can't replace if I run into a wearout problem. I want to be able to drop in a new card with a reference backup image and have the board back operational. This may not be optimal but at my current level of proficiency and because of the application this seems the most sensible right now. So, to re-state more clearly the question, what should I do to get a (more) reliable boot from sd card at this point? I am concerned that while the board is running at the moment, It will choke on some future reboot - perhaps in the process of fixing uboot and I won't know what to do... This isn't something I feel I can 'experiment' with to fix. There are too many unknowns for me. Dumping a file onto the board or editing via winscp or webmin I can do now but once the board will not boot to SD I am in up a little over my nose... This board doesn't do much and doesn't need to do it particularly fast. Reliability is far more important in this case. U-Boot SPL 2019.04-armbian (Jul 16 2019 - 09:15:50 +0200) DRAM: 4096 MiB Trying to boot from MMC1 NOTICE: BL31: v2.1(debug):3ce3ce0-dirty NOTICE: BL31: Built : 17:00:24, Jul 15 2019 NOTICE: BL31: Detected Allwinner H5 SoC (1718) NOTICE: BL31: No DTB found. INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller NOTICE: BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design. INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 !!! This time the board booted as expected!!! Problem is I can't have it behaving like this at the remote site! U-Boot SPL 2019.04-armbian (Jul 16 2019 - 09:15:50 +0200) DRAM: 512 MiB Trying to boot from MMC1 NOTICE: BL31: v2.1(debug):3ce3ce0-dirty NOTICE: BL31: Built : 17:00:24, Jul 15 2019 NOTICE: BL31: Detected Allwinner H5 SoC (1718) NOTICE: BL31: Found U-Boot DTB at 0x408c3b0, model: FriendlyARM NanoPi NEO 2 INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller NOTICE: BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design. INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 855873 was applied INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot 2019.04-armbian (Jul 16 2019 - 09:15:50 +0200) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: mmc@1c0f000: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial Out: serial Err: serial NanoPi NEO2 v1.0 detected Net: phy interface7 eth0: ethernet@1c30000 ** Reading file would overwrite reserved memory ** There is no valid bmp file at the given address starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3042 bytes read in 2 ms (1.5 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc Thanks to all. Q

I too am running H5 based board and want to get hw WD functions as well as others working. I have Nano PI NEO 2 , NEO plus2, and NEO Core2. I need to be able to use the WD features on all of these boards. I have read all in the fora here as well as what was linked with particular attention to this and have tried to implement the example provided by gnasch but when I do, I get this: # ps aux |grep watch root 44 0.0 0.0 0 0 ? S 22:39 0:00 [watchdogd] root 1773 0.0 0.1 2824 648 ttyS0 S+ 22:41 0:00 grep watch Honestly, I haven't figured out what it means but it differs from what gnasch posted in particular, nothing for each core. I also tried: # systemctl status watchdog * watchdog.service - LSB: Start software watchdog daemon Loaded: loaded (/etc/init.d/watchdog; generated) Active: active (exited) since Sat 2019-12-28 22:39:33 EST; 1h 10min ago Docs: man:systemd-sysv-generator(8) Process: 659 ExecStart=/etc/init.d/watchdog start (code=exited, status=0/SUCCE Dec 28 22:39:33 Millheim systemd[1]: Starting LSB: Start software watchdog daemo Dec 28 22:39:33 Millheim systemd[1]: Started LSB: Start software watchdog daemon lines 1-8/8 (END) Also, I can do: #echo 1 > /dev/watchdog and the system does reboot. This was suggested earlier in the thread but did not indicate that the reaction was supposed to be a reboot However, I don't understand what is being watched! In particular, I don't know how to verify the HW WD is working. There is a watchdogd process running which is no surprise since it is possible to cause a reboot as above. I do see /dev/watchdog and /dev/watchdog0 but do not know what exactly is going on here. I think I understand that this is associated in some way with the HW WD in some sense but why two? I see the "watchdog-device = /dev/watchdog" in watchdog.cfg but do I need an additional line that says "watchdog-device = /dev/watchdog0" ? I think I understand how to test cpu loading but the question arises, how are multiple cores handled? Is it possible for one of 4 cores to get hung up with a runaway process or some such? This would seem (in part) to be the reason for gnasch's comment: As well as the reason I think I want to see something for each core. Any additional insights would be appreciated. Regards to all, Q

One other thing. The local group gpio has a group ID of 1002. I created the group because it was (apparently) needed but did not specify GID on creation. When I have seen GIDs for gpio elsewhere they are sub 1000 numbers (101 I think)- presumably reserved for system functions. I assume these sub 1000 numbers are assigned by the os and by convention the range below 1000 is used. It does not follow (in my mind anyway) that there is any necessity for that convention except easier system admin, config, etc. It would not surprise me however, to learn that some core code can't handle system GIDs above 1000. That said, if GID should be changed, to what? Use same method as usual? 100 is not currently assigned but 101 is ( systemd-journal) is 100 ok to use or is there another? In any case, after such a change I assume a reboot would be at a minimum wise - if not required. Q

Greetings all. I am having no success getting access to gpio pins in NR using opi-gpio. I am trying to re-build a system that I messed up due to an update. The update broke access to the 1-wire host adapter I had running on I2C. I have searched and read a lot trying to find a solution but I am not making enough sense of the solutions I read to even know if they apply or if I am applying them correctly. Very frustrating because I had this working once but that was a number of versions ago for both armbian and NR. Also, the gpio pins were working even after the I2c update. In the process of 'fixing' that I started over with current armbian: millheim@Millheim:~$ Linux Millheim 4.19.63-sunxi64 #5.92 SMP Fri Aug 2 00:18:27 CEST 2019 aarch64 GNU/Linux and node red 1.0.2. Once running, I copied the backup I made of the flow and have most things working as I had them before. The main thing that I cannot get working is GPIO. I decided to try to use an approach that duplicates as closely as possible another system I have running which is a Nanopi Neo Core 2 LTS. The board I am trying to get working is a Nanopi Neo 2. I flashed the corresponding image, selected docker and hassio (hassio was false start and am not using it). I then pulled official current NR and now have NR flow working except for access to gpio. It looks to me like the docker container isn't getting access to the gpio. I cannot figure out what I need to do here. When it comes to giving the correct permissions, I want to use good practice but don't think I need to be retentive and only give access to the 3 pins I am using at the moment. I am looking for a solution that will allow me to access the pins, interrupts, etc. shown in gpio readall without having to fiddle with this issue repeatedly. This iteration: docker run -it -p 1880:1880 --device=/dev/gpiochip0 --device=/dev/gpiochip1 -v /home/millheim/.node-red/data:/data --name nodered nodered/node-red Gives this error: 17 Nov 03:39:24 - [info] Starting flows 17 Nov 03:39:24 - [info] [opi_out:Pin 24 - PC3] Pin: 67 17 Nov 03:39:24 - [error] [opi_out:9f074a4f.c5db88] Error: EACCES: permission denied, open '/sys/class/gpio/export' 17 Nov 03:39:24 - [info] [opi_out:Pin 23 - PC2] Pin: 66 17 Nov 03:39:24 - [error] [opi_out:526f3769.6171f8] Error: EACCES: permission denied, open '/sys/class/gpio/export' 17 Nov 03:39:24 - [info] [opi_out:Pin 21 - PC1] Pin: 65 17 Nov 03:39:24 - [error] [opi_out:acccfc03.277b9] Error: EACCES: permission denied, open '/sys/class/gpio/export' 17 Nov 03:39:24 - [info] Started flows My user is member of group gpio. It is probably clear to others (barely to me) NR does run this way and does communicate with owserver. There are errors thrown but only because only one sensor is present. Others aren't connected. /etc/rc.local has this: sudo chown root:gpio /sys/class/gpio/unexport /sys/class/gpio/export sudo chmod 220 /sys/class/gpio/unexport /sys/class/gpio/export exit 0 /etc/udev/rules.d/99-com.rules has this: # KERNEL=="gpio*", RUN="/bin/sh -c 'chgrp -R gpio /sys/%p /sys/class/gpio && chmod -R g+w /sys/%p /sys/class/gpio'" # SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio'" SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'find -L /sys/class/gpio/ -maxdepth 2 -exec chown root:gpio {} \; -exec chmod 770 {} \; || true'" Output of armbianmonitor -u: https://drive.google.com/open?id=1Xfu8YhRqs1OCbWmSoMbsP4VvBEhGgbyv I doubt this will be terribly helpful but just in case millheim@Millheim:~$ gpio readall +-----+-----+----------+------+---+-NanoPi-NEO2--+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | 3.3V | | | 1 || 2 | | | 5V | | | | 12 | 8 | GPIOA12 | ALT5 | 0 | 3 || 4 | | | 5V | | | | 11 | 9 | GPIOA11 | ALT5 | 0 | 5 || 6 | | | 0v | | | | 203 | 7 | GPIOG11 | OFF | 0 | 7 || 8 | 0 | OFF | GPIOG6 | 15 | 198 | | | | 0v | | | 9 || 10 | 0 | OFF | GPIOG7 | 16 | 199 | | 0 | 0 | GPIOA0 | OFF | 0 | 11 || 12 | 0 | OFF | GPIOA6 | 1 | 6 | | 2 | 2 | GPIOA2 | OFF | 0 | 13 || 14 | | | 0v | | | | 3 | 3 | GPIOA3 | OFF | 0 | 15 || 16 | 0 | OFF | GPIOG8 | 4 | 200 | | | | 3.3v | | | 17 || 18 | 0 | OFF | GPIOG9 | 5 | 201 | | 64 | 12 | GPIOC0 | OFF | 0 | 19 || 20 | | | 0v | | | | 65 | 13 | GPIOC1 | OFF | 0 | 21 || 22 | 0 | OFF | GPIOA1 | 6 | 1 | | 66 | 14 | GPIOC2 | OFF | 0 | 23 || 24 | 0 | OFF | GPIOC3 | 10 | 67 | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+-NanoPi-NEO2--+------+----------+-----+-----+ +-----+----NanoPi-NEO2 USB/Audio-+----+ | BCM | wPi | Name | Mode | V | Ph | +-----+-----+----------+------+---+----+ | | | 5V | | | 25 | | | | USB-DP1 | | | 26 | | | | USB-DM1 | | | 27 | | | | USB-DP2 | | | 28 | | | | USB-DM2 | | | 29 | | | | IR-RX | | | 30 | | 17 | 19 | GPIOA17 | OFF | 0 | 31 | | | | PCM/I2C | | | 32 | | | | PCM/I2C | | | 33 | | | | PCM/I2C | | | 34 | | | | PCM/I2C | | | 35 | | | | 0V | | | 36 | +-----+-----+----------+------+---+----+ +-----+----NanoPi-NEO2 Debug UART-+----+ | BCM | wPi | Name | Mode | V | Ph | +-----+-----+----------+------+---+----+ | 4 | 17 | GPIOA4 | ALT5 | 0 | 37 | | 5 | 18 | GPIOA5 | ALT5 | 0 | 38 | +-----+-----+----------+------+---+----+ Thanks for taking the time to look through this. Hope you can help. Q

Fix DNS not part of problem - My error. Webmin install candidate not found. Repos not included in armbian install. Add them. The instructions to do this are here http://www.webmin.com/deb.html I used nano to edit /etc/apt/sources.list file to add the repository shown in the link. Webmin dependency apt-show-versions not installing / breaking webmin install. Apparently, the issue was apt-show-versions was in some way impacted by having compressed files somewhere 'nearby'. Deleting with rm as below allowed process to complete. cd /var/lib/apt/lists rm *.lz4 apt-get -o Acquire::GzipIndexes=false update apt-get install apt-show-versions Success! apt-get install --fix-broken webmin ... The following additional packages will be installed: libauthen-pam-perl libio-pty-perl libnet-ssleay-perl perl-openssl-defaults The following NEW packages will be installed: libauthen-pam-perl libio-pty-perl libnet-ssleay-perl perl-openssl-defaults webmin 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded. Need to get 16.2 MB of archives. After this operation, 174 MB of additional disk space will be used. Do you want to continue? [Y/n] y ...Setting up webmin (1.900) ... Webmin install complete. You can now login to https://HAL_Mk1:10000/ as root with your root password, or as any user who can use sudo to run commands as root. Processing triggers for systemd (232-25+deb9u6) ... Usin a web browser, Log in to webmin at the board's IP or host name:10000 (192.168.xxx.xxx:10000). Go to system>bootup and shutdown within webmin and you will see webmin among the entries there. Check that webmin is loaded at startup. You can change to not load after your system is configured to your satisfaction to lessen load. At that point it is fairly easy to ssh into system and start webmin from command line later when needed. As I have said before, what follows is not complaining. It is merely an assessment of an area where I see some room for improvement. I think it is worth saying especially for the sake of those with limited time to invest and those trying to get started. Also, I think I understand that these issues aren't directly issues with armbian but they have the potential to have significant impact on adoption. I hope that the armbian devs can adjust things so that: Webmin is available to install more easily. The issue with compressed files goes away. In my case, I lost a lot of time trying to get past this that could have been spent in any number of more positive ways, many of which would benefit armbian. I wouldn't mind preparing some changes for the site to address this and some other issues I see but that will have to wait 'till I make up some lost time - how does that happen... Thanks to all and here's to the success of the devs of Armbian going forward! Q

Thanks SFX2k Will look into cockpit. There are some things I am not comfortable with about Webmin so here's hoping. Also thanks for Tecmint. Will check out. I had tried installing from a local package but it didn't go well. Can't remember details. I don't mean to be pedantic but as far as armbian-config goes, I still can't find a place to specify DNS servers for a manual IP config under the Network/IP or Network/Advanced tab. Those are the only two places it ought to be by my experience and no option when doing a manual IP config seems, well, less than optimal. If when you say "fine here" you mean you can manually config IP and set DNS servers within armbian-config, then I need to pursue this further. Something is broken somewhere. If this is the way it is supposed to be, perhaps I could contribute some additions to the documentation when I get time. When I have a bit more time, I will edit the first post and indicate solved etc. Q

UPDATE: It looks like my issue boils down to the question: Should Webmin be available from the default sources used by Armbian? Other packages are accessible but without webmin I am inclined to find another variant where Webmin can be used easily... If yes, how can I troubleshoot APT config? It isn't finding webmin. If no, why? Webin seems quite popular - even in this context. It would be helpful to know why those who know Armbian best would want to avoid having it on the platform. Q

1) Agreed. 2)Not hurt. As indicated, following up with a serious and respectful response makes it a little clearer as to the intent - but only a little. Making a generalization here so --CAUTION-- Prickly responses to help requests count heavily against the platform (in this case Armbian) in the mind of new prospects considering investing their resources in the endeavor. That really does "hurt" everyone! Moving on. Thanks for the link and comments networking and DNS resolution. I will review. As I was thinking about how ping works after the fact, it made sense to me that when ping gets a DN it would first pass it off for DN resolution and then ping the resolved IP addr. that was returned. It may not be that simple or even correct, but It is a reminder to me to not focus too intently on one thing. The bigger picture is still important to keep in mind. I was reporting that armbian-config seemed broken a little so this is confusing. Did you mean "...does not do... suposed to do... "? I was anticipating a link to a bug report - 'till I read further. Q

Tido Thanks for your comments. We agree. I also think you would agree that holds true for M.2. So the remaining question is, can eMMC be used easily and effectively in this context only as a RO store and does it offer any significant gains in terms of a "responsive" system. Also, in my book, reliability means in part, the system doesn't go down because of wearout that could have been detected (S.M.A.R.T.) or avoided altogether. While I need to understand this aspect more, I had read that RAM is used for logs. One of a number of reasons I decided to try Armbian. Assume you mean hot. You would not believe the amount of CAT5e in my house for this reason. You can't ever beat wire when lots of devices need low latency relatively secure communicaton and power. A complex subject for another time... My take on speed is that the higher the latency the greater the possibility that the user will end up sending multiple commands -not good, though good software design should handle this. Also, the lower the latency, and faster the processing the easier it is for example, to make things like IR remotes work transparently. Consider using a random IR remote set up to adjust "the volume" in a room. Only the user and the HA system know the context - what system in the room is making sound. In this context the HA relieves the user of the need to select the correct sound maker. HA tracks and translates transparently - how's that for alliteration? The less time I take from I to O for my HA is also more time that slow adapted devices can use and still allow me to achieve a near real time experience for the user. Consider a 2 second delay in a video link. It is very challenging to make that conversation work without collisions. When one side of the conversation is actually a dumb computer and the other an impatient human it wont be pretty for the computer or the person that set up the computer! And I don't see a design in which all crashes happen in slow motion as a solution to the problem either As far as chatty goes, while this can be eliminated it is of course better to handle in a way that is fast, doesn't compromise real time performance (write bottlenecks) or stability/reliability (flash wearout) so, best addressed at the beginning of the project. Q

SFX2k Wrong as it may be I followed the documentation here getting started which under I attempted to use the options offered there. I came back to the forum just now after I noted that there is another DIFFERENT way shown to update farther down the page to update. I understand that documentation is a challenge to keep up to date and perfectly correct but it is also unhelpful and impolite to point out someone's error when it was a result of faulty directions they relied upon without also acknowledging the bad directions. Further, it is less helpful to others tripped up for the same reason that are searching for help. Far better to simply point out that the menus for network configuration in armbian-config don't work (at the moment) and that farther down the page there are different directions that should work(they also don't appear to fully solve my problem by the way) . Now for the update: I restarted board after using nmtui exiting, re-entering and seeing changes I made stuck, rebooting and once again re-entering nmtui to verify. I do see an IP address (I don't recall seeing that before - will check) so that suggests that DNS is now accessible but APT still messed up. UPDATE. I was using a bad ping target. PINGING domain names does work - for sure after using nmti to configure network. I don't do this every day but I think I have used nasa.gov in the past for a ping test. It has been a while since I have had to solve this kind of problem though. root@HAL_Mk1:~# ping nasa.gov PING nasa.gov (52.0.14.116) 56(84) bytes of data. ^C --- nasa.gov ping statistics --- 12 packets transmitted, 0 received, 100% packet loss, time 11267ms Q

Guidol, It may be just as easy to corrupt eMMC but wouldn't it be far less likely to happen if the OS wasn't writing to it as a matter of course? Also, my stated concern was not corruption per se but wear that would render the memory useless and I think, the entire board because The eMMC contains the bootloader. I also expect that I should be able to restrict write access as root and mark RO for the OS which would further protect it. If true that makes an even better case to use just the USB connected M.2 device for storage - equally easy to deal with as the TF card. Again, the only reason not to in this case would be because of a significant performance hit - that is the answer I am looking for. Q

I was not referring to the port number but the signalling protocol being used as it plays a key role in determining performance of the storage system.

Point taken Guidol. Sorry for the confusion. Correcting here and elsewhere...

Greetings all, See my last post in thread for method I found to get around issues. EDIT: This may be limited to is an apt issue DNS seems ok after all. Use nmtui to edit network config not armbian-config None of what follows should be taken as complaining. I am only trying to get some help, give some observations from a non-expert viewpoint and possibly help ID a bug. Not being an expert, I am looking for confirmation. I am trying to get the NanoPi NEO core-2 LTS set up and am having some issues with apt. I haven't gone past that because the first thing after getting properly booting install (for me anyway) is to install webmin. This makes it relatively easier for me to have visibility into the system, edit config files etc. etc. My /etc/apt/sources.list seems to be correct but when I do apt install webmin I get "no candidate". on another system running Linux 4.14.0 on aarch64 (also a FA NanoPi NEO2 (+) variant, the webmin package is there. apt clean, apt update, apt --fix-broken install have all been done. I changed to GB sources in armbian config utility but that domain wasn't responding. The other system is using dietpi, is on the same network, uses an identical sources.list (for all intents) and works fine. This is what lead me eventually to look at DNS and network as possible causes. Using armbian-config, I set my system up with static IP and if I found a place to enter dns I use 1.1.1.1 and 1.0.0.1 (I don't use domain names inside my network) . I couldn't find a place to do that. If I ping google.com from command line on NEO, it works. If I ping google.com I get a response. if I ping nasa.gov I don't (more later).EDIT: This was a bad ping target. I wasn't watching closely enough to see that dns resolved the IP and that the IP is what gets pinged directly. I learned something today! I tried editing nano /etc/NetworkManager/NetworkManager.conf and replacing dns=default with dns=none and then putting entry for 1.1.1.1 in my resolve.conf. to no avail. domain names are working for the rest of my network so I am inclined to think something is wrong with this particular system. I do not use IPv6 so I opted to turn that off in armbian-config (I don't understand why apt and IPv6 are associated). Again, IPv4 static IP, correct gateway IP, correct mask, and I could find no option to enter DNS servers. Wifi is not in use Wired does work at least a little (I can ping google). But beyond that I am not confident in the state of the network configuration. When selecting clear network interfaces I did see DNS masquerading option not loaded error. It is not clear to me if that is important. I also went to "advanced|edit /etc/network/interfaces and the file shown has no entry for eth0 but does have an comment "#Network is managed by Network manager" along with the local loopback entries. There seems to be an issue with the armbian-config menu system (at least in my mind) in that when selecting an action, the only route back from any action is to cancel. This is not optimal - or I am missing something here? For some menu items the current status of the item is displayed as part of the menu (enabled vs disabled) for others, it is not and when you select the menu item (select static vs dynamic) the screen refreshes to show enable and disable options but does not indicate the current state. Cancel does what in that case? Also, I tried reverting to dhcp and leaving IPv6 disabled as indicated in config menu. After reboot IPv6 address is present in Ifconfig (below)! Still disabled in Armbian-config. Toggling IPv6 does remove IPv6 address from ifconfig but only 'till reboot. Disable does not survive reboot. Regardless of presence of IPv6 address, I am unable to ping nasa.gov but can ping google.com. Again, both visible from other devices on my network. not working eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.114 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::XXXX:YYYY:1cc:1220 prefixlen 64 scopeid 0x20<link> # I mangled address ether MAC REMOVED txqueuelen 1000 (Ethernet) RX packets 1729 bytes 185731 (181.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 169 bytes 14605 (14.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 24 Working Nano eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.149 netmask 255.255.255.0 broadcast 192.168.1.255 ether MAC REMOVED txqueuelen 1000 (Ethernet) RX packets 4295815 bytes 468858671 (447.1 MiB) RX errors 0 dropped 2467577 overruns 0 frame 0 TX packets 38465 bytes 22491765 (21.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 28 Seems like there are two separate but closely related issues here. Control over IPv6 and DNS. With a third less critical being ambiguous configuration menu functions and display. Thanks for taking the time to read this far. Hope you can help. Q