bedna

First of all, spamming balance on an SSD will significantly lower the lifespan of it. What you do is ask btrfs to relocate data-chunks that are occupying the % of a block, so that 1 goes fast is because they are very small (1%), but when you ask it to scan and look for a position to move chunks that occupy +50% it WILL take a long time, a veeeeery long time, not to mention 95%. You are basically just moving around data slowly killing your SSD. Read here: https://btrfs.readthedocs.io/en/latest/Balance.html#compact-under-used-chunks Btrfs will do this automatically in the background constantly when your computer is having extra cycles to do so. The only time it will be useful is if you remove massive amounts of data, then you can notice neither data nor metadata freeing up space. It can also be useful if you are using RAID because then it can move data between the disks. IIRC -susage is irrelevant for most users, what you want to move is the data and metadata, ie -musage & -dusage. If ever run a balance, it's when I remove big, and I mean BIG chunks of data, like 25% of the drive, and when I do, I start with 5, increment by 5 up to 35, NEVER more. But it is ONLY if I actually need the space immediately for something else, otherwise I just wait and let btrfs handle it by itself. So, with what you are doing with your cron running every day is literally killing your ssd... You should probably stop, IMMEDIATELY. With a --full-balance, you rewrite ALL DATA on the ENTIRE DRIVE! Better to have a scrub running once per month or every second week or so to know that your drive is in healthy condition... So what you are experiencing is not a bug, it's how it works, and in worst case scenario it might be your ssd about to give up... This link, albeit reddit describes it pretty good: https://www.reddit.com/r/btrfs/comments/hfpot9/what_does_balance_actually_balance BTW, you can check what it is doing while running by typing: sudo watch -n1 'btrfs balance status /path' But again, I HIGHLY discourage you do balance unless you ABSOLUTELY need to. Edit I missed that the filesystem has become read only when responding to this at 4am so lets edit this with a bit more info. Well, I'm sorry, it looks like you killed your drive, or at least the filesystem. The best you can do is try to copy all files on it to another drive (probably not worth trying to save the filesystem), format this one and pray that it's only your filesystem that became corrupt. But after reading how you treated that drive I think you should be prepared for it being damaged beyond a reformat, or that if you manage to format it, it will become corrupted pretty soon again, so I would not rely on that drive for backups... I have found SMART to not be reliable when it comes to health. If you like btrfs, I would recommend buying a rpi, a 6TB spinning drive, a hd case and run urbackup on that. That is what I use (rpi4 8gb, which is overkill, it never utilizes more than 2-3G memory on it, even though I use it as a backup server, nfs network drive AND is running a plex server on it) and it has been running flawlessly for years. (that reminds me, I might want to install something newer than rpi os bullseye on it, maybe armbian xD) I only make file backups, no images. Not very fast, but what does that matter when you only use it for backups. (I run the NFS network drive from another storage device, but that is beside the point) If you also use btrfs on the system you backup from, it creates a snapshot at runtime that it transfers files from, so there is no risk of corrupting files while the backup is running due to files changing during the backup. You would probably get all that for the same price as one ssd, or at least close to, spinning dives cost close to nothing. I have 5 clients connected to that backup solution, with 4 backups daily saved for about 2,5 months (one backup every 5hrs and backups paused between 3am-7am), and one archived every month to save for three years. ie 240 incremental backups per device. One of the clients backing up 1.13T (the others are smaller, between 100-350G each) but all of it only taking up about 5.5TB, and backups runs fast af, only copying changed data due btrfs and de-duplication (COW). I have NEVER had to run a balance on that device (only done it once before for testing). But since it is getting close to the threshold, let's make an experiment and run a balance on it with chunks up to 30%. There are 987 snapshots on that device (not all 5 clients has reached 240 backups due to not being constantly turned on, my laptop and my installed "fallback" os for example) $ sudo btrfs subvol list /media/backup | wc -l 987 This is before balancing: $ sudo btrfs fi df --si /media/backup Data, single: total=5.60TB, used=5.60TB System, DUP: total=33.55MB, used=606.21kB Metadata, DUP: total=31.14GB, used=27.71GB GlobalReserve, single: total=536.87MB, used=0.00B The balance up to 20% took about 5 seconds, then on 25 and 30 it took a while, about 10 minutes (I forgot to run it with time so this is an estimate with me looking at the clock when starting and when saw it had it ended) It only moved a minimum amount of chunks $ sudo bin/btrfs-balance.sh --backup If balancing takes a long time, open another terminal and run: sudo watch -n1 'btrfs balance status /path' btrfs balance will run on /media/backup Do you want to continue? [y/n] y Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=5 SYSTEM (flags 0x2): balancing, usage=5 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=5 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=10 SYSTEM (flags 0x2): balancing, usage=10 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=10 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=15 SYSTEM (flags 0x2): balancing, usage=15 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=15 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=20 SYSTEM (flags 0x2): balancing, usage=20 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=20 Done, had to relocate 0 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=25 SYSTEM (flags 0x2): balancing, usage=25 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=25 Done, had to relocate 1 out of 5253 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=30 SYSTEM (flags 0x2): balancing, usage=30 Done, had to relocate 1 out of 5252 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=30 Done, had to relocate 0 out of 5252 chunks Dumping filters: flags 0x6, state 0x0, force is off METADATA (flags 0x2): balancing, usage=30 SYSTEM (flags 0x2): balancing, usage=30 Done, had to relocate 1 out of 5252 chunks Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=30 Done, had to relocate 0 out of 5252 chunks This is after balancing: $ sudo btrfs fi df --si /media/backup Data, single: total=5.60TB, used=5.60TB System, DUP: total=33.55MB, used=606.21kB Metadata, DUP: total=31.14GB, used=27.71GB GlobalReserve, single: total=536.87MB, used=0.00B As you can see, no change whatsoever because btrfs does this in the background all by itself. And running higher % would not save any space, only take a ton of time, I'm pretty sure of that. If you want the script I used, here you go: (I have two btrfs filesystems on that rpi, modify to your liking if adopting) !/usr/bin/env bash # Check if script is run as root if [ "$EUID" != 0 ]; then echo 'THIS SCRIPT MUST BE RUN AS ROOT! (WITH SUDO)' exit 1 fi if [ "$1" == '--backup' ]; then METHOD='/media/backup' elif [ "$1" == '--usr' ]; then METHOD='/media/usr' else METHOD='all' fi echo 'If balancing takes a long time, open another terminal and run:' echo -e "sudo watch -n1 'btrfs balance status /path'\n" echo "btrfs balance will run on $METHOD" read -p "Do you want to continue? [y/n] " -n 1 -r if ! [[ "$REPLY" =~ ^[Yy]$ ]]; then echo '' echo 'Aborting...' exit 4 fi echo '' if [ "$METHOD" == '/media/usr' ] || [ "$METHOD" == 'all' ]; then btrfs balance start -v -musage=5 /media/usr btrfs balance start -v -dusage=5 /media/usr btrfs balance start -v -musage=10 /media/usr btrfs balance start -v -dusage=10 /media/usr btrfs balance start -v -musage=15 /media/usr btrfs balance start -v -dusage=15 /media/usr btrfs balance start -v -musage=20 /media/usr btrfs balance start -v -dusage=20 /media/usr btrfs balance start -v -musage=25 /media/usr btrfs balance start -v -dusage=25 /media/usr btrfs balance start -v -musage=30 /media/usr btrfs balance start -v -dusage=30 /media/usr btrfs balance start -v -musage=35 /media/usr btrfs balance start -v -dusage=35 /media/usr fi if [ "$METHOD" == '/media/backup' ] || [ "$METHOD" == 'all' ]; then btrfs balance start -v -musage=5 /media/backup btrfs balance start -v -dusage=5 /media/backup btrfs balance start -v -musage=10 /media/backup btrfs balance start -v -dusage=10 /media/backup btrfs balance start -v -musage=15 /media/backup btrfs balance start -v -dusage=15 /media/backup btrfs balance start -v -musage=20 /media/backup btrfs balance start -v -dusage=20 /media/backup btrfs balance start -v -musage=25 /media/backup btrfs balance start -v -dusage=25 /media/backup btrfs balance start -v -musage=30 /media/backup btrfs balance start -v -dusage=30 /media/backup btrfs balance start -v -musage=30 /media/backup btrfs balance start -v -dusage=30 /media/backup fi exit 0 This probably means I should manually remove some snapshots, because I did make a few massive changes that caused a lot of new data to be created, I do NOT want it to become filled. Conclusion: Don't run btrfs balance unless absolutely necessary, especially on SSD:s!

