Porteus

Hi you all,

After the unfortunate crash I suffered from last month, I have become quite paranoid with my new install.

I have set up the system to boot with changes save on exit to a save.dat.xzm file. This worked great until it started to know error messages on boot like "cp: cannot stat yaddi yadda...". Sadly, the boot screen changes too fast for me to snap it or something.

Nonetheless, the state of the system I inherit from this is useless. I think it has to do with the download and installation of the heroku toolbelt.

Fortunately [because I am now paranoid], I have saved sessions as modules to serve as recovery points after every important steps of my configuration/package-installation process.

So I have a session module 'changes-160723.xzm'. Loading great. Now I want it to be some sort of recovery point and want my save.dat.xzm to pick up from that module.

Renaming that session module to save.dat.xzm doesn't seem to work BTW.

Looking forward to your always-enlightening inputs. Thanks.

igreka wrote:I have set up the system to boot with changes save on exit to a save.dat.xzm file.

Really!! I wasn't aware that changes=EXIT would work with a non-.dat file.

This worked great until it started to know error messages on boot like "cp: cannot stat yaddi yadda...". Sadly, the boot screen changes too fast for me to snap it or something.

A trick I use to catch boot errors is to add a 3 to my boot options. This stops system from booting to the GUI desktop.

Nonetheless, the state of the system I inherit from this is useless. I think it has to do with the download and installation of the heroku toolbelt.

So I have a session module 'changes-160723.xzm'. Loading great. Now I want it to be some sort of recovery point and want my save.dat.xzm to pickup from that module.

If you create a new save.dat file and use it to boot together with your changes xzm module I think it will pick up from that module. (Not knowing how your changes module is created.)


BTW A thought I had recently for creating a changes module was to create the module using the contents of the /mnt/live/memory/changes folder. Haven't tried it, just a thought.

Really!! I wasn't aware that changes=EXIT would work with a non-.dat file.

Well, I took a regular save.dat file and appended '.xzm' to the filename and moved it to the porteus/modules folder. It seemed this approach served its purpose of recording changes to the system. However, I can't say if it was sound to do so.

If you create a new save.dat file and use it to boot together with your changes xzm module I think it will pick up from that module. (Not knowing how your changes module is created.)

I tested that hypothesis to no avail as so:
1. Start in AF mode;
2. Create brand new save.dat file;
3. Touch 'testing' empty file to /home/guest/Desktop;
4. Save session to /porteus/optional/sessions; <---- I created that subfolder initially to save all my... sessions 8)
5. Reboot in AF mode with changes=EXIT:/path/to/save.dat load=sessions/session_file;
Note that at this point, the empty 'testing' is there safe and sound.
6. Touch 'testing2' next to poor lonely 'testing';
7. Reboot with the 'changes' and without the 'load' cheat codes;
Result: 'testing2' is now seating there all alone.

My take is that the 'changes=' cheat code only record changes to the filesystem made from and after the point where it was enabled. Thus it disregards all the previous changes recorded by the session file.

So I guess I cannot use sessions as recovery points unless I always want to use the 'load=' cheat code in which case what would be the point of using 'changes=' in the first place?! right?

Maybe a smarter approach would be to use 'save-changes /path/to/new_save_file' and then rename that file to 'save.dat' whenever I need to recover back that 'state/point in time'. I tried that with a session module and my 'save.dat.xzm': it fell miserably. I going

igreka wrote:Well, I took a regular save.dat file and appended '.xzm' to the filename and moved it to the porteus/modules folder. It seemed this approach served its purpose of recording changes to the system. However, I can't say if it was sound to do so.

igreka wrote:Maybe a smarter approach would be to use 'save-changes /path/to/new_save_file' and then rename that file to 'save.dat' whenever I need to recover back that 'state/point in time'. I tried that with a session module and my 'save.dat.xzm': it fell miserably.

Should have been in modules folder?

See DAT entry here http://forum.porteus.org/viewtopic.php? ... 069#p47320