Igor

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.

This is my situation, but i am using gpios for driving relays with this simple script: ls -l /sys/class/gpio total 0 --w------- 1 root root 4096 Jan 1 1970 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 lrwxrwxrwx 1 root root 0 Oct 20 11:22 gpiochip412 -> ../../devices/platform/soc/1c1c000.usb/usb2/2-1/2-1.4/2-1.4.4/2-1.4.4.1/2-1.4.4.1:1.0/gpio/gpiochip412 --w------- 1 root root 4096 Jan 1 1970 unexport If this can help you in some way ...

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/

Patience

An update was sent to stable branch. I believe this problem was fixed, but can't make tests.

This manual needs updating. This is my script that download X86 (for ARM its the same) UEFI image, convert it to qcow2, create bridged VM, run it and run 1st boot steps:

Just leave this problem to someone with a device and know-how.