lanefu

yeah i'd love to see that.. a solder your own PCB would be great... are there any funds in the treasury for a token bounty?

This might be close https://docs.ansible.com/ansible/latest/plugins/connection/persistent.html

Yep that's pretty much the vision i had. Inspired by 8-Channel 5V Relay Shield Module Board Optocoupler module Arduino ARM PIC AVR https://www.amazon.com/dp/B01ARS8OVQ/ref=cm_sw_r_cp_apa_i_1qVmDbG1TMZ8B The allwinners have like 4 uarts. Ive read bitbanging uarts is possible but a i2c uart expander or something is probably saner. I think making a ansible serial Connection plugin would be the ideal way to interact with OS Now that i think about it. Just logging serial then using ssh should be more than fine. If the network doesnt come up, then it fails the test

I was able to read a DHT22 on PA10 with my Orange Pi Prime using https://github.com/Jeremie-C/OrangePi.GPIO Minimal documentation provided in readme https://github.com/lanefu/DHT22-Python-library-Orange-PI

The file handles are probably still being held open by the service. try systemctl restart havegd and see if that releases them also whats output of systemctl status systemd-tmpfiles-setup.service

I've got a pocket C.H.I.P. and its just such a neat device---I still haven' t thought of a good use for it. The Next Thing guys had a lot of style.. I really like both generation Opi Ones. a lot of bang for buck.....both slighty lacking in the USB department tho... just one more port would have been great. (OTG doesnt count)

My list of arm boards was too long to make it a tasteful signature so here's some highlights: My List of geek Stuff 3xOpi Plus2e - hashi cluster servers Opi Prime - main work area (screen, ssh vim, git) OrangePiOne plus - hashi cluster worker Le Potato - tester Atomic PI - desktop Tritium-h5 - tester Opi PC2 - tester Opi3 - tester Espressobin - tester Helios 4 - 2ndary NAS Orange Pi R1 - tuyaconvert Opi Lite - retrorangepi R69 retrorange pi Opi One - root cause of my SBC and Armbian addiction Frankendell i7-2600 - garage computer and build box Dual Xeon E5-2650 v3 - new build server Synology 1815+ Primary NAS Edge Router Lite - Router Do you want to share highlights of your Arm empire?

haha.. I just built another image.. and now I can't reproduce... must have been another quirk with that bad rootfs image thanks for checking @Werner @martinayotte

OpiOne uses different kernel config tha sunxi64 OpiOnePlus uses different patch dir than sunxi64

build fresh dev image from master or OrangePi PC2, build fresh filesystem.

any concerns with above @martinayotte?

A clean rootfs and for 5.2.1 i had a slight change to kernel that was causing bootfailures immediately after thenkernel.loaded.. id say its unrelated https://github.com/armbian/build/pull/1458 Watch your build and make sure it doesn't download a rootfs. Im hoping[mention=1]igor[/mention] will kick off a new build if he gets a chance and then we wont have to worry about it anymore Nm looks like he's got a build running https://github.com/armbian/build/issues/1457#issuecomment-511304728

This issue resolved itself with a new rootfs during build. Sent from my iPad using Tapatalk

Hey Wanda I found this. Not sure what it would take to reconcile. https://github.com/armbian/config/blob/167e0dc2d81a2327c05740c5abfc6fa1fd99f9d9/debian-config-functions-network#L613 Sent from my iPad using Tapatalk

Ask a moderator to delete Sent from my iPad using Tapatalk

Hmm . odd try this k1 plus image

sudo rm -rf cache/rootfs/buster-cli* sudo ./compile.sh EXPERT=yes BETA=yes BOARD=orangepipc2 BRANCH=next RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no EXTERNAL=yes CLEVEL_LEVEL=cache USE_TORRENT=no ROOT_FS_CREATE_ONLY=FORCE sudo ./compile.sh EXPERT=yes BETA=yes BOARD=orangepipc2 BRANCH=next RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no EXTERNAL=yes

Ran into an issue with selinux. it causes init to hang because it cant find /lib/aarch64-linux-lib/libaudit.so.1 the difference appears to be next this configured and dev doesn't CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0 Worked fine once i readded config option https://github.com/armbian/build/pull/1458

@ch3510 Try this image i built with fresh rootfs

@Tido Everything is here now.

