i found that using 'chattr +i' immutable flag on the 'theme.conf.user' file to keep the SDDM login screen background from reverting back to theme's default image on every login to be a very bad idea, as the 'immutable' attribute gets inherited by every single iteration of that file created by manual snapshots.
when this happens snapper/timeshift only LOOKS like it actually deleted the snapshot, but it is still there in it's entirety hidden in a folder that you can't even sudo delete due to the 'immutable' attribute set on ONE FILE.
i found 7 full 6-7GB snapshots filling up my rather small 40GB OS core installation partition.
i was actually able to boot into a snapshot from october that was deleted in mid december >.>
to remove them i had to unflag the attribute on the original parent file, then had to remove the same from every snapshot iteration of that file.
to make this easy i booted into a live-disk environment, set all the hidden snapshot folders' ownership to root and then deleted the folder and contents as root.
this lagged out dolphin for a minute but managed to remove all the folder contents EXCEPT the immutable file, making it easy to find the offending files individually and remove the chattr +i flag.
after this, full deletion of the snapshot folders and all contents was straightforward.
I know I'm probably the one who suggested that approach some time ago, and I apologize for that (I was not aware at all of that drawback).
At least, in the same post, I suggested a possible different approach (name your background like the standard one, hopefully not changing, at least frequently).
SDDM should honor a custom theme entry in /usr/share/sddm/themes/ if you adhere to the naming convention. You can easily change the background on your custom theme, or any other attribute you wish to modify, without needing to worry about the file that is being overwritten.
To override settings in the theme.conf configuration file, create a custom theme.conf.user file in the same directory. For example, to change the theme’s background:
i changed the name of the image i wanted to 'bg.jpg', the same as what's in the theme files, and it seems to stick for now. (Garuda server room image i ninja'd from the forums here)
the login image is a small matter anyway, i just wanted to let others know of the snapshot issue so they can be prepared for the unintended consequences of flagging a file as 'immutable' =-)
-refers to the original default file found in the default SDDM login screen folder in the default location where it gets installed by default, as suggested in this forum post:
snapper/timeshift:
this happened before, over a year ago with an older version of Garuda with Timeshift, this time it happened with Snapper, so it’s the actual snapshot function - the specific interface software is obviously irrelevant.
i nuked and reinstalled just last october due to my root drive filling up and it’s happened again and now i know why.
path:
the snapshots were in the root directory, each with their own @snapshot folder name, i think they hand the date built into the numbered section of the file name but the metadata like the name i gave the manual snapshot and creation date were gone, most likely deleted when i thought i deleted the entire thing.
i had the idea to look around my root folder from windows because of a randomly numbered btrfs process that repeatedly refused to shut down when shutting down or restarting the system. i think this was a process/s that was trying to delete this crap and hanging due to the immutable flag on the one file it can’t delete.
i could cannot see the snapshots while in the main Garuda install, not from Snapper nor from btrfs Assistant. i first saw them while looking around from windows, which is why i saw to use a live-disk interface to remove them. my windows 7 brtfs driver will not provide admin overrides so i had to do it from a live-disk.
