Igor

Didn't know that, our tests doesn't show alerts on suboptimal perfomance. https://docs.armbian.com/status/board-tests/#odroid-m1-01 This is with stable kernel at our tests: eth0 ↑644/↓941 Mbps Annoying but not critical. We can't change operations nor policy just like that. It is stressful and costly for time. Most of processes are automatic and disrupting their regular path is asking for much bigger problems then lower ethernet speed. Our staff and machinery is already operating at extreme edge. Idealy for sorting out this problem would be backporting fixes to LTS kernel. RC / edge kernels has different role and I think we are not moving CURRENT (LTS kernel) to 7.x in upcoming release. Its too soon.

That is extremely expensive, far beyond what we can afford. On top of work that only buy you a coffee. And I'm not aware of any Linux distribution doing hardware validation at this scale. Perhaps by the end of next year we'll be able to introduce hardware validation at the pull-request level. Until then, we have "just" this small testing setup in place: https://blog.armbian.com/booting-every-board-every-night/ And it actually caught this problem. I've already spent an hour investigating it, then making a patch, and more time will go into working with upstream developers to get the fix merged into mainline Linux. Upgrade was broken for cca. two days, and only in nightly builds, which aren't suitable for production use anyway. At the current donation rate, it will take about 33 years for GitHub Sponsors to cover our investment in the existing autotest hardware. And probably another 10–15 years to bring hardware validation closer to the development process. Until then, please don't expect us to provide on-demand hardware testing on rolling test releases.

Its a purely cosmetic issue, but we will look into it when possible. Check if your kernel is upgraded - BSP package carries low important updates.

Can you explain this more. Where? How to reproduce.

From a technical perspective, Armbian community-supported and DietPi are pretty much the same thing: same kernel source, same U-Boot, same patches. The difference is mainly who answers the issues. It's a division of labour. Armbian maintains expensive SW stack: the kernel, U-Boot and board support for 200+ boards, and that's where most of our time goes. DietPi only ships that work, which leaves them more time for dealing with users. Their contributions to the shared stack, don't show up in our statistics. A single average Armbian contributor commits more value than the whole DietPi team. That's not a complaint, just how it is. When something on the NEO breaks with a new kernel and later starts working again (Ethernet, Wi-Fi, LEDs, booting itself), that fix usually comes from people you never talk to. They're digging through kernel patches and U-Boot, reading not answering forum posts or GitHub issues. Its open source and anyone use those fixes. If you want to help keep the NEO in good shape, support developers unlike support service. tl;dr on why the two projects don't get along: on these boards, DietPi's kernel, U-Boot and firmware come from Armbian — the same sources and patches, built with our framework. DietPi adds its own userland on top. When something breaks in that stack, DietPi's answer to their users is "that's an Armbian problem". That puts the pressure and the load on us, and leaves their users thinking we're the problem. And it's not a one-off, it happens again and again. The real problem is the enormous technical complexity of supporting this hardware, which we don't have the resources to keep up with. Dismissing our work doesn't help with that. It makes it worse.

Running from eMMC. https://docs.armbian.com/status/board-tests/#orange-pi-pc-01 Did you update bootloader?

Community maintained build targets are "supported" this way: https://docs.armbian.com/contribute/board-support-rules/#community-maintained We can only afford to sponsor build capacity and host on free public resources (Github releases). If compilation breaks, we can only (temporally) remove them, fixing is your problem. Once / If community maintainer / random luck fixes compilation, they are (automatically) back, else they are gone. For good. Or only temporally. We don't store older images for community supported hardware, but they remain in the build framework so one can build then on their own. If last build broke, there won't be download page. This is the policy in tl;dr;

The problem is the address itself. With netmask 255.255.255.0, 192.168.1.255 is the broadcast address of the 192.168.1.x network, so it can't be used by a device, as @TrevorH also pointed out. The imager accepted it without warning, and the documentation didn't mention it either. That's on us. Because the board couldn't get on the network with that address, first-time setup asked "Connect via wireless? [Y/n]". The imager profile doesn't answer that question, so on a headless board setup waited until you logged in. What to do now: flash again with the same settings but a normal address, for example 192.168.1.50 (anything from .2 to .254 that isn't used by another device and isn't handed out by your router's DHCP).

Its not a problem of imager, but this feature is not designed as you expect: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstlogin#L93 This needs to be extended here first, then Armbian imager will follow. Workaround is to mount SD card and create / adjust configuration by hand. Do not select static IP, but put WIFI password, SSID, country ... and then, once image is mounted, add static IP and GW to that /etc/netplan/* yaml file. Not the best way, but it should work.

I think it might be a design issue. Static IP is meant for wired network only. This is the base: https://docs.armbian.com/user-guide/autoconfig/#configuration-directives that is used by Armbian Imager. I am using this feature reguraly to add a device to wireless network unattended, seleciing SSID / password / Country only.

9 years later Port to latest mainline 7.2.y kernel. https://github.com/armbian/build/commit/29eb954d4e15773c551324ee4e6bdedb8d6302b0 https://armbian.com/boards/nanopim3 https://armbian.com/boards/nanopifire3 https://armbian.com/boards/nanopct3plus Not perfect but usable.

Fixed! Ref: https://github.com/armbian/configng/pull/1021 Just run armbian-upgrade on your SD card and re-try installation. I verifed manually ext4, btrfs and f2fs install options. All works as expected. I tested scenario of full transfer to USB media so it boots without SD card. If you re-insert SD card, it will boot from there.

Tested (Rpi 400): 1. Same image, Armbian Trixie minimal 2. Initial setup + armbian-upgrade 3. Plugged nvme via USB3 igorp@rpi400:~$ lsblk -o NAME,FSTYPE,LABEL,PARTUUID,SIZE,MOUNTPOINTS NAME FSTYPE LABEL PARTUUID SIZE MOUNTPOINTS sda 119,2G mmcblk0 29,8G ├─mmcblk0p1 vfat RPICFG 3f631019-01 512M /boot/firmware └─mmcblk0p2 ext4 armbi_root 3f631019-02 29G /var/log.hdd / zram0 swap 1,8G [SWAP] zram1 ext4 log2ram 50M /var/log zram2 0B As you can see, my nvme drive has no partitions. 4. run armbian-install 5. Error recreated Working on a fix.

Odroid C1 has been troublesome since ever. Mainly due to SD card compatibility issues and powering is also not the best. And I have to correct myself - we also use stock uboot from 2011 as it seems this board never received anything more recent. Such ancient code is getting increasingly challenging to compile. Board is still in our automatic test system https://docs.armbian.com/status/board-tests/ but system is currently offline as one of the core PoE switches died and we wait for replacement. Will check soon. Thank you!

I will recreate later on real hardware to make sure it works. Can you perhaps provide logs? They are in /var/log/armbian-install.log or similar.