..and the other part of the conversation that I tried to move in the first place. I haven't tested it so I don't know if that will help, but there's a tool named "LAVA", used by the Linaro folks, which is basically a CI agent devised for ARM boards and software testing. https://master.lavasoftware.org/static/docs/v2/index.html#lava-overview Besides having special images, we could have "nice people" who accept to register their agents for running integrations tests on them. Or set as a default feature on nightly images or when attached to beta repository? Yeah that would be good... although I think it should still be 'opt-in' . People get weird about their OS reporting without their explicit permission...just have to make it an easy choice. I guess that's a good thing to survey. Well, the two options : Running images clearly labelled as "Automated tests images that test, collect and send data back to a remote server" Allow any user to run a special script that run tests, and send the data back to the server with their consent Could do the trick. Running the test automatically on "nightly images" or "beta images" might lead some insane people to throwing a tantrum and firing GDPR requests, because data are collected from their hardware and sent to a remote server, without them be 'clearly informed' and without their 'consent'. Given how long you're running this forum, I don't have to remind you that insane people will *always* find a way to download "beta nightly images", run them without second thought, and throw a tantrum on the forum because THESE IMAGES ARE NOT STABLE AND ARE STEALING THEIR PRECIOUS DATA. ...yeah that's definitely a concern.... and thanks for reminding me about GDPR. Yeah... Though, when I see how the European Data Protection Board handles GDPR requests, (Want your data removed ? Show me your ID !) this isn't as threatening as it seems. Just make sure to have a script that can remove test data related to some user ID. having a new forum badge.. TESTER... People love to hunt for badges.. or a supporter badge in pink.. OK, I definitively need a nap.. I raise another step - improve QUALITY ASSURANCE without human interaction. I know, new features are more fun to integrate, but this is also a feature :-) What kind of code (script, C, others??) and which checks are available that can support the human I think @Igor linked that, at least I saw it here somewhere https://github.com/koalaman/shellcheck A Lint-Checker Lint is a code scanning tool to identify, suggest and correct the wrong or the risky code present in the project. There are ones for many different languages. TRAVIS CI - add your idea For the integration, do not spend to much time, just setup so it basically works and improve it over time - I am talking about tools that are free for FLOSS projects - don't get me wrong please. https://github.com/marketplace Lust but not least a nice badge on Github I thought about opening a new thread for Quality Improvement - so feel free to move it where it belongs. No intention to hijack this thread. Shall we ask in public what other ideas the crowd has of tools we don't know ? I do like the bash linting idea. Thats a pretty obtainable goal. I did kick off a Public thread about testing a few months back. There are some good ideas there. We do have an open role for "testing / code quality" are you that person? As for as traditional CI/CD testing with something like Travis CI, i think were a long way from that. The sheer size of the depency chain and the length of the build time isnt really a good fit for their free offering. The code base would need a refactoring strategy to get there. That being said... Armbian is unique, so we need to come up with some unique solutions, including figuring out what it is that we actually want to test rather than follow established models oriented around building microservices. Check out some of the testing stuff linaro has. I think we should get more involved with them as a whole. I thought if the team is small, automatic testing tool can support. Now as you mention your thread I remember, but it lead nowhere by now. I am looking for low hanging fruits, while your ideas are good, they look like a lot of work to me. To little know how over the whole project (all the scripts and folders) and Github per se. The idea from @chwe was okay, but to solve it via github wasn't smooth. As you wrote it needs a simple server to collect and reflect this data (some unique solutions). TRAVIS was just as an idea, a starter for brainstorming or so I don't know linaro, I mean I heard of it but that's it. Sorry for not having better news. you mean? https://github.com/armbian/testings The idea behind having this on github it that others than the usual suspects contribute to testing (everything more customized would fail for sure, except we could use forum credentials).. It has to be easy as hell without even thinking what're you doing. If things are complicated and if you give the testers more possibilities than yes or no, I'm confident that you don't get any contribution at all. We had 15 different contributors on the repo and around september, november last year it basically worked (most of them pushed around this time - I started my thesis in november so I hadn't much time to push it further). I still think it can work.. it needs an enhancement and more publicity before releases so that people actually do it.. But it needs some force.. All those software tools are nice to look at code.. Problem is.. our work doesn't fail then.. it fails once it's on hardware.. Hardware testing must be done on hardware.. and is probably not as easy to automate (testing wise).. So the 'only' part where software helps us there is on the buildscript related part (so basically this thing must only understand bash, and besides the obvious stuff $VAR should be ${VAR} those tools can't help much - prove me wrong!).. Soooooo what if we also produced special "test" images.... and those would be built with a different customize_script.... and could just self-test on boot and phone home a report. and that's all they did....no other functionality.... all they do is burn image to sdcard, plug in ethernet, boot, and then its done. That way novice users could help contribute just by running the test image.

gotcha.. i should have said USE_TORRENT=false instead of ROOT_FS_CREATE_ONLY anyway i'm testing again myself. something went amiss

Did you clean your cache and do ROOT_FS_CREATE_ONLY=force ? i did notice that when I did the ROOT_FS_CREATE_ONLY=force it stopped after making the FS, so then i ran again without and it picked up the FS

So i wasnt able to duplicate on a fresh build.

created issue https://github.com/armbian/build/issues/1456