Jump to content

Armbian 22.05 (Jade) Release Thread

Igor

By Igor
in Armbian Project Administration

 Share

Recommended Posts

Igor

Igor

Posted
  • Author
Posted

Locales problem again - are you seeing this:

http://ix.io/3Yhy

 

Seems to be Debian bullseye thing, since Jammy doesn't have that.

 

 

Spoiler 
Choose default system command shell:

1) bash
2) zsh

Shell: ZSH

Creating a new user account. Press <Ctrl-C> to abort

Please provide a username (eg. your first name): igorp
Create user (igorp) password: ********
Repeat user (igorp) password: ********

Please provide your real name: Igor 
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = "en_US.UTF-8",
	LC_ALL = "sl_SI.UTF-8",
	LC_ADDRESS = "en_US.UTF-8",
	LC_NAME = "en_US.UTF-8",
	LC_MONETARY = "en_US.UTF-8",
	LC_PAPER = "en_US.UTF-8",
	LC_IDENTIFICATION = "en_US.UTF-8",
	LC_TELEPHONE = "en_US.UTF-8",
	LC_MESSAGES = "en_US.UTF-8",
	LC_MEASUREMENT = "en_US.UTF-8",
	LC_TIME = "en_US.UTF-8",
	LC_NUMERIC = "en_US.UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").

Dear Igor, your account igorp has been created and is sudo enabled.
Please use this account for your daily work from now on.

 

 

jock

jock

Posted
Posted
19 hours ago, Igor said:

Locales problem again - are you seeing this:

http://ix.io/3Yhy

 

Seems to be Debian bullseye thing, since Jammy doesn't have that.

 

 

  Hide contents 
Choose default system command shell:

1) bash
2) zsh

Shell: ZSH

Creating a new user account. Press <Ctrl-C> to abort

Please provide a username (eg. your first name): igorp
Create user (igorp) password: ********
Repeat user (igorp) password: ********

Please provide your real name: Igor 
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = "en_US.UTF-8",
	LC_ALL = "sl_SI.UTF-8",
	LC_ADDRESS = "en_US.UTF-8",
	LC_NAME = "en_US.UTF-8",
	LC_MONETARY = "en_US.UTF-8",
	LC_PAPER = "en_US.UTF-8",
	LC_IDENTIFICATION = "en_US.UTF-8",
	LC_TELEPHONE = "en_US.UTF-8",
	LC_MESSAGES = "en_US.UTF-8",
	LC_MEASUREMENT = "en_US.UTF-8",
	LC_TIME = "en_US.UTF-8",
	LC_NUMERIC = "en_US.UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").

Dear Igor, your account igorp has been created and is sudo enabled.
Please use this account for your daily work from now on.

 

 

 

I tried the armhf tinkerboard bullseye RC image provided in the link before and have not seen the debian locale warnings.

balbes150

balbes150

Posted
Posted
21.05.2022 в 10:27, schwar3kat сказал:

I tried to clone the RC branch to try and diagnose the issue.  I'm not sure if this is correct:

Maybe I'm doing something wrong, but after switching to the right branch, it still helps me :

 

./compile.sh LIB_TAG="v22.05"

 

without this key, the system itself switches back to the master branch  :)

 

ps I would suggest for future discussion, get rid of this parameter in scripts and use a "dumb branch switching system" (i.e., do not check which branch the system is on and use the current one, without auto-switching, or just issue a message, but do not switch without "user permission").

1
Igor

Igor

Posted
  • Author
Posted
20 hours ago, balbes150 said:

without this key, the system itself switches back to the master branch


If its a bug, we have to fix it. Probably you need to set .ignore_changes ?

 

20 hours ago, balbes150 said:

and use a "dumb branch switching system"


Actions scripts are using this principle, so I didn't even notice there is something wrong.

Igor

Igor

Posted
  • Author
Posted

Today's RC build (images has just been updated) is first, finally, after two weeks of constant struggle (bugs in CI, bugs in build process, bugs in hardware) that was done almost without errors. Just a few images has to be re-done. Thank you all for helping fighting bugs!

Those need attention before release:
https://armbian.atlassian.net/browse/AR-1197

https://armbian.atlassian.net/browse/AR-1196

https://armbian.atlassian.net/browse/AR-1198

 

If possible:

https://armbian.atlassian.net/browse/AR-1186

https://armbian.atlassian.net/browse/AR-1186
https://armbian.atlassian.net/browse/AR-1176

