For brevity I had not added it in the message but I had tested it in the “porteus.cfg” as well.ncmprhnsbl wrote: ↑06 Oct 2024, 04:45could be a bug..it's possible that this is one cheatcode that won't work via the cheatcodes config
.. in this case the APPEND line in /boot/syslinux/porteus.cfg is the way to go..
The reason I wasn't sure if I had done the right thing because I made the changes first and then tried to create the savefile.dat.
But in theory if it works as a directory maybe I have to create the files and do AFTER the changes and I shouldn't worry about saving the status. In short a kind of someting between the save directory and the save module systems.
So actually maybe it would be better for me to have some info on how it works before assuming that it doesn't work.
I'm proud of myselfsounds correct, though not ideal
I have verified and it is as you say, on an external volume everything works (I have already merge some changes, on reboot I will try it). I tried to understand well what you are referring to also by translating the message into my idiom, however I simply do not know what these whiteout files are and so I simply do not understand it out of my ignorancecertainly, a check for a same named module that would overwritten should probably occur, with at least a warning.
it is possible to xzm2dir a save module with whiteouts in a posix directory outside the live filesystem ie. some mounted volume (which admittedly isn't always available)
I will try this as well, however I generally don't like making changes to the structural operation of a distro because then it means that every time I reinstall I have to remember to apply all the changes to patch the standard behavior.but, there's probably no reason for those whiteout files (.wh..wh.*) to be included in the first place, so here's an edited /usr/local/bin/save-session that should exclude those:
...code...
which will allow for extraction within the live filesystem.
(also excluded /mnt for the hell of it)
which has me thinking of moving the exclude list to a user configurable one somewhere in the config folder.
But then in case the change works correctly will you integrate it into future versions of Nemesis?
This is one of the themes that has given me the most concern about the other distros I've used.EDIT:
just looking at the config folder, i noticed the "backup" file:
...code...
first correction: it should be /usr/local/bin/backup-config-module
this should work in the opposite fashion to save-session, only keeping what is explicitly included, which is handy when you know exactly what you want to keep, not so much if you don't.
Because in my opinion this thing makes a distro completely under the control of its administrator.
In alpine, management seemed perfect because the file allowed you to specify both files/directories to add (by prefixing a + to the path) and those to remove (by prefixing a -) and it supports star notation to specify sets of files.
However, they have an open bug report from me for 5 years of a problem in this system....
That is why I would like to take it gentle by making requests on this issue that is already very tricky for me, at least waiting until I better understand how it works.
I can say that I personally like to do a lot of experiments on the distro even breaking the functioning until I find the right way and then save only those changes.
The fact that the creation of save modules on porteus works in “layers” if well leveraged could also be a big advantage in this regard!
