Igor

If those people are signed as testers, then I am sure no bugs can be found.

FYI. I pushed update to CURRENT kernel too - today / tomorrow.

I don't know if with Armbian this works but this would be the very first question. Start here: https://github.com/armbian/build/pull/4267 Since things are not even merged, it means support is in poor state. And kernel branches you found won't bring much changes - we have (i assume all) this with patches. As most problems for this platform are not in the kernel but below.

I didn't say installing package will do the job Explore .deb file. Flashing is purposefully manual - via armbian-config - if your system is up and working.

u-boot deb package contains a script for flashing.

Remove that file manually and upgrade again.

Highly possible. Not all are capable of going higher then 115200 Like I said, unsupported memory chip in boot loader would explain those troubles. Probably it would work if you flash nonworking image with a u-boot from a working one. You can find them here: https://imola.armbian.com/apt/pool/main/l/linux-u-boot-nanopim4v2-current/

Also on the image that is working? Strange. You sure you have V2, not V1? Perhaps some memory configuration that is not supported with mainline boot loader? RK3399 can be booted with open source or closed source loader. We changed to open source at some point, but not on all boards. Perhaps this is the issue? We have a few of those acting as a build runners - no issues whatsoever:

We code system scripts in 90s the same way but IIRC we used Perl. Perhaps this is not the case when password complexity protection kicks. I recall on this bug https://armbian.atlassian.net/browse/AR-1234 This is the part of the code that is handling this. We will fix this when possible. (i work on this project 7am 10pm and can't jump on this just like that).

It should work in both cases. I am running it from NVME. But with eMMC boot. SPI boot loader is broken.

Fail 3 times. https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-firstlogin#L252-L298 Or set a proper password once and then change your password at any time. But it annoys me a bit too. One possible solution is to just issue a warning or specifically asks you - are you sure to use unsafe password.

If you are talking about build host support, then this commit is adding support.

This is how mainline Linux looks like. Features breaks all the time (caused by constant kernel changes / development) and its impossible to track as this is simply too expensive. Linux distributions in majority are not doing any testings of those functions, while our test system is too primitive to detect something like this. A few more hundreds of thousands would be needed to put in, which is, in case you want free service, impossible. If detection would be made, someone needs to invest hours to fix it. Currently waiting things, average resolving rate = 400 days. So you have an idea how little you are investing into maintenance on top and around chaotic mainline Linux experience. Workaround? Those usually always exists. One of them is going to armbian-config -> system -> other kernels and switch to older kernel, where this function was working. Then freeze kernel (which is anyway good thing for production deployment) and check from time to time if this was fixes. No, nobody will send you email when this will be fixed ...

Armbian usually has better hardware support then Ubuntu. Especially on ARM. https://docs.armbian.com/#what-is-armbian

Of course. We are using pretty much unchanged kernel from Rpi foundation. Did you check here https://github.com/raspberrypi/linux/issues ?

I think there is nothing wrong if those are added to the defaults: https://github.com/armbian/build/blob/master/packages/blobs/desktop/skel/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml https://docs.armbian.com/Process_Contribute/

In general we don't have much archives for those as they were not yet fully supported. We still don't have a dedicated maintainer, while I can't keep an eye also on this hardware. Automated test builds are made automatically directly from development branch - those are expected to break here and there. I have rebuild images from stable branch right now. Please check if they work for you: https://www.armbian.com/rpi4b/ (I have tested Armbian_22.08.7_Rpi4b_jammy_current_5.15.74_gnome_desktop.img.xz on Rpi 400 and looks fine)

Additional changes has been applied to the download pages - moving automated builds at the end, greying them out, adding additional remarks. Stable + automated builds https://www.armbian.com/rpi4b/ Automated only: https://www.armbian.com/rock-5b/ Those automated are ATM present only for WIP / rolling targets (such as Rpi or Rockpi 5b) but all others could get them.

Currently we only maintain 5.15.y mvebu as for everything else we don't have time to catch up https://armbian.atlassian.net/browse/AR-1313

How problems looks like? Try this: (armbian-config -> alternative kernels) https://imola.armbian.com/apt/pool/main/l/linux-5.15.72-bcm2711/

Patience for getting human response on whatever your problem is. Before you are going to switch some problems with another, please read this FAQ.

Thanks to @brentr we got new images with several fixes: https://armbian.atlassian.net/browse/AR-1269 RockPI WiFi assigned different MAC address on each boot https://armbian.atlassian.net/browse/AR-1268 RockPI-S WiFi throughput only 300K bytes/second https://armbian.atlassian.net/browse/AR-1265 Rock PI-S images will not boot from internal EMMC (SDNAND) https://www.armbian.com/rockpi-s/

Just a reminder, if someone wants to fix it.

https://www.armbian.com/rock-5b/

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build". - improved support in GRUB (armbian wallpaper) & HiDPI GRUB support - all preinstalled applications are normal apt packages - current 5.15.y kernel, Jammy userland (5.19.y has some strange issues) - snapd is not installed (user can install it) - HiDPI support (automated adjustments on big screen resolutions) - NVIDIA graphics acceleration with proprietary driver (x86 only) - Intel graphics acceleration also works out of the box - preinstalled Google Chrome (x86 only) - preinstalled Microsoft Visual Studio Code (x86 only) - ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms) - face unlock works perfectly fine on this laptop - installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it). I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome. Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy. https://www.armbian.com/uefi-x86/ https://www.armbian.com/uefi-arm64/ Please report where it works and how (well)!