Igor

Ebin Ultra is very similar as this one, I even have one device somewhere at home, introducing several new troubles ... I think it even boots and works to some degree with normal Ebin image without changes. This is pretty normal in this world. Most of custom hardware does not have UEFI nor need it. UEFI is expensive to make and they sell hardware at BOM + profit only. Software support is buyers problem at the end. Time is the problem. I can spent sharing some experiences, not sure if valuable ... We have lost insane amount of time in past years trying to keep functional Linux image for this hardware. User space plays absolutely no role, kernel little. And this is just one custom hardware out of many. We received hardware valued 50 USD as a support for this in all those years in exchange for hundreds of hours to keep this device usable ... and Armbian team mainly don't need this to work. Users do, while costs of keeping this (terrible made and supported) is over extreme for our hobby / private time / pockets. And users, which are in 99% unable to see pain and frustration, mainly complains how something doesn't work ... never happy people never rewards maintainers. Work here is "only" related to keeping boot loader functional. Which is ofc not small nor simple. From there on, standard generic aarch64 kernel boots. For several years now. I don't think we can count anything from end users / amateur distributions as they require standard way of booting, but there was help from kernel.org communities. As this board can be moved under generic kernel, so whole marvel SoC mvebu64 kernel family can be dropped. Which would need to be expense on overloaded Armbian team. Or good will of someone from community. My 2c.

Try this method: Not sure if prebuild exists for this target but you can follow instructions and DIY.

No need to use snap version as sudo apt install chromium also works.

Deprecating some hardware is always hard, depressing and at the edge of desperation 😢 Lets hope that someone picks it up from here ...

This device does not meet basic support criteria anymore: https://docs.armbian.com/User-Guide_Board-Support-Rules/ Start here: https://docs.armbian.com/Process_Contribute/ and start maintaining this device or find someone (outside Armbian team) that will be doing this instead of you. When you fix problems, share it with others https://github.com/armbian/build/pulls ... sent fixes to upstream u-boot / kernel, or not. Our resources are way too small and your support is virtually non-existing. We can't support all hardware that exists. And especially not indefinitely and with complete lack of funding. Enjoy open source and stop blaming us who invested into your wrong purchase. Make a donation instead. For all the years of software you didn't have troubles with: https://www.armbian.com/donate/ My reply sounds ridiculous, I know, but this is how it is.

It is, but perhaps something else is wrong, ... this device is not monitored by our team anymore, so its hard to say. Did you wait long enough? https://docs.armbian.com/User-Guide_Networking/#automatic-configuration-on-first-boot

Generating images, once device is in the system, does not burn our expensive time. It costs a lot less then answering this support question. Updates are generated for all devices (of one family) at once. Adding and removing is expensive and perhaps someone fixed this problem? Then we need to put it back. Those are already maintaining activities, which we don't have resources for ... keeping devices in auto-build costs us close to nothing (until compilation succeeded) and this is the same way all others distros do, while they are marking those random auto-build as "supported by Linux X" ... We at least tell you "we don't know if it works", as checking is expensive. Or even impossible as nobody from the team has this device. It was added by someone like you, user, that wanted to keep this device in the Armbian system, which system provides a lot of common fixes and generally helps maintaining those devices. Our interest is that Armbian runs well on as many devices as possible, but the costs of that is super extreme - as you know, we can't sell you our work, you don't want to pay our bills .... Once we bring support on some device, we have copycats that does absolutely nothing but also "supports" this device. It is really difficult as costs dealing with those devices is close to impossible to cover. If you want that device function perfectly and when there is close to nobody helping, one needs to spent serious time / money to support HW dealers business, copycats and you. Its not sustainable. The same applies to other devices that were thrown to the market ... We are maintaining this system, some devices, while the rest are on you - community. Providing images, keeping this device in the system that is getting common updates all the time, is already great added value. Bugs are shared among similar devices, which means when this bug will be fixed for Pinebook PRO, this device will also have working images ... Its pure economy. They can't afford that. Device is here - and if you want to keep it operational, its your problem. Well, our common problem. We add our share and we can't add more. We don't have this device, we don't have anyone maintaining it. Not anymore. Now, a lot of those devices will still work even nobody maintain them. This indicates it stops before loading user space, probably kernel is crashing. Sometimes you need to solder those pins. HW designers aim is to make a device that they can sell well ... Does this device matches that? Yes, its a nice toy. There is no GRUB on those devices, but yes, problems with boot loader are possible. Every major kernel bump renders some devices into not usable state. That is why we have so much work that nobody notice and very little help. If we could allocate needed resources, all of those "Community (not) supported" will be working. This is certainly not in HW designers interests (as they want to sell you new device), while end users can't understand that buying hardware is just a fists step and means nothing. You need to add a lot more to have this device functional. This is not RPi, who has masses of people that will maintain it for free.

If non basic Linux user which you are addressing here would know what needs to be fixed, fix is usually sent to the build system and we would all have an image that boots fine. Until then, you can only join in exploring or use some older image that works. AFAIK currently nobody knows what is the problem or problem is being discussed, solution being tested. If you have a custom device and keep on with recent kernel, this is most common thing that happens. Things starts to fall apart and until time, will and interest comes together, its usually fixed. And sometimes, if there are not enough people, which eventually happens, support stops / functioning on upgrades becomes random.

Its not enabled in config. 1. Sent PR to enable it https://github.com/armbian/build/blob/main/config/kernel/linux-rk35xx-vendor.config#L2885 2. Upgrade to vendor 6.1 kernel as we will not maintain 5.10.y anymore (there its also not enabled) 3. Use nightly kernel builds / tell us to sent update to stable repository

