laibsch

armbian already move a lot of directories to tmpfs to reduce the amount of writes. a misconfigured system can of course reduce the lifespan of flash memory but that will be the case regardless of filesystem. there are ways to mitigate write amplification, for example. you will need to monitor the write activity on your memory. don't fill it up completely. iostat or nmon will help you see how often and how much is written to disk.

In general, it is a bad idea to try and fight systemd, I guess. Why not let systemd-resolved handle it?

Thank you for your work. Much appreciated.

Excellent. Thank you for sharing. Are you the author of https://github.com/MathiasStadler/orange-pi-zero-boot-from-spi or one of its consumers?

The way I understood it is that we are talking completely unattended installs here. For mass installations (probably hundreds if not thousands of boards) with no interactions other than other than popping in the flash card and pushing the power button.

I don't see this when following the link

does it make sense to publish both compressed and uncompressed in that case? No: additional compute requirements for CICD to compress images additional storage Yes less bandwidth for our mirrors and users faster downloads What do you say? I have another question: What do you mean exactly by docker support? Are you saying these images have somehow been prepped for easier consumption by docker? Please clarify. I suggest to document this properly somewhere to help in wider adoption and better user experience. This should be good for people testing armbian without having to flash an image to real hardware or without even owning an SBC. Another use case you already mentioned is automatic testing.

"We extend our deepest gratitude to the remarkable contributors who played a pivotal role in this release. Special thanks to: [...] @dependabot" 🤩

I am really happy to see this. I built a Noble image and tested it locally with qemu. ssh into the VM was fine but the framebuffer showed corruption. There was only about 10M of free space on / qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -m 2048 -display gtk,gl=on -device virtio-net,netdev=net0 -netdev user,id=net0,hostfwd=tcp::5800-:22 -drive if=none,id=root,file=./Noble_cloud_minimal-qcow2,format=qcow2 -device virtio-blk,drive=root Is there a reason not to offer these images in xz compressed format? Size goes down from 665 MB to just 153 MB for Armbian_25.2.3_Uefi-x86_bookworm_cloud_6.12.20_minimal.img.qcow2.

as a step in the right direction, there is some work being done to get dnsmasq to install and work properly.

I think neither of the solutions provided by Werner and Igor are really satisfactory and I 100% agree with @Mr. Fennec that the SBC should be easily discoverable after boot. The closest to that is the nmap command from Igor but that does not work reliably for me and requires root. Adding avahi-daemon package is less than half an MB installation size including dependencies. Not even a drop in the bucket for the image sizes. In my opinion, every board should have a minimal image containing nothing but what's necessary to do the following for at least Debian and Ubuntu: network via DHCP ssh server with standard PW avahi tooling to make the SBC discoverable with zeroconf/mDNS From there, you can take your board to anywhere you want it to and very easily. The desktop images provided are purely courtesy and can be easily replicated from a minimal install by simply installing the packages. For one thing, I was disappointed to see that for my board a minimal, CLI-only package is available for Debian but not for Ubuntu.

I'd say let's wait at least until it lands in Debian

what exactly are you proposing? do you think you could do the work (with some help if necessary) or are you hoping someone else might do this on your behalf?

Interesting thing you are doing there. Is this still something you are interested in getting resolved? Were you able to get it resolved on your own? Apologies for the late response.

Yes, I would not recommend plucky unless you know you need it. In my humble opinion, and I say this as someone who officially maintains packages in both Debian and Ubuntu, LTS is the way to go. That would be either Jammy or Noble at the moment. I personally have made the switch to noble and that would also be my recommendation. Don't expect a large number of updates on LTS and that is a good thing. Personally, I am not happy about Armbian always updating their kernel on a daily or even more frequent basis. But obviously, as Igor said, there is currently no way to make targeted, manual per-board kernel and firmware releases. So, as of now, if it builds, it gets shipped, even if nothing changed for your board in question.

do you have a github account? this definitely sounds like a bug and might be best if reported there.

60° is certainly very high

happy to meet up

Hello @Dandaman46 I think it's going to be almost impossible for anyone to make suggestions if they don't know what you have already done. IOW, what is the "etc."? Best way to communicate that is by way of code, I assume.

next time you are looking for a particular command or file, try apt-file search locale-gen. very useful.

