similar thing happened to someone I switched to linux via mint. The latter provides timeshift, makes backups automatically until fills up root partition, user cant login anymore after that. 
My systemâs been successfully running on Zen-kernel with BTRFS for almost 2 years. It couldnât have been better, but I never used any additional features that BTRFS provides as well as my hardware is far from being cutting-edge. Iâve got a 3-year-old Thinkpad. So I just decided to stick with LTS-kernel and Ext4 as it would be even more reliable.
That is easily fixable, just chroot and delete the snaps or other stuff hogging up the space. But cleaning up root SHOULD be automatic after every backup/update.
1 Like
Wonderful idea. I do the same. I also clean the package cache after every update. Not one problem with space, ever.
me included i love me some automation, and i do need the updates to catch me first at least on the main OS i run on the bleeding edge, indeed not hard if it break i have currently 5 other drives with OS instances 
I have a habit of using âsyncâ on a tty before ejecting any removable media. Plasma has a habit of saying, âyep, all done!â within milliseconds, while the usb mediaâs still hammering away on read-cycles. Trust the tty!
That is because caching is enabled and while the write has successfully âfinishedâ, it hasnât actually persisted it to the disk. If you tried to eject/unmount the device from within plasma, it would not let you know it can be removed until the actual write finishes.
Donât want to create new thread, so Iâll ask here.
Despite arch-audit-gtk showing green shield (everything Ok), underlying arch-audit prints this result:
~ ⯠arch-audit
minizip is affected by arbitrary code execution. Critical risk!
linux-lts is affected by multiple issues, information disclosure. High risk!
cpio is affected by arbitrary command execution. Medium risk!
giflib is affected by information disclosure. Medium risk!
libtiff is affected by unknown, denial of service. Medium risk!
linux is affected by multiple issues, insufficient validation. Medium risk!
openjpeg2 is affected by arbitrary code execution. Medium risk!
openssl is affected by arbitrary command execution. Medium risk!
openvpn is affected by information disclosure. Medium risk!
perl is affected by signature forgery, directory traversal. Medium risk!
wget is affected by information disclosure. Medium risk!
xdg-utils is affected by information disclosure. Medium risk!
p7zip is affected by denial of service. Low risk!
There is linux-lts with high risk CVEs. According to security page only three versions 5.15.xx are affected but I have 6.6.13. Same deal with other packages from the list - actually installed versions are not the same as affected.
Why arch-audit mentions those packages at all - so that the user wont downgrade to affected version? I donât understand the logic behind it.
arch-audit -u shows you the packages that have security issues that are actionable.
6 Likes
This arch-audit tool seems to be counter-productive to running a stress-free EndeavourOS.
3 Likes
Very useful - thank you.
3 Likes
Welcome aboard! 
Have fun!
1 Like
Thank you 
Whereas, this is mostly sound advice, there are certainly things I think are debatable, missing, and understated; primarily:
- My #1 tip would be to read System maintenance - ArchWiki.
- It stress âUse precaution when using packages from the AUR or an unofficial user repositoryâ, which Iâd read as âStrongly prefer flatpak or AUR appsâ. In my experience, AUR has caused my of my grief with Arch â but I do include some AUR including
downgrade
- It stresses âAvoid doing partial upgradesâ (unmentioned herein) and other advice not mentioned.
- It stress âUse precaution when using packages from the AUR or an unofficial user repositoryâ, which Iâd read as âStrongly prefer flatpak or AUR appsâ. In my experience, AUR has caused my of my grief with Arch â but I do include some AUR including
- My #2 would be to have a surgical backout system or snapshot system in place (which different than âbackupâ although overlapping). That means BTRFS or timeshift or whatever (although I donât trust timeshift ⌠BTRFS would be my suggestion since it has EndeavourOS support. Ensure you know your snapshot system, practice it, trust it, and takes snapshots before updates and periodically.
- I disagree with ~Have some amount of swap~. For example, have 1GB swap on a 32GB RAM system, provides almost no protection from the OOM killer. Iâd say, if you have enough RAM that you âneverâ exhaust it, then donât bother with the complexity of swap; otherwise, configure enough to make a difference (e.g., the minimum of 8GB or your amount of RAM). Use a fast swap device (e.g., NVMe or zRAM preferably).
- I disagree with ~Use a minimal maintenance routine~. Iâd rather a smallish root (e.g., 50GB) kept tidy than an a needlessly huge package cache threatening running out of space if neglected. I use rungs to ease doing my regulary maintance (although I do skip steps like updating mirrors if done very recently).
- I disagree with ~Dontâ re-use /home~. I almost always re-use home (although big stuff, like media files, I separate entirely and I use the cloud for really important documents. After doing dozens of /home re-uses, I have never experienced any dangers (especially if /home is a snapshot of another), but I have experienced saving much time tweaking my desktop after install.
- There is other advice (~Donât multi-boot~) that is simply paternalistic; doing such things comes with risks if you donât know what you are doing ⌠so such advice needs to be qualified.
Iâve been running EndeavourOS since the beginning. Itâs as stress free as they come!
2 Likes
Let me further clarify the intent behind this advice. This isnât âa list of things everyone should doâ. It is a list of ways to make your usage of EndeavourOS simpler and more trouble free. Especially if you are someone who isnât interested in spending a lot of time tweaking your system or dealing with things.
If you are a Linux enthusiast who enjoys trying new things out, experimenting or using complicated configurations, then you should do whatever makes you happy or makes your system the most reliable. There is no one right way to do things.
Even I donât follow all of this advice on my personal installs. In some cases, I do the opposite of these things.
Where this advice comes from is from supporting many, many people over a long period of time and noticing what tends to cause people problems.
For example, I think it would be hard to argue that not multi-booting makes your system simpler and less prone to failure. Does that mean you shouldnât multi-boot? No.
This one is interesting to me. I actually mention this directly in my points above in less detail but setups like this are double-edged sword. On the one hand, if you know what you are doing you can use a snapshot to recover from breakage easily and quickly. On the other, I have seen so many people break their systems past the point of repair trying to a restore a snapshot(btfrs and timeshift). Again, I am noy saying that this is a bad idea and nobody should do it. However, I also believe that this isnât something everyone should do.
In general, I think it is better to do what you can to avoid breaking your system in the first place than to rely on a recovery system if your system breaks.(I am talking about snapshots here, not backups. Everyone should have backups)
Some people seem to think that breakage is unavoidable on an Arch-based distro. I fundamentally disagree with this. If you operate your system in a simple manner, you can pretty easily avoid breakage. That is what this tutorial is about. How to run your system in a way that minimizes the chance of breakage.
8 Likes
1 Like
I do updates every day and I even install them during work hours, on my desktop system that is
1 Like
Tip #2 is really sound advice. We have a weekly chore list on our fridge, and âpacman -Syuâ was added to Saturdays 
thereâs probably a better way to do that, but it gives me the weekend in case something breaks.
2 Likes
Dangerâs my middle name
1 Like