Because this feature is expensive to do it right and expensive to maintain. Armbian is a part of kernel community, we make things works, we make Linux, we make patches, and also distribute our own Debian like OS. There are some distributions that does something in the low level world, but usually very little. Tacking this low end hardware, one (or a distro) can only lost a lot of time gain nothing. I think there are problems with both, PinebookPRO and RockPRO. When we stop throwing our precious time into software maintainace (you cover < 1%), things starts to fall apart. If nobody takes it over. Upstream support, where most of distributions relies on, is usually the first that dies off. tl;dr; Without knowing both devices and their software support into the details, its impossible to answer your question. Good luck.

1st option (Noble Gnome) with full featured desktop, where (almost) all features works / are enabled. Second is for IOT / server and others are ... there is some small info why they are. If you don't know why, skip / ignore them.

Fixing is WIP https://github.com/armbian/build/pull/6656 https://armbian.atlassian.net/browse/AR-2312

May 1st, 2025 AVAILABLE FOR ALL BOARDS on Debian Bookworm image via armbian-config https://docs.armbian.com/User-Guide_Armbian-Software/Media/#omv Download Armbian with OpenMediaVault (OMV) Currently (for testing) only 4 targets were build: rock5-itx, odroid m1, odroid xu4 and x86. Once its confirmed that works well, other targets will be assembled. Then boot the image, wait few minutes and login via: http://ip_address_of_armbian_running_ha U: admin P: openmediavault Test setup on Odroid M1: Tested on: Odroid M1 Raspberry PI 4 DIY

Probably this is the problem. For example - I have to switch to X11 in order to share screen over Zoom, on Wayland, this functionality simply doesn't work. Check this: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277

You can execute this also from armbian-config. Otherwise, documentation. Its not in the best shape, but enough to get going: https://docs.armbian.com/User-Guide_Getting-Started/

Study this: https://github.com/armbian/os/wiki

If you have downloaded "Debian" from Orangepi site, you are already using Armbian. Only some slightly changed old version and without Armbian & community support. To try Armbian, you burn SD card and boot from it. No need to install it anywhere yet. To install it, just run armbian-install and select correct (root) partition. Since this is Linux and your are using 3rd party OS (and bootloader), backup of /storage is recommended before proceeding. Just to be on a safe side.

This forum is also bug tracker. Otherwise it eventually reflects here https://www.armbian.com/participate/ and / or here: https://github.com/armbian/build Helping on the project is the only way. Telling us what to do is pointless. We are aware of many problems, just capacity to keep things maintained is limited. There are thousands of problems in the code made & maintained by thousands of people. We also make daily repository - beta.armbian.com , which is still tested better then rolling Linux levels. Its usually good, but sometimes things breaks. Repository management is done by those scripts: https://github.com/armbian/os/blob/main/.github/workflows/repository-update.yml https://github.com/armbian/build/tree/main/tools/repository Edit: Stable repo index is updated only manually: https://github.com/armbian/os/actions/runs/9760276553/workflow#L342-L345 Here some better mechanism has to be implemented.

You always proceed with Armbian install instructions. If there are some special hacks, they are described at download pages https://www.armbian.com/odroid-n2/ the rest is generic https://docs.armbian.com/User-Guide_Getting-Started/ All our images works without Hardkernel proprietary SPI boot loader, so choose eMMC. In case you have troubles with HA image, try some other (1st minimal was tested manually) from download page to make sure. Getting IP takes some time, but more then few minutes (big slow SD card).

Nobody knows what you are doing. Which device?

We have some repo troubles lately. Will be fixed soon.

Yes, that is expected. Remove it and it should boot from nvme.

This is common. Sometimes other (similar or identical) board's DT is used and we always bundle more DTs in the package.

Proposed solution: https://github.com/armbian/build/pull/6828

First thing in the morning, I tried to do a clean install to Odroid M1. It didn't go without problems, but I have at least identify some troubles. If you start with a new blank nvme, one partition formatted as ext4, it works without any intervention: https://paste.armbian.com/ovusomagef ___ _ _ _ __ __ _ / _ \ __| |_ __ ___ (_) __| | | \/ / | | | | |/ _` | '__/ _ \| |/ _` | | |\/| | | | |_| | (_| | | | (_) | | (_| | | | | | | \___/ \__,_|_| \___/|_|\__,_| |_| |_|_| Welcome to Armbian-unofficial 24.8.0-trunk Bookworm with Linux 6.6.36-current-rockchip64 No end-user support: built from trunk System load: 15% Up time: 0 min Memory usage: 2% of 7.51G IP: CPU temp: 42°C Usage of /: 1% of 1.8T Last login: Sat Jun 29 08:20:35 2024 from 10.0.10.242 Bug is in the partition prepare. I used some nvme where there were some MSDOS and ZFS partitions previously on SSD. Partition maker prompted out "are you sure to delete those or smth". This is the problem ... but after that, everything goes smooth: df Dat. sist. 1K-blokov Upor. Na voljo Upo% Priklop na udev 3859648 0 3859648 0% /dev tmpfs 787644 9308 778336 2% /run /dev/nvme0n1p1 1921724608 2074264 1821958288 1% / tmpfs 3938204 0 3938204 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 3938204 0 3938204 0% /tmp /dev/zram1 47960 332 44044 1% /var/log tmpfs 787640 0 787640 0% /run/user/0 tmpfs 787640 0 787640 0% /run/user/1000