I assume you are talking about local connection here, not from the internet, so it's ngiinx webserver you are talking about, not nginx-reverse-proxy? Can you at least ping the ip of the server? Syncing apps might not connect over http or https (or rather, they probably don't), which your browser does. Are you sure letsencrypt works properly and it's not just your browsers refusing to connect over https due to missing/miss-configured ssl certificates? Does forcing http connection at least give you some response? As for using wget to test: "wget --spider <url>" should get you some info. It should look something like this for correct setup using https: (enter url without http or https, I have redacted url and ip for obvious privacy reasons) $ wget --spider <your_url_here> Prepended http:// to '<redacted>' URL transformed to HTTPS due to an HSTS policy Spider mode enabled. Check if remote file exists. --2026-05-23 14:48:27-- https://<redacted> Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt' Resolving <redacted> (<redacted>)... xxx.xxx.xxx.xxx Connecting to <redacted> (<redacted>)|xxx.xxx.xxx.xxx|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 0 Remote file exists and could contain further links, but recursion is disabled -- not retrieving. But as eselarm said above, we need way more information to be able to help.

For mate IIRC they use gnome's gnome-language-selector (start it in a terminal if you are missing the icon in settings), but it was a while since I used that desktop-env so I could be wrong. My old notes says the setting should be in: System > Control Center > Language Support For your information (as a fellow Swedish person): there is a locale called en_DK.UTF-8 that you might want to use instead. That way you get the correct settings for Scandinavian (like date/clock format for example) but the language is English. Or you can probably do it in terminal altogether: sudo dpkg-reconfigure locales # select en_DK.UTF-8 here, or whatever locale you want to use, I will use the dk version in this example localectl set-locale LANG=en_DK.UTF-8 sed -i "s/sv_SE/en_DK/" ~/.dmrc