This happens all the time. A good thing I can suggest in such a case is to sudo apt install command-not-found It's an incredible useful piece of software to have. This is what it will show for you laibsch@banana:~$ fastfetch Command 'fastfetch' not found, did you mean: command 'fastafetch' from deb exonerate (2.4.0-5) Try: sudo apt install <deb name> Too bad, no good answer in this case. Let's see what apt-file can do for us. laibsch@banana:/tmp$ apt-file search fastfetch fastfetch: /usr/bin/fastfetch fastfetch: /usr/share/bash-completion/completions/fastfetch fastfetch: /usr/share/fastfetch/presets/all.jsonc fastfetch: /usr/share/fastfetch/presets/archey.jsonc fastfetch: /usr/share/fastfetch/presets/ci.jsonc fastfetch: /usr/share/fastfetch/presets/examples/10.jsonc fastfetch: /usr/share/fastfetch/presets/examples/11.jsonc fastfetch: /usr/share/fastfetch/presets/examples/12.jsonc fastfetch: /usr/share/fastfetch/presets/examples/13.jsonc fastfetch: /usr/share/fastfetch/presets/examples/14.jsonc fastfetch: /usr/share/fastfetch/presets/examples/15.jsonc fastfetch: /usr/share/fastfetch/presets/examples/16.jsonc fastfetch: /usr/share/fastfetch/presets/examples/17.jsonc fastfetch: /usr/share/fastfetch/presets/examples/18.jsonc fastfetch: /usr/share/fastfetch/presets/examples/19.jsonc fastfetch: /usr/share/fastfetch/presets/examples/2.jsonc fastfetch: /usr/share/fastfetch/presets/examples/20.jsonc fastfetch: /usr/share/fastfetch/presets/examples/21.jsonc fastfetch: /usr/share/fastfetch/presets/examples/22.jsonc fastfetch: /usr/share/fastfetch/presets/examples/23.jsonc fastfetch: /usr/share/fastfetch/presets/examples/24.jsonc fastfetch: /usr/share/fastfetch/presets/examples/25.jsonc fastfetch: /usr/share/fastfetch/presets/examples/3.jsonc fastfetch: /usr/share/fastfetch/presets/examples/4.jsonc fastfetch: /usr/share/fastfetch/presets/examples/5.jsonc fastfetch: /usr/share/fastfetch/presets/examples/6.jsonc fastfetch: /usr/share/fastfetch/presets/examples/7.jsonc fastfetch: /usr/share/fastfetch/presets/examples/8.jsonc fastfetch: /usr/share/fastfetch/presets/examples/9.jsonc fastfetch: /usr/share/fastfetch/presets/neofetch.jsonc fastfetch: /usr/share/fastfetch/presets/paleofetch.jsonc fastfetch: /usr/share/fastfetch/presets/screenfetch.jsonc fastfetch: /usr/share/fish/vendor_completions.d/fastfetch.fish fastfetch: /usr/share/licenses/fastfetch/LICENSE fastfetch: /usr/share/man/man1/fastfetch.1 fastfetch: /usr/share/zsh/site-functions/_fastfetch Oh, it looks like fastfetch does exist after all. Not sure, why command-not-found didn't know about it. Anyhow, the following should resolve your issue: sudo apt install fastfetch explanation of apt-file output: the stuff before the ':' is the package-name and the stuff after the ':' is the matching file-names and where they would be located on the filesystem if the package was installed.

Another option you can look into that should be easier to get up and running is to use an X tunnel over ssh. You don't need to run a full-blown Desktop Environment if you only want a browser or Libreoffice or ... At the same time, I highly encourage you to love and learn the command line.

OK, I guess maybe not too many users of this board hence no answers. Let's broaden the topic (it was never meant to be closed); what kind of temperatures do you see on your SBC und load and idle? Looking forward to your comments.

Hello, I am curious to hear how accurate the measurement of temperature is from the onboard sensors, particularly in my case for the Banana Pi M2+. While I do understand that the BPi M2+ suffered from poor choices for thermal management from the manufacturer both in hardware and software, I believe that thankfully Armbian has worked out the kinks on the software side, hasn't it? I am running the latest noble image, here's what I noticed. The temperature as shown by the sensors and armbianmonitor commands never really goes below 60° even on idle with ambient temperatures of around 25 to 30 degrees. My SBC already came with a small heatsink attached to the CPU. I found that value pretty high and inquired with an infrared thermometer but couldn't really find a spot on the board over 40°. Which makes me wonder if the reading is accurate and properly calibrated? My impression is that it is not. Furthermore, I noticed the board behaves quite well under load. For example, I stress-tested it with the yes command on all cores for about an hour or so and while the temperature went up to 95°, it appears the software was well-tweaked to only slightly throttle the CPU (verified with armbianmonitor -m) to not exceed this. I am not 100% sure about the thermometer readings, but I believe they were around 60° at the time, certainly nowhere near what sensors was showing. I have been testing the board for about a week now and I have to say that one time, the board did indeed shut down due to thermal overload. Interestingly, this wasn't even when the CPU was heavily loaded but there was a lot of IO wait. Temperature was high and it briefly shot up to 101° (ouch) which triggered an emergency shutdown to prevent thermal damage. Looked good to me, mostly. So, again, my question today is how trustworthy are the readings from the sensors, are they properly calibrated?