Search the Community

Getting into buildroot and yocto seems a bit too much for me to get an A+B style update possibility. I would like to stick with the quality images provided by Armbian. The following applies to a NanoPi-NEO3 others SBC might have different partition layouts. From what I understood is that uboot looks for /boot in /dev/mmcblk0p1 reads the boot.cmd/scr and armbianEnv.txt and then boots the kernel accordingly. The armbianEnv.txt seems to point the kernel to the root partition using the rootdev directive. If /dev/mmcblk0p1 would now only hold /boot would it be possible to point to a different partition for the rootfs using armbianEnv.txt? If so I could imagine changing the partition layout to the following: /dev/mmcblk0: /dev/mmcblk0p1: boot partition /dev/mmcblk0p2: rootfs partitionA /dev/mmcblk0p3: rootfs partitionB /dev/mmcblk0pX: multiple more partitions that survive updates Too now allow consistency with the rootfs partitions also the boot partition directory structure would slightly change. It would contain 2 directories: /bootA, /bootB AND a hardlink /boot which either points to /bootA or /bootB In the running rootfs the fitting /boot is mounted via a bind mount hoping normal apt-get updates can deal with this. This would allow creating a rootfs by updating and verifying everything works locally and then creating an image from it. Now to OTA a relatively simple script running from rootfsA can download a new rootfs image/file structure and place it in the partition of rootfsB. Same with the new boot partition just into /bootB. The values of the armbianEnv.txt from the new boot image always point to the corresponding rootfs partition either because the image was already built for this or the script dynamically adjusts them. Same goes for fstab, machine-id, ssh identity and other rootfs specifics. The script will then verify that the write worked to avoid sd card issues. The (almost) atomic operation for switching the systems would be changing the hardlink of /boot to the /bootB directory and reboot. This idea will not detect any boot issues and revert automatically back as uboot is not involved. Also this only works if uboot is still compatible with the new boot files provided. But an additional new uboot image could also be provided during the update. Reverting can be done manually (relatively fast) by changing the hardlink back and rewriting a previously created backup copy of a might be updated uboot image. Independent of the fact that buildroot, yocto, rauc, mender… systems have a better feature set, do you think this could work?

Hi everyone, it's been a while since i've posted but I have a new project that i'd like to share and hopefully get feedback and ideas from the community. Ever since the first 2 x gigabit ethernet devices came out, I've been thinking that there were a lot of potentially interesting networking use cases. I happened to be re-configuring pihole on a new opi zero, and I had some hardware issues that caused my connection to be a bit flaky on a website that I "shouldn't" have been using. This gave me the inspiration to create a gateway that intentionally manipulates traffic in such a way that you train good usage habits of websites that can be addictive. How does it work? Nethadone leverages several eBPF programs to monitor and classify routed traffic as it passes through. Based on the configured policies, packets are slotted into a series of bandwidth classes. For anyone not familiar with eBPF, it's a powerful capability of newer Linux kernels, that allows C and Rust code to be compiled and run in a sort of kernel-space sandbox and loaded in realtime. Due to the efficiency of JIT-optimized eBPF code running inside the kernel, features that were possible only with expensive networking equipment are now feasible on something like an Orange Pi R1Plus. The flow of a packet through the moving parts of the system is here: There are three eBPF modules at work: A traffic monitor captures (saddr, daddr) pairs from clients on the network to external IPs, counting the bytes used. These counters are exposed by the webapp and collected in a local prometheus instance. A DNS sniffer captures DNS requests passing through the router, in order to cache the likely domain of a given IP address A throttler eBPF is dynamically recompiled based on traffic patterns, and classifies traffic based on a policy. Packets classified into one of the slower bandwidth classes ends up passing through a netem qdisc, which simulates a slower network connection. As "bad" usage continues, the policy is changed until traffic is passing through the equivalent of a 56k modem. I think most people here would probably get the hint and stop scrolling if they were forced to use a telephone-based modem again Deployment Example This diagram shows how I've installed it at home - any device connected to the nethadone AP is subject to throttling: This setup was mainly to have an easy way to get back online if there were issues, but after a couple of weeks of general usage with both desktop and mobile clients, there have been no major issues, apart from the need to restart after 24h or so. Armbian-related TODOs While there are some things that could be better, the tool is working well enough that it has already had a positive impact on my and my wife's usage of a number of sites. My goal is to now make it as user-friendly to set up as possible. One big issue is that Armbian understandably does not enable BTF in the images that ship. The dae project has been a life-saver, providing BTF-enabled kernel builds for a lot of devices for Armbian 23.08. I tried to create a custom image with a BTF-enabled kernel, but had a lot of difficulty getting something bootable and set it aside. I also ran into some kernel configuration issues when attempting to make an older OPI R1 (not plus) work, even with the dae kernels. My gratitude to everyone who helps maintain Armbian and helps on this forum. In the coming weeks as I try to work on making it easier to use this on other devices, I may seek out some advice from forum members on how to work through these issues. For anyone interested in trying it out, or wants to find out more about how to use eBPF on an arm-based device, the code and documentation can be found here: https://github.com/atomic77/nethadone 👋 -Alex

Hye guys. One question regarding the above topic Can I make a swap space to support the RAM activity?

Hi all. I've done an interview with Igor from Armbian. We talked about the new release that's coming this weekend. And about armbian-next, the new updated build framework.

As ubuntu 22.04 has realy up to date compiler. Is it possible to force armbian to use local copiler? linaro gcc compiler is 8.x but gcc in ubuntu 22.04 is 11.x. Is it possible to force armbian to use local compilers? Or can armbian update gcc to 11. x ??