[TEST] Team testers?

[wildcat_paris]

thinking of http://forum.armbian.com/index.php/topic/2043-lamobo-r1-520-swconfig-problem-with-last-520-armbian-update/?p=15773

 

We may ask the forum users and create a list of testers for each board (or family of boards)

 

=> we could create a sub forum Armbian/Tech/Dev/Armbian build framework/Testing/

- to call for testers when needed (testers would register a pined thread managed by Igor/Mikhail/Thomas/others)

- to report testing on the forum using a title like [5.20/Lamobo-R1] "Status" (OK/KO/minor issues)

- create bug reports in appropriate forum

 

each registered testers creates its minimum set of test (like testing the switch config of Lamobo-R1) and create a thread as a reference

 

(just an idea)

 

 

 

 

[Igor]

Yes, we could (formally) engage more people into developing process as testers. It could be helpful and we would be little relieved.

 

Perhaps we start to seek & assign few testers / maintainer for each board? We can provide access to daily upgrades to make things easy on technical level. I can provide extra repository (aptdev.armbian.com) with daily updated deb packages, while creating images takes way too much time for daily builds. I am already working on this for some time and it's not far away from running it daily.

 

Subforum "Development" is not that busy, so we can have those things here.

[wildcat_paris]

I would help for Lamobo-R1 Odroid XU4

[pfeerick]

I can help for the Pine64...

[tkaiser]

We can provide access to daily upgrades to make things easy on technical level. I can provide extra repository (aptdev.armbian.com) with daily updated deb packages, while creating images takes way too much time for daily builds. I am already working on this for some time and it's not far away from running it daily.

 

I still think it would require some 'passion' on the tester's side since while testing with daily upgrades we might be able to catch problems like brcm40183-patch easily (and more early) a responsible tester would need to maintain more than one installation to be able to test through the 'normal' upgrade process also prior to major updates like this now. So given two kernels and two distros are affected as with most of our devices 5 SD cards are already needed (one for the 'daily' stuff and 4 to test through 'major upgrades'). Let's see how many people are willing to do this.

 

And with devices like Lamobo R1 it gets even more difficult since it really seems people are crazy enough to rely on this crapboard for routing purposes and NAS combined. A responsible tester would need a second R1 to test through possible upgrade scenarios (u-boot might cut SATA power, new kernel driver might affect networking in an unreliable way) and also some sort of a lab setup to test whether the advertisement claim (routerboard) works... which is not the case anyway. So good luck.

 

In other words: with more volunteers involved we might catch a few more bugs prior to release but still won't be able to guarantee 'hassle-free upgrades' as some seem to dream of.

[Da Alchemist]

I am willing to help, but i do not know if my Linux knowledge is sufficient.

 

Orange Pi Pc

Orange Pi +2e

Odroid C2 (without emmc)

 

Regards

[zador.blood.stained]

We don't have to test anything every day or even every week. Testing is required mostly when bumping u-boot and/or kernel versions and before releasing new packages and/or images.

[balbes150]

Interesting to see the list of boards\models needed to participate in the testing (which must tested).

 

 

 

 

IMHO Sorry, I may not know much and write nonsense regarding the features discussed in this topic boards\models. If you do not need to test specifically work with SD\eMMC. For tests does not necessarily need SD\emmc carriers in large numbers, they can replace the cheap USB flash drives or drives (separate partitions). One SD\eMMC will be needed to start the boot loader (if the Board is not able to boot from USB). Alternatively, you can use TFTP . U-boot is able to start the system from the network. Linux Live-CD (x86\amd64) USB stick with the configured TFTP and a set of test images\system (for arm\boards aarch64\models) for normal PC + microops to SD\eMMC with this TFTP configured bootloader.

[zador.blood.stained]

Interesting to see the list of boards\models needed to participate in the testing (which must tested).

From what I remember:

• Cubieboard 2
• Lime2 and Lime2-eMMC
• Some i.MX6 boards, don't know much about them so can't say more specific
• Pine64 (512MB) and Pine64+ (2GB)
• Different revisions of Beelink X2
• Roseapple Pi (?)

 

If you do not need to test specifically work with SD\eMMC. For tests does not necessarily need SD\emmc carriers in large numbers, they can replace the cheap USB flash drives or drives (separate partitions). One SD\eMMC will be needed to start the boot loader (if the Board is not able to boot from USB). Alternatively, you can use TFTP . U-boot is able to start the system from the network. Linux Live-CD (x86\amd64) USB stick with the configured TFTP and a set of test images\system (for arm\boards aarch64\models) for normal PC + microops to SD\eMMC with this TFTP configured bootloader.

• On most boards you need SD/eMMC to start u-boot and feed it with initial configuration, with exception for most Allwinner boards that can use FEL mode or SPI flash for this purpose (SPI Flash support needs to be explicitly enabled in u-boot configuration for this to work)
• For TFTP you also need Ethernet support in u-boot, otherwise you'll have to load kernel, initrd and DTB from storage too
• Whether using root on NFS can be used for finding regressions in packages or OS configuration, booting whole images from SD card should still be done before the release to properly test u-boot and boot script, especially if we start moving towards UUID based filesystem mounts