Really? You changed the network config, installed a massive application AND enabled apparmor in the same boot... Cmon dude... It probably does, if you don't also change the network.

Ok, just wanted to know if you used the flatpak since they indicate on their wiki that could be troublesome. When you say "none of them can start automatically", what methods did you use to configure autostart? As they state at the top of the wiki/setup: "Distribution may provides some specific tool for autostart Fcitx and usually also set up environment variable together." Take notice of the word MAY. Seems Armbian does not. So what does im-config do as described on the next line after that on the wiki page? Does it fail or give you some hints of why autostart is not working? https://fcitx-im.org/wiki/Special:MyLanguage/Setup_Fcitx_5#im-config_(Debian/Debian-based/Ubuntu) This question is more fitting to ask the devs of the application, not the operating system. If you have problems with an application on windows for example, you generally don't ask microsoft for help but rather the developers of the application. But if you provide good enough information, we might be able to help you figure it out on this forum...

More information is needed. What armbian release do you use? How did you install fcitx5? Have you followed the instructions on their wiki? https://fcitx-im.org/wiki/Special:MyLanguage/Setup_Fcitx_5 Or read the FAQ? https://fcitx-im.org/wiki/Special:MyLanguage/FAQ Are you using a chromium based browser?

Are you using the rolling release? Otherwise you should not use "full-upgrade" but rather just "upgrade". Not saying that is the reason for missing deps, but it definitely could be.

@Giunti & @samlevy0515 It would be helpful to the community if you responded to the developer trying to fix this issue rather than state a workaround. Thank you.

