Igor

It is, since moving network bits into extensions. Here it is installed: https://github.com/armbian/build/blob/main/extensions/network/net-systemd-networkd.sh#L11

This was dropped out from kernel by mistake, but it was already fixed at sources https://github.com/armbian/build/pull/6984 You need to build kernel from sources or use kernel from nightly repository that is already having this fix.

"systemd-network doesn’t quite play well with docker." Perhaps this https://blog.kylemanna.com/linux/docker-systemd-network-surprise/ is the problem.

This means Docker works. Minimal Armbian images comes with very minimal systemd-networking since several weeks. This brought much smaller OS images, but could cause this kind of troubles. Try to do some research into this direction.

This is custom hardware world. There are many models, some are similar, some different, some very different. Some vendors sets names with complete absence of any logic ... and there is little we can do about. Orangepi Debian and Orangepi Ubuntu are Armbian fork. They generate those images with Armbian tools that were forked few years ago and where they removed all other vendors out. Instead of cooperating with us on the same code base of the build FW, they "maintain" their own. Also kernels are maintained by https://github.com/orangepi-xunlong/linux-orangepi/commits/orange-pi-5.10-rk35xx/ (one person) vs. Armbian + community maintained (10+ people) https://github.com/armbian/linux-rockchip/branches. We have ditched this very old (named legacy at Armbian) kernel 5.10 few months ago and we just released 3rd version of (named vendor at Armbian) kernel 6.1.y. Both, legacy and vendor are provided by Rockchip and are containing many non-standard solutions that cannot and will never be mainlined. Then there are mainline based kernels, named current and edge, which are derived from kernel.org but heavily patched to provide as good as possible functionality. This latter does not interest HW vendors much as its beyond their control. You need to have a strong reason to run their software. It's purpose is to sell hardware. Armbian bookworm current is what you want. Only problem here is that we (Armbian staff) don't have re$ources to spent on this device, so it will remain community supported. There is also a version of this board that is broken and will only cause additional expenses. And our time is too precious. Absolutely not. Forget about kernel 5.1.y Its dead end, nobody is maintaining it anymore.

We are thrilled to launch this initiative to recognize and reward the incredible contributors who help keep Armbian running smoothly. All existing and new contributors will be entering the pool to win modern powerful and sleek Intel powered workstation: 1 x Khadas Mind Premium + dock and 1 x Khadas Mind Standard + dock Review: https://www.servethehome.com/khadas-mind-is-a-different-mini-pc-our-review-intel-1360p/ About: More info: https://www.armbian.com/newsflash/armbian-khadas-are-rewarding-contributors/ How to nominate? Post into reply why you think certain forum member contributions stands out and should be added to the pool.

Just a tip. Wireless chips (drivers) on those boards are often terrible quality ... Try same method on USB wireless to see if it behaves the same. It might be the driver.

I am glad you are able to understand. Yeah, its done different for each device, untested on all combo and stressful to support. In embedded Linux you need to support specific use case and you tune u-boot to support that ... Oh, we are well aware Here is, perhaps little outdated, attempt to come up with something better:

If you expect something in return, then perhaps you could consider sponsoring, consulting, ... instead? Donations are a gift. Nobody knows that you need this particular hardware to work, while all HW can not be supported. For every USD of donation, we can easily lost 500 USD to get the job done. It is that twisted. FYI. SW developers needs respect and/or financial security while fixing your computers problems instead of you. Nobody prevents you hiring people that will help us maintaining this hardware. Perhaps we stop because we can't afford? Have you thought into that direction? This is open source. There are only a few of people that can afford and want to help everyone, others you need to sponsor. New hardware keeps coming. Software is always changing, maintaining custom hardware remain complex and costly. We need more then just your 50 USD to cover bill that is 100-1000x bigger. Still I thank you as if everyone would donate, it would work out and it would be a big change. Most people don't and many people donates to our downstream that contributes (close to) nothing to you, nothing to us. Perhaps people don't donate as they are constantly unhappy as their expectations are out of the charts. Like paying 0.5% of needed money to cover for the service, but one still expect full blown quick response that is not possible to provide regardless of payment. This software is supported by this community and you are also a part of that support staff. Perhaps helping others is the key? I am personally a lot more motivated when someone helps resolving problems then making a donation. There are too many devices, things are very complex and a lot of time needs to be sacrificed. If someone needs a week to fix this and there is 10 USD of reward waiting for the job ... motivation is clearly something else. Response can only be super slow as we don't have a dedicated person on this hardware, vendor doesn't help us neither, we already do more then possible. We stop supporting some hardware when there is nothing more to be done. Donations don't cover a single support person. And behind support person, there are developers in many areas, project managers and other support staff. We need them all in order to operate, and millions to provide software support to people the way they / you expect. Not few thousands. But we don't give up neither. We keep going. I will tell you from my personal perspective. I would need several days of silence, that nobody else would want anything from me, to look into the problem. While looking into I will find more problems and will try to fix them. I have to deal with so many other things that this week can't come anytime soon. Not this year, not next. Having 10, 50 or 500 USD of donation (and to blow additional few thousands of my own) makes no change. And in this time I need to earn those few thousands to fix your problem. Then its a thin line between donations and something else. Conditioned donations are professional services. But since local McDonald's pays significantly better hourly rate without requiring high-end education on top of 20-30 years experiences ... If we need to keep some hardware operational, its up to the maintainers first. Volunteers decide and we (Armbian pro support) support them if possible https://docs.armbian.com/User-Guide_Board-Support-Rules/ If we have nobody that will be sponsoring you / taking care of hardware, there is nothing we can do. Donations won't change this, but you can try sponsoring a person within Armbian that will be supporting this hardware for you. Even this is very hard to arrange. And this is also open source with no (c) protection. For authors this is hard place, there are bad players and many traps to fall into.