https://armbian.atlassian.net/browse/AR-1158


I have manually (some via automation) tested: VIM1, VIM2, VIM3, Opi Zero plus2, Jetson Nano, Orangepi One, Orangepi Win, XU4, C4, C2, Cubox, Clearfog pro, Rockpi E, Nanoi pi M4, Opi Zero, Udoo quad, x86 UEFI

balbes150

balbes150

Posted
Posted
2 часа назад, Igor сказал:

If its a bug, we have to fix it. Probably you need to set .ignore_changes ?

IMHO this is "incorrect logic", i.e. this is "implicit" behavior, the concept of ".ignore_changes" needs to be changed to a "normal" variable with "explicit" behavior. I would remove this mechanism altogether, and make a "generally accepted" option for using GIT branches (when switching to any branch, only data from this branch is used, without automatic hidden switching to the master branch). The key ".ignore_changes" should be used in relation to the current changes in the current branch in the form of a service message with a user-only solution. :)

 

2 часа назад, Igor сказал:

Actions scripts are using this principle, so I didn't even notice there is something wrong.

Therefore, I propose to change this "implicit" behavior, it is familiar to those who know the system, but creates problems for beginners who are accustomed to the "generally accepted" ways of using GIT (switched to the branch, which means its code is automatically used). :)

 

1
schwar3kat

schwar3kat

Posted
Posted
3 hours ago, Igor said:

Today's RC build

Issues now resolved
orangepi-r1plus-lts - no issues observed.

Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz

iperf on both Ethernet interfaces produced expected results.

1
balbes150

balbes150

Posted
Posted

Tested M1\P1\M2\P2 T4 with core 5.17\5.18 no problems found. The fix for legacy has been sent.

I forgot, there is one problem - the old u-boot 2021.07, 2022.04 is needed (without this, the HDMI sound does not work correctly).

Igor

Igor

Posted
  • Author
Posted

Today I am making last RC build to check for troubles, Saturday, as planned, making a release ... in case there will be no major troubles. Bugs / last improvement are still going to be merged.
 

balbes150

balbes150

Posted
Posted

Question. Since many did not have time to fully test the new version of u-boot-2022.04 for RK, but this version is important for my models, is there an opportunity to use the first option that I suggested - to create an add-on.the u-boot-next version?

Igor

Igor

Posted
  • Author
Posted

Alternative  - checkout to branch 22.05, add your changes and send me u-boot packages that affect your boards.

ZazaBr

ZazaBr

Posted
Posted

Rock3A test with jammy build with kernel 5.17.5

WIFI:  -Qualcomm QCA9377 (5ghz/2.4gz and bluetooth), RTL8821CU(5ghz and 2.4ghz) , MT7601U chipsets are working. QCA9377 is somehow chopped 6mbit/s transfer rate, the others have nice performance for common tasks like upgrading the system and browsing. It should work tools for monitoring wifi like tcpdump and hacking with aircrack-ng.

-ethernet: its 1gbit/s, my router detects but I dont have gigabit internet provider to test downloads.

-docker can be installed in the 3rd softy modules option without problem as was in other kernel versions 4.19 and 5.10. Didn't test it at the moment, but I will certainly test and use it.

 

SYSTEM:

-Since I plugedd a lot of adapters, power drain was more than the average, so it rebooted the board somehow with 5v voltage and 3 amps available from the powerbank. The board becomes more at stable above 9v. 5v is for tasks that are not really demanding, watching the load from htop helped to see that.

-Using hdmi-vga adapter its still an issue, tried lower the resolution and the screen rate to 1366x768 60hz/30hz and 1650x1050 60/30hz but monitor still managed to turn off and on.

 

 Some stuff I will test more in this board, but at the time, this kernel suits well in this board for tasks using cli.

1
Werner

Werner

Posted
Posted

Since release images are made theoretically a bunch of boards are now to be dropped to CSC since maintainers failed either one or both of these criteria:

Quote
  • maintainer must participate in the Release Process
  • maintainer must sign-off that device has been tested, is stable, and ready for release during release process

https://docs.armbian.com/User-Guide_Board-Support-Rules/

 

However since this is the first release with the new support model and this may not have been clearly enough be communicated it is still to determine if the demotion is enforced this time.

2
schwar3kat

schwar3kat

Posted
Posted