(I am not part of Armbian other than the community, and have donated money, so I feel no obligation to be "professional") Ok, if you want to act like a clown, I'll treat you like a clown: Don't click unknown links, don't download unknown scripts or applications and you are fine. You know, use common sense. I'm sorry you feel "wronged" by this free and open source project because it doesn't focus the tiny amount of assets they have to manually remove something that pretty much is a nothing burger (and will be solved in the next update), unless you make yourself vulnerable by infecting yourself with with an RCE malware/virus or give physical access to people you can't trust. If you think making a text on their website would "protect" people, when this exploit has been mentioned by more or less every single linux outlet in existence, I don't know what to say. You are not doing this to "protect others", you do it for ego reasons. (Sorry mods, I won't respond more with the risk of starting a war, but if being mentioned in the way op did, I WILL defend myself.) Also, a link about Dirty Frag: https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html Mitigation:

This, even though serious, it's "only" a privilege escalation, not remote code execution (RCE), so if someone were to use this on you, they would first need to have physical access OR access remotely (RCE) to be able to run the exploit and escalate to root. And if you have a malware with RCE, you are already f**ed. In time, I'm pretty sure upstream patches will spread down to armbian builds too. In the meantime if you think someone might be able to get access and escalate, you can disable algif_aead (or try to apply patches yourself) as mentioned in https://xint.io/blog/copy-fail-linux-distributions Another solution is for you to pay a developer to do changes/testing needed If you don't "demand more labor", then why are you requesting more labor? (don't answer, it's a rhetorical question)

He meant this forum-post was moved to "staging". Maybe someone in the community will be able to help. (I can't help much with your problem, only explain what he meant with the post) Try what yourself suggested, run fsck from another system and see. But if a filesystem becomes readonly, it can mean that the drive is starting to fail physically.

"mmc1(part 0) is current device". Is that really a usb? Never seen a usb be named that, sound more like an internal storage.

I see. I actually tried to educate myself to see if I could help out, that is why I extracted the code in the first place. I would love to be able to help, but it seems outside of my capabilities. But I'll keep reading trying to learn, and maybe some day I will be able to make a pr rather than just a post on the forum. Thank you AGAIN for ALL you do!!

Maybe you already know, but to be sure (you guys are most likely always swamped), the keyrings workflow has failed the last two runs with the same error, on April 8 & April 15... https://github.com/armbian/armbian.github.io/actions/workflows/generate-keyring-data.yaml ERROR: Unable to find debian-archive-keyring package URL from https://packages.debian.org/sid/all/debian-archive-keyring/download Thanks for all you do! Edit With the limited understanding I have of this, I extracted relevant code and just ran a check on my local machine, and it returned: % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3012 100 3012 0 0 509 0 00:05 00:05 509 Debian debian-archive-keyring URL: http://ftp.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2025.1_all.deb % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3021 100 3021 0 0 532 0 00:05 00:05 532 Debian debian-ports-archive-keyring URL: http://ftp.debian.org/debian/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2026.02.04_all.deb (the reason it took 5s was due to the time it took me to press "allow" on the outgoing curl connection in my firewall) So maybe it was just a fluke, and it was just really unlucky failing resolving to packages.debian.org instead of ftp.debian.org those two times. Idk, just wanted to make sure everything was correctly configured. Ignore this if all is ok.

@MMGen First, thanks for a great tutorial! I have a question about gpt. I maintain shrink-backup and I use dd to copy "boot sector" and rsync the rest (VERY easily described) But I do not distinguish any difference between if it's mbr or gpt when using dd, I just copy everything before root partition with dd (and a few MiB extra) then format root, rsync, yadayadayada... (not important) So I got curious why you skip the first 64 512b blocks in the dd for gpt? (for others reading, the 512 is because fdisk ALWAYS returns 512b blocks, even though gpt is actually 4k blocks) dd if=$(echo *.img) of=/dev/sda bs=512 skip=64 seek=64 count=32704 Can you explain why? I tried to find something online referencing the first 64 512b blocks of a gpt partition table, but could not find anything. I would really appreciate you educating me, or some links where I can read up on the reason. Thank you!