Igor
Administrators
-
Joined
-
Last visited
Everything posted by 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.
-
-
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.
-
-
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!
-
-
-
If you check random image from our archives, you will 100% find one that has no troubles for you. https://fi.mirror.armbian.de/archive/ https://fi.mirror.armbian.de/oldarchive/ Odroid C1 / C2 has SD cards compatibility troubles. Lakka probably uses old bootloader from 2011, which will be slightly better in this compatibility, while modern 2026 boot loader, which we use for 80% of this time, is not polished. This is very old hardware that support would normally be long dead. P.S. This is a forum, not a personal support channel. Things are changing all the time, and discussions may become relevant again later. We don't close topics here.
-
-
My POW. From marketing perspective 7 sells better then 6 and mainstream x86 devices also require little hw related maintainance. More recent kernel generally provides better support for new (mainstream) hardware, which is their primary focus, then 6.18. And its not bleeding - arch - edge level neither. And they look special. IMO its more marketing then technical choice. Most of Linux users don't have perspective that we have. Higher number is better, different versioning even more. And by the end of the day, Ubuntu kernel is patched, its not pure mainline, so its different by default.
-
Not that simple. Official software stack is very different from the one we use. Drivers are often written from the scratch as frozen sw support provided by vendors is often very low quality. Its made in "do not touch or change anything" and it will work, else it will fail. And you ended up using 10years old SW stack that never got any update. https://docs.armbian.com/user-guide/faq/#why-things-stop-working
-
Some tips: - use vendor or current kernel. Stay away from EDGE. Outside is wild wild west. - use supported hardware only. Outside is wild wild west. This is not about OS type, but hardware support. Not Nix vs Debian vs Ubuntu vs Armbian. Armbian works perfectly on good hardware. Spent some time with https://docs.armbian.com/ read, try to resolve problems, keep asking questions. This is how you loose "novice". Our main comm channel is Discord, IRC is just for compatibility reasons and I don't know what are the diffs between servers. There are very few people using it and so far nobody complained to my knowledge.
-
At one point Balena Etcher failed to burn .xz images correctly. We reported bug but it has been two years since. More then that we can't do. Today we have our own flash program which is a class better. Use it: https://imager.armbian.com/ and in case you ran into the same problems, report back. PS I flashed Orange 5 today and it boots just fine.
-
-
-