orangepi-r1plus-lts - problems with the published downloads.

Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz -  bad image.  USB3 Ethernet not working,  torrent and direct.
Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz  -  no image available, torrent or direct.

Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz  -  working, no observed issues (torrent tested).
 

Igor

Igor

Posted
  • Author
Posted
6 minutes ago, schwar3kat said:

orangepi-r1plus-lts - problems with the published downloads.

Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz -  bad image.  USB3 Ethernet not working,  torrent and direct.
Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz  -  no image available, torrent or direct.

Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz  -  working, no observed issues (torrent tested).
 


Strange that bullseye works, but focal not. And RC images were alright, right?

schwar3kat

schwar3kat

Posted
Posted
4 minutes ago, Igor said:

And RC images were alright, right?

Initial RC images were all bad with the same issue USB3 Ethernet not working.  As if the quirk patch was missing.
Final RC images were all good.

Igor

Igor

Posted
  • Author
Posted
2 minutes ago, schwar3kat said:

As if the quirk patch was missing.


Check if you see anything suspicious here:

https://github.com/armbian/build/commits/v22.05
Some commits were merged at last moment, including EDGE upgrade on Rockchip since EDGE is not production ready kernel and was moved to 5.18 so in case it doesn't work in EDGE, this is not the biggest problem, but it has to work well in current.

Lets sum bugs in Jira and resolve this when possible. I already open a few minor ones.

schwar3kat

schwar3kat

Posted
Posted
3 hours ago, Igor said:

Check if you see anything suspicious here:

https://github.com/armbian/build/commits/v22.05

I don't see anything suspicious.  They all look safe.
I've opened Jira AR-1204

I tried a build from a clone of that branch using LIB_TAG="v22.05" and focal image worked.
No obvious differences between the working and not working images.
I wonder if this issue is similar to the first CI run that affected all three images with the same symptoms.

 

Igor

Igor

Posted
  • Author
Posted
13 minutes ago, schwar3kat said:

I tried a build from a clone of that branch using LIB_TAG="v22.05"


Did it really switch to 22.05 branch. I heard there are issues with this functionality and you need to manually switch before running the script.

 

13 minutes ago, schwar3kat said:

I've opened Jira AR-1204


Good. We'll deal with this asap.

schwar3kat

schwar3kat

Posted
Posted
7 hours ago, Igor said:

I tried a build from a clone of that branch using LIB_TAG="v22.05"

I think that it did switch, but I can't guarantee it. 
Previously when I tried unsuccessfully to build this branch, balbes150 showed me to use LIB_TAG="v22.05" to prevent it from switching.
targets.conf has your rock-3a changes, so I think it worked.

balbes150

balbes150

Posted
Posted
6 минут назад, schwar3kat сказал:

Previously when I tried unsuccessfully to build this branch, balees150 showed me to use LIB_TAG="v22.05" to prevent it from switching.

In such cases (when you need to use another branch), at the beginning I manually switch the branch (git checkout branch) and additionally, when building, I use LIB_TAG (you can immediately register it in the exlaple.config settings).

schwar3kat

schwar3kat

Posted
Posted

Orangepi Zero Plus - published images work.

Armbian_22.05.1_Orangepizeroplus_bullseye_current_5.15.43.img.xz
Armbian_22.05.1_Orangepizeroplus_focal_current_5.15.43.img.xz
Armbian_22.05.1_Orangepizeroplus_jammy_edge_5.17.11.img.xz

1
Igor

Igor

Posted
  • Author
Posted
6 hours ago, schwar3kat said:

I tried a build from a clone of that branch using LIB_TAG="v22.05" and focal image worked.
No obvious differences between the working and not working images.
I wonder if this issue is similar to the first CI run that affected all three images with the same symptoms.


I have build images again and they work - both NICs are up. Replacing them soon. Replaced.

schwar3kat

schwar3kat

Posted
Posted
15 hours ago, Igor said:

they work - both NICs are up.

Very strange.  Edge Jammy is working.

Both current images have the the LAN0 RX bug.  
It is true that both NIC's are up, and LAN0 TX speed is good, but RX speed is between 0 and 90 B/s for a short period, and then it dies completely.
If it does get an IP address, I can't connect to the device with ssh, it times out. 

Iperf fails with continuous errors on RX.  (TX gets normal speeds):
'recv failed: Resource temporarily unavailable'.

The results seem inconsistent which is perplexing.  Time for plan B I think 🤔

 

 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept