laibsch

Thank you, @Mangix. We bumped u-boot to v2025.10 for Helios, so I would assume those commits are already incorporated, aren't they? I have only looked at commit dates, not actual code.

Well, that makes me wonder how you were able to verify successful flashing with the broken adapters as you were upset we even dared to ask if you did... Maybe reconsider your tone for next time? As it seems the initial request to make sure you had no issues with your storage - one way or the other - were in fact helpful and spot on...

I don't even think this has anything to do with Armbian / Debian / Ubuntu. It's simply someone mucking around too much for their own good and frankly being arrogant about it. Until I see the problem reproduced in a stock setup this is simply PEBKAC as far as I can tell. I mean, for anyone actually willing to read, it's right there: Nov 24 13:06:57 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection. systemd is essentially a monolith, you don't really get to pick and choose for all intends and practical purposes. The choice @Quantum needs to make is whether he wants to have something that works or whether he prefers to be high-and-mighty and run around being condescending to those whose work he uses without paying a dime all the while making outlandish claims. This is a non-issue.

@Learnincurve It is very easy to build only the kernel with the Armbian Build Framework. The result will then appear as output/debs/linux-image*.deb

ping @amazingfate and @prahal

maybe @schmiedelm has an idea?

btrfs on Helios4 is now on by default and there is a uboot-btrfs extension to easily enable this for other boards or even at compile time.

With the latest changes in Armbian and most importantly the update of u-boot to v2025.10 for Helios4, it is now possible to boot SATA and USB from u-boot flashed to SPI NOR flash, with the dip switch set to SPI boot mode. This even includes booting straight from u-boot to btrfs now.

Images shall only be written with imaging tools that validate burning results. This saves you from corrupted SD card contents. Approved Tools: USBImager a lightweight cross-platform imaging tool Balena Etcher an electron / node.js based cross-platform imaging tool (may contain spyware)

Can you run a uefi-x86 image in a VM and see if you can reproduce the behaviour? I doubt this is specific to your board but an error somewhere else.

Are you saying you are missing further steps in between setting root passwd and being logged in?

How did you flash the Armbian image? Did you validate the checksum for the image? What software did you use for flashing the image?

What you need to understand is that whatever money you paid, you paid for the hardware not for software support. So, the hardware vendor does not give you software support. And we are just a bunch of enthusiasts trying to keep our own boards alive. I am sure that you can understand that your understandable nonetheless misguided rant does not necessarily help in making us more enthusiastic. Armbian provides you with some help to maintain your own board yourself. Whenever somebody does so and provides their work back to the community you are in luck and can freeload off of their work. Still doesn't give you the right to make demands and rant. In your case, you are in luck as there is a person donating their expertise and time. Let's see if @NicoD has anything to say about the issue with your board. Buy him a coffee on Paypal or Patreon for the time he already donated to keep YOUR board alive while getting 0 cents from you so far?

I never said it was a Debian issue (you failed to mention which userspace you were running in your original post, btw). The issue is with whereever you got your authelia package from (which you also failed to mention). You also failed to mention what error exactly you are running into. But yes, you are right, Debian will and can do nothing about it. Basically the same is true for Armbian, the symlink is there for a reason and there to stay. You are in the wrong place to get this fixed.

Your best bet is to compile your own image. It's super easy: "git clone https://github.com/armbian/build.git;cd build;./compile.sh" https://docs.armbian.com/Developer-Guide_Building-with-Docker/ https://docs.armbian.com/Developer-Guide_Build-Preparation/ https://www.youtube.com/watch?v=kQcEFsXEJEE

As far as I can tell, Armbian does not support the OrangePi RV2. Where did you get the image from? Or are you really talking about the PC2? RISC or ARM? Big difference.

authelia is not a Debian or Ubuntu package. I'd recommend you complain to whoever you got the package from, I guess. It's the first time the symlink has become an issue as far as I can recall.

should be fixed with https://github.com/armbian/build/pull/8980

I think @NicoD meant tasksel.

please DO share what steps you took to get it working for the benefit of the next guy.

You are likely hitting genuine bugs and/or the situation of missing packages. I do not use Cinnamon, so I cannot comment much. Try to see if there is anything relevant in the logs. Check ~/.xsession* files for hints, too. Maybe try a different DE first, set up it to be working and then work on your preferred choice after that. Have a look at APA which is trying to improve the experience of Armbian as an OS, maybe it can help you. Good luck, amigo!

@Igor, supposedly, these images do not boot. Maybe you have a chance to verify on your end.

http://debug.armbian.de

most likely a bunch of packages that shouldn't have been removed were removed alongside, the joys of GUI package management 1) don't be afraid of the command line 2) see if /var/log/dpkg.log gives any hints what is missing What desktop system were you using before? Try to get it back installed. PS: In your current situation, you can reach a log-in console and command line with Ctrl-Alt-F1 PPS: Reinstalling from scratch might be faster.

Alt-F2?