Igor

Fixed upgrade component is coming up ASAP. Just doing last tests.

Upgrade was disabled. Investigation is in progress ... some board works, some don't.

Images with 4.19, 5.19, 6.1RC will be generated once merged: https://github.com/armbian/build/pull/4368

Technically? Support wise? It adds unnecessary complexity. We are using controlled environment to rule out most stupid troubles and to save time. Stupid troubles can be big time wasting elements. Most of the distributions usually don't have developers & maintainers for core components. They ship vendor prepared firmware, our firmware, pure mainline ... or something in between. Best working kernel is vendors (when hw is released) while mainline always remain in pretty raw state also after years. We keep that operational, starting with some features, adding more. Some are coming from mainline, some from our labs. Some might never come to the main Linux tree and we could maintain features nobody else. And a lot faster then mainstream. Mainstream turn around is slow, time consuming, commonly poorly tested. Most of troubles we have in stable branches are coming from mainline, from that "doesn't matter" space. Morally? If you are asking for support on 100% my personal expense - my time is most important value. Not yours is. Technical support for Armbian users or even supporters that help us pay the bill they are generating to the technical infrastructure (electricity) is on the edge of possible. We can't finance people out of that. And since we have very limited resources, 3rd party Linux users are simply always last to be serve. There are many things you have reported or we find but are not fixed yet. First sorting out that, then 3rd party problems. Fair?

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.