Armbian aim its to make and maintain Linux (firmware) from when the power is connected to the board. This is much closer to embedded Linux then normal Linux distributions. Nothing less then full control. Ofc this is not always possible, but we know how to do it ... and when / where this is achieved, this is fun. That heals frustrations and depression Problem starts with maintaining all this. As this is everything but fun, require different mindset, gets boring and is easy developed into full time job that brings no / too little food on the table. Average (x86/Rpi) Linux distro users, who doesn't understand any of this, would "only like that everything works". Armbian is Debian from outside, but it could / can be Arch or whatever flavor, if someone would be crazy enough / have have too much time to add extension to make Arch output / rework that that kind of customization are possible. Why doing that if the aim is to run Linux firmware / some use case / and that is already very difficult as this everything but standard made hardware. Vendors don't want that you run (mainline) Linux. They want to sell hardware with their partially closed SW, similar to / with Android. We want to help users running Linux on those exotics, often for single purpose made, devices. In embedded / custom Linux world, where we are, distribution philosophies are usually wrong. Yes, you / we would like to have UEFI to spare troubles ... well, making it is Concorde fallacy by default except mainstream hw. Do you have required funds and / or enough power to motivate volunteers to make it? Users are scattered around many many devices, which will (never) be under UEFI. If you move device to mainline Linux with basic functions, its already a (great) success. Costs millions (core work can not be done and its not done by volonteers) on top and around community help. Where masses are behind - Rpi, now RK3588 and similar variants are going to get this, others too late or never ... Many things should exists but they do not Making hardware was never this cheap and Rpi model proved that community will make firmware instead of them or not at all. Something is always provided by SoC maker. This is what they hope for. Some helps and invest into SW, some not at all. And most users have don't know this nor care about. Armbian is Linux build framework first. A framework that helps us and community maintain this endless crowd of custom hardware. They were purposefully made not to be standard and what is under Armbian is already a lot of standardization applied. Because power of build framework and people that made and maintain this. Regulars, part timers, random people that shows up. We could do more, but we don't have re$ources or sufficient level of support. There are some people that will be very helpful for this, but usually they do not have the know-how to pick it from here. Volunteer developers do that anyway, but majority of solutions are never integrated as core team is simply too small. And this is never to be changed. We are surviving with keeping the focus on some devices, leaving others "to community / anyone that wants / upstream / * ". Line has to be set somewhere as otherwise doers would burn out, level of sadness would eat us out. Some exotic devices nobody will ever pick it up if some of developers won't donate months of his time. Then this works is picked up by some other distributions. We have noticed ArchLinux re-packing and serving our Rockchip kernel, others are too exotic. This market function this way. They design hardware and provide support for business clients. Amateurs are often collateral damage. This is hard to change. Expectations are set with marketing and are often set with different objectives. Then you add complete lack of technical understanding from end users and you get a clash. People that come for help are frustrated, support givers are 1/1000 and totally milked out ... Armbian supports (in term of ordinary Linux distro) lets say 200 devices. In reality we only know for those, where we have maintainers - "standard Armbian support" https://www.armbian.com/download/?device_support=Standard support which are volunteer and they come and go. We (core team, partially pro) maintain framework, ecosystem, some devices. They don't maintain devices for us (Armbian), they maintain devices for you, users, community. Device that works good with Armbian, can easily run any other distro. Well, not UEFI easy. Still some devices were made in small quantities or were largely abandoned for better new models. Many people run do-not-touch-as-it-works glued together image which nobody can ever recompile. This problem Armbian solves very well. And closer to humans as some industrial grade tool such as Yocto.

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

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/