lanefu

Created Issue: https://github.com/armbian/build/issues/1456

remove from build/cache/rootfs and also build with option ROOT_FS_CREATE_ONLY=force

I'm going to create a bug and track it in github since we seem to have a trend now..... I've got a PC2 adn a bit of time today, so i can try to debug.. are we gettign reports for other buster builds besides PC2?

May be out of noob territory now you'll need a TTL adapter http://linux-sunxi.org/UART#Before_you_start

Can you provide serial console output

Which images did you try? Did you use a stable image from the downloads page?

Would you mind running TK's SBC bench? https://github.com/ThomasKaiser/sbc-bench

I ran zoneminder for about a year or so. Its neat, but its architecture is slow and outdated. I had to build from a feature branch in order to actually store h264 streams rather than mpeg. Personally I'd steer away from it, and focus on cameras with their own motion detection, video shipping, and a decent api. (Amcrest falls in that category)

https://github.com/orgs/armbian/projects/1

Hmmm i guess that adds up.... They do ship it via DHL from Korea and arrives pretty fast.... I ordered may 10 and it came may 15th.

Hey @Tido !!!!!

You are cutting and pasting, correct? I wish i had a terminal client for the forum

Ansible is the magic word... What steps specifically do you need to automate? ....to your point armbian config won't help... the device tree overlay step is updating /boot/armbianEnv.txt so lineinfile is your friend for that. Here's a few more breadcrumbs for armbianEnv.txt https://docs.armbian.com/User-Guide_Allwinner_overlays/#armbianenvtxt-entries-reference

Dude, Don't be so harsh. Maybe this will offer some perspective https://docs.armbian.com/#what-is-supported

....but you have a fantastic username

Freeze your kernel in armbian-config may be a good idea.

Speaking of testing... I now have a nomad job that lets me dispatch parameterized runs of armbian builder for CI Need to work on applying patches from github PRs then I can probably integrate.

note: This is from a previous thread about testing, I accidentally moved it, and this was the only way to resume the conversation --- Just kicking off a thread here to talk about different ideas around testing. It would be great if the community could help test more.,,, but what would it look like.... maybe end users can burn a test image and run a test script. the script could do cool things like: * spi loopback test * check for healthy kernel modules * look for dmesg errors * test wifi * test ethernet * test audio? * even run a phoronix test of somesort to validate a particular feature. Are there any simple circuit diagrams people could design to make testing easier... i2c testing? bitbang something into the audio input? who knows. well, in a way they do via complaint. ;-) A lot of parts need some sort of script, amlogic BSP kernels (not Armbian) are tested in such a way (perform 1000 reboots, etc). That I can aid in, but the typical user probably won't have the sorts of things needed. https://github.com/armbian/testings That'd be awesome! I'm coming from the perspective of creating more opportunities and interest for the undiscovered non-typical users. was a nice starter, unfortunately nobody contributes to it and the testings there are really outdated.. I did some tests back then to automate testing (actually it was one of the use-cases I thought about for my BPi-R2 (using its serial from the pinheader to connect them to the serials of the tested boards) doing automated upgrades and check if network comes up, in case not it would try to log-in via serial.. automation has some issues.. e.g. properly filter dmesg issues is hard cause different drivers tend to float dmesg with different errors so it's hard to filter them properly.. You also need some way to powercycle the board (e.g. reboot and powercycle are different things in case of a proper reboot - BPi R2 boots up properly when you powercycle it from eMMC, whereas it doesn't with a simple reboot.. ). The idea is great, and we need more testing break due to bad testing is something we had to often... I'm willing to test new images on the boards I've got. Maybe you could make a checklist with all images that need to be tested. Once tested you check, and it's removed from the list and can be put on download page. You could also do a button at the download page to let users download the test image, and ask them to give test results. Just an idea. actually the basics to test are there.. cool so since this a brain storming thread. i wanna try to stay away from thinking about process. This is more about thinking of creative ways to do testing. I didn't see that page. I will use it for my next tests now! Hi, I tried to push my testing of pineh64-dev compiled from today, but have no access to armbian/testings.git Is there something I have done in the wrong way? As you can see I tried 3 times and even with '-f' it does nothing. I tried to push manually but got this error: If you are out to test the full functionality of a modern Linux distribution such as Ubuntu including multimedia capabilities, etc, it's quite difficult (I really mean it's rather impossible) to write a script to do it. There are quite simply too many possible use cases. Not even Ubuntu people do it for their x86-64 images. They rely on tens of thousands of users to report on possible bugs. Personally I test my Amlogic TV boxes running armbian / Ubuntu 18.04 by running a distributed kernel compilation on them. That tests the network functionality, roughly tests the kernel and memory for stability, roughly tests the ext4 filesystem on the SD cards, test the basic functionality of Ubuntu 18.04 on Aarch64 hardware, and... that's it. I am happy to report that for my use case, Armbian Ubuntu has shown exceptional stability on some of the cheapest hardware one can find on the planet. did you clone your fork when testing? Or did you follow this one? git clone https://github.com/armbian/testings cd testings ./createreport.sh createreport.sh was glued together relatively quickly (I know it cause I wrote it.. ) and its git remote handling is a bit hacky (e.g. upstream and origin).. If you clone from your fork things mess up quickly and then it tries to push directly into armbian/testings for which you don't have commit rights.. I didn't test it recently (just moved a few days ago and more or less all my SBCs are somewhere in boxes.. ).. Once I've a bit more time I'll hopefully clean it up a bit.. can you give me the output of: git remote -v? My angle more about any testing vs no testing. Ya i mostly care about like not seeing dmesg full of noise etc.... extra credit for spi and i2c and technically the gpu, and hardware encoding and decoding could be tested headless. Oh yes, any testing is way better than no testing. Perhaps document a systematic testing procedure and leave it to the hundreds of Armbian users to do the testing and report on results back here in the forum? I would suggest that would be the better approach to this. Right now most people only bother to report when they have a problem, not when everything works fine for their use case. Yes all your points are true, and there are at least some pieces floating around that could be tied together and documented. I was trying to keep this thread on the creative side and not on the process side. Ex: I have a 4 channel relay board and a bag of solder on USB A sockets and the allwinner H3 has like 4 uarts in it. If we tested images via usb booting its possible a test image could be mounted on another SBC and delivered via usb gadget mode from the OTG port. That's a little bit complicated, I guess. A much, much simpler approach to testing Armbian images is to network boot them. But then you are not testing an essential functionality that most Armbian users depend upon: the ability to boot from an $4 micro SD card. Yeah nfs root is would be way simpler. Main advantage to the theoretical usb boot would being able to test uboot on the image. Can you chainload uboot from uboot? I don't think that's officially supported because both u-boot's would want to load at the same address, so the second one would load on top of the first one and the boot process would crash. I see there has been some discussion of this in the u-boot mailing list, but you'd have to ask if there is any recent update on this issue. Also note that some SBC vendors are shipping their boards with u-boot pre-installed on SPI ROM (afaik, Khadas and Libre Computer). I follow these instructions, but when executing the script it creates a fork on my account. Here is the result of git remote -v: jeanrhum https://github.com/jeanrhum/testings.git (fetch) jeanrhum https://github.com/jeanrhum/testings.git (push) origin https://github.com/armbian/testings (fetch) origin https://github.com/armbian/testings (push)

Thanks @Igor for creating the other notecards. I was able to clean them up and turn them into issues. I've assigned this thread an RFC.... ironically RFC 001 because I used the github project ID rather than an issue to reference. https://github.com/orgs/armbian/projects/1 In this thread we identified 2 RFCs, but really it was 2 major tasks needed to achieve the 1 goal. so the RFC is both combined. I adjusted the name to align more closely. (Build Framework Rework - simplify compilation.sh) I'm defining the acceptance criteria for this project to say its done as: Customizations needed after kernel patching and before compile are external to compilation.sh Code for building BSP packages is no longer in compilation.sh Assuming the acceptance criteria above is agreed upon... Feel free to create as many notes / issues as you like to help us get this done.. If you're able to break things down so that more of us can work on it at the same time the better.

I've made it easier to apply RFC tags on the forum itself. That will make it easier to search. A slight tweak: Instead of assigning a [00x] sequence number to "approved" RFC, I'm going to give RFCs the issue number generated by github.

I finally made rfc tags work better

If you have a bit of experience or interest in doing a simple mkdocs theme. Please let me know.. I'd really like to get our Doc Site to match the rest of Armbian.

try dpkg-reconfigure ca-certificates

Yep. Makes sense... Once direction and feasibility is agreed upon, implementation details and progress should be in github. Also makes sense.... will take a little brain power to go clean things up, but should be fine once we get in the habit...... I'll have to document policy as well.

Yep thats the general idea. Notecard is a placeholder for planning.... you can right click a notecard and turn it into an issue