After working with Debian Bullseye for several months, I decided to give SparkyLinux a try, and have installed Sparky 7 (semi-rolling), based largely on Debian Bookworm.
Once I have the basic setup to my satisfaction, I would like to save a snapshot of the configured system, and perhaps make a bootable Live USB. I note that Sparky offers two solutions:
- SystemBack (first offered by Sparky in July 2021)
- Sparky Backup System (reportedly around since 2012; a fork of Remastersys)
My first impulse was to try SystemBack, as it is a more-recent offering from Sparky, and I had dabbled with it in the past. However, I have been unable to get it running properly on Sparky. When I try to select a target directory, SystemBack shows ALL my folders being inaccessible ("x" prefix and red font), and gives the message "Writable Linux File System!" at the bottom of the folder tree. I guess this implies it does not have access to any of my folders on the system disk or attached USB drives.
Of course, the system refused to let me try "sudo systemback," or "gksudo systemback," as those approaches to GUI apps have been deprecated as unsafe. I also tried "sparky-su systemback," which asked for root password also, and was once again refused. The command "spsudo systemback" met the same fate.
I get the impression that this is not really about whether my file systems are "Writable Linux Filesystems" (they are all ext4), but rather about obtaining adequate permissions to my drives/folders. Yet the system -- for good reason -- rejects running a GUI app with root privileges. When I used systemback-sustart, I got this
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
I WAS now able to sign in with my USERNAME and USERPASSWORD (not root), but I still did not get access to my drives/folders. I am not smart enough to interpret the message returned from the terminal, which suggests a default to root again.
At this point, I am asking if there is a know solution to making SystemBack work properly (provide access to my drives/folders). I apologize in advance if I am simply missing something basic, or if I have overlooked a solution that has already been posted here or elsewhere.
If I have no solution for SystemBack, I will next try Sparky Backup System, which seems to have much more discussion here on the forum. I notice that installing Sparky Backup System will automatically remove SystemBack, so I hope to find answers about SystemBack before proceeding.
Upstream is always important. Is fconidi still the maintainer of the the fork? his git was updated May 2020.
If sunrat and HOAS had problems with it in 2020 as in a post back then in Debian Forums, it might be EOL (End of Life) for systemback.