[balbes150]

IMHO This is only theoretical reasoning. To start the system, it is enough to have a small, static (not changed) u-boot on any carrier (that supports the fee). Creating and debugging such a minimum bootloader (with source) not a difficult task. In normal use the Board user - use your (not limited) media may large capacity, fast and expensive media. Testing the second (separate) media (with a simple, small and cheap) with a predetermined and virtually unchangeable by the loader. To start the predefined script with possible media (flash drive, network, etc.). Survey \ activate predefined list of carriers (in order of priority) and look up the script with a predetermined name. Finds a script to it. His task is complete. This is the principle of the BIOS. And the scripts start the test images\system - can change forever. Loader itself and its variables are not changed (except the upgrade test system), and then resource it read-only. Perhaps I am mistaken, but as far as I remember - network support long been integrated into u-boot and is supported by all manufacturers boards (this is a common debugging tool and development). For testing and debugging the UUID is not the best solution, it greatly limits the possibility of a simple copy of the rootfs and other partitions on arbitrary media. This area is better suited LABEL. On the one hand is the uniqueness of the determined desired media, on the other - is easily managed and edited by conventional means.

[zador.blood.stained]

This is the principle of the BIOS.

Which none of the boards have, and thus they support only limited number of boot media for SPL and u-boot. And you still have to test u-boot and standard boot script.

 

For testing and debugging the UUID is not the best solution, it greatly limits the possibility of a simple copy of the rootfs and other partitions on arbitrary media. This area is better suited LABEL. On the one hand is the uniqueness of the determined desired media, on the other - is easily managed and edited by conventional means.

So if you have system on SD for testing, on eMMC for everyday use and on connected card reader because why not (i.e. forgot to disconnect) rootfs by label won't be the most reliable method for testing.

[balbes150]

U-boot for the boards, there are no command "autosrc usb mmc emmc bootp" ?

 

The tester, who does not know that it is happening in the system (which carriers and why they are used) ?????

Better not to have such testing.

 

About the pros and cons of LABEL. Suppose such a scenario. Recorded image on the SD card of 16 GB . Checked. Works. Decided to move on the USB flash drive of size 8 GB. When using LABEL. Simply copy all the directories and files (as is) to a new medium. And assign a LABEL. Made changes to the system during testing. Created archive. Then deployed on any medium, even smaller (considering the size of the files). Can be easily transferred to testing by other users of the entire system "as is" for any media. I do not impose. I just share information. By the way, if the console UART, write and debug the script  - not difficult. When you work (if using) on other boards it is rarely necessary to edit (console UART is not needed). Enough to rule the working scripts, which defines all the features of the system startup (which you can change). This algorithm is already well established.

[zador.blood.stained]

U-boot for the boards, there are no command "autosrc usb mmc emmc bootp" ?

You can edit default environment or default boot sequence (via patches), but I think we don't understand each other.

 

The tester, who does not know that it is happening in the system (which carriers and why they are used) ?????

Better not to have such testing.

Main purpose of testing would be "here are pre-release images, please write them to SD card and check if they boot fine". If images don't boot we have to build them and upload them again, issues that don't affect boot process can be fixed after the release i.e. by upgrading packages.

 

About the pros and cons of LABEL. Suppose such a scenario. Recorded image on the SD card of 16 GB . Checked. Works. Decided to move on the USB flash drive of size 8 GB. When using LABEL. Simply copy all the directories and files (as is) to a new medium. And assign a LABEL. Made changes to the system during testing. Created archive. Then deployed on any medium, even smaller (considering the size of the files). Can be easily transferred to testing by other users of the entire system "as is" for any media. I do not impose. I just share information. By the way, if the console UART, write and debug the script  - not difficult. When you work (if using) on other boards it is rarely necessary to edit (console UART is not needed). Enough to rule the working scripts, which defines all the features of the system startup (which you can change). This algorithm is already well established.

I don't want to argue with your logic (and it seems like we are talking about different things), but "unique" part of UUID is a big advantage for me to consider it as default method for mounting filesystems.

[wildcat_paris]

I don't want to argue with your logic (and it seems like we are talking about different things), but "unique" part of UUID is a big advantage for me to consider it as default method for mounting filesystems.

 

I can only agree.

 

UUID will be very helpful when testing to boot a new image on SDcard while having a working system on eMMC (where you cannot remove the eMMC flash memory -- I only know hardkernel doing removable eMMC)

[wildcat_paris]

This area is better suited LABEL. On the one hand is the uniqueness of the determined desired media, on the other - is easily managed and edited by conventional means.

I forgot about your message and when testing with UUID on XU4 with recent uboot & vanilla kernel, I strangely moved to LABEL & tested and I found it very simple. Far easier to manage than the "random" UUID

Thanks!

[tkaiser]

Back to the original topic of this thread: There's something we need help with: https://github.com/igorpecovnik/lib/issues/493#issuecomment-252751466

[Igor]

Plus one testing job on XU4 since mine is in production: booting with initrd on default kernel.

[zador.blood.stained]

Also libvdpau-sunxi patch needs to be tested on A10 or A20 board (to check if dark video problem is correctly resolved)