Skip to content
View in the app

A better way to browse. Learn more.
Armbian Community Forums

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Igor

Administrators

  • Joined

  • Last visited

View Profile Find content

Posts posted by Igor

    Your fetch pulled PR #11072, not #11084: pull/11072/head:pr-11084. #11072 still mounts EFI at /boot. That is why the kernel files are on p1. Revert your local grub.sh edit and run:

      

    git fetch origin pull/11084/head:pr-11084
git checkout pr-11084
./compile.sh build BOARD=rock-5-itx ... ENABLE_EXTENSIONS=uefi-edk2-rk3588 BOOTFS_TYPE=ext4 BOOTSIZE=512 UEFISIZE=256

     

    Expected result: kernel, initrd and grub/ on p2 (/boot), EFI on p1 at /boot/efi. Please report if it boots. I tested the image layout, not a boot.

    0

    I managed to bring Bananapi M4 / RTD1395 to latest mainline uboot and kernel in usable state. https://github.com/armbian/build/pull/11071 Booting still require to load some audio propriatery blob (don't want to boot without) ... so it remain a nasty port. But board is usable, at least for server tasks, even pci works, but I am stopping here.

     

    Perhaps, with some luck, this port could be usable for tv boxes based on this chip. FYI, no support can be provided.

    0

    9 hours ago, Raul said:

    But tell me the exact git command

      

    cd build
git fetch origin pull/11072/head:pr-11072
git checkout pr-11072
./compile.sh build BOARD=rock-5-itx BRANCH=vendor ... UEFISIZE=512

     

    Perhaps just do a quick test to confirm even I am pretty confided it should work now.

     

    9 hours ago, Raul said:

    but anyways I hope my stupidity helped improve Armbian by just a bit ...

     

    Yes, it revealed a bug. Thank you.

    0

    On 10/17/2026 at 2:26 PM, drracer said:

    my bug hunt and fix have been greatly supported by LLM tools (AI assistant Claude), no cubietrucks have been harmed during the sessions.

     

    Now ask your assistant to submit a PR at https://github.com/armbian/build/pulls :)

     

    We're already overwhelmed with bug reports, fixes, PRs, and the ongoing work required to keep everything running. From my perspective, what's often missing is an understanding of just how much effort it takes to maintain reliable Linux support for such a wide range of inexpensive yet surprisingly complex hardware.

     

    Suggestions and AI-generated solutions are welcome, but turning them into working, tested, and maintainable code is where the real work begins. Contributions are always appreciated!

    0

    11 minutes ago, j0ta said:

    only nightly edge kernels contain the ethernet speed fix for m1


    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.

     

    11 minutes ago, j0ta said:

    just move the rc kernels into bleeding-edge until the stable release

     

    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.

    0

    1 hour ago, j0ta said:

    Please test rc in bleeding-edge before making it available on edge

     

    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.

    0

    On 9/19/2026 at 11:53 AM, dave3 said:

    but I found it better supported.

     

    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.

    0

    On 5/24/2026 at 4:36 PM, Sam Rossiter said:

    Has support for this board been dropped?

     

    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;

    0

    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).

     

    0

    5 hours ago, vtech said:

    If it is not natively supported by Armnian imager?


    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.

     

    5 hours ago, vtech said:

    How to work around in this situation to configure static IP to wifi.


    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.

    0

    6 hours ago, vtech said:

    from armbian imager


    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.

    0

Account

Navigation

Search

Search

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.