Testing live persistence

[Jerry3904]

If we need to add something to the doc on "Persistence," please post revised/additional copy.

TIA

[BitJam]

Works pretty well. If you run halt as a regular user, the save still happens before the warning that you have to be superuser to run halt.

Ah. That's a bug in my program. I will fix it. Thanks.

One other point...if you want to talk about old-school commands, you might want to also link shutdown (as in shutdown -h now).

My thought was to leave "shutdown" alone so it gives people a way of shutting down from the CLI that bypasses my bypasses. I figured that if a program was going to call a program to shutdown or reboot then it was more likely to call "shutdown" rather than "halt" or "reboot". Also, both /sbin/reboot and /sbin/halt are in /etc/sudoers.d/antixers so normal users are allowed to run those commands without entering a password but /sbin/shutdown is not. OTOH, please feel free to try this:

Code: Select all

ln -s xfce4-session-logout /usr/local/bin/shutdown

You can then see if it interferes with anything. It will work better in the next version that adds "sudo". That was the bug above, I forgot to use "sudo".

If we need to add something to the doc on "Persistence," please post revised/additional copy.

I will post a blurb about intercepting commands. I will leave it to you (or others) to decide if and where it should go in the docs. PLMK if this is not what you meant.

[BitJam]

I've attached version 0.02. It adds "sudo" when the real path to the command contains "/sbin". It also passes on command line parameters. For example "reboot -t x y z" eventually results in this output:

Code: Select all

TEST: sudo /sbin/reboot x y z

[dolphin_oracle]

Nice work! Works really well.

[BitJam]

If we need to add something to the doc on "Persistence," please post revised/additional copy.

The following two statements are usually both true:

• There's not enough documentation.
• There's too much documentation.

IOW, please feel free to heavily edit this to make it more suitable for users (from your perspective). Or ask me to trim it down. I often tend to go into too much technical detail. I think you want a users manual, not a technical reference manual. It is possible that users don't need to know any of the information I give below.

BTW: I think users/testers/anti should decide exactly which commands we highjack for persist-save. Certainly we should highjack xfce4-session-logout. I'm not certain about halt, reboot, shutdown, or poweroff.

Dynamic Root Persistence and Persist-Save
When Dynamic Root Persistence (DRP) is enabled, filesystem changes are stored in RAM just like on a Live system without persistence. In order for your changes to be saved, they must be copied to a disk-based filesystem. That is what the persist-save program does. If DRP is enabled then you are always free to run persist-save via the RemasterCC menu. You can also configure persist-save to run every time the system shuts down. If you select automatic-mode then the saving will happen without first asking if you want to proceed. In semi-automatic mode, you will be asked if you want to save or not. In manual mode you have to run persist-save yourself in order for your changes to be saved.

In order for the automatic and semi-automatic modes to work, we created a xfce4-session-logout program in /usr/local/bin. The actual xfce4-session-logout program is in /usr/bin. Since /usr/local/bin has higher priority in the $PATH variable, our version gets used when xfce4-session-logout is called without an absolute path specified ("xfce4-session-logout" instead of "/usr/bin/xfce4-session-logout"). This is exactly how it is called from within the XFCE GUI. If DRP is not enabled then our program just calls the real xfce4-session-logout and the system behaves normally. If DRP is enabled then we will first call persist-save (if the save mode is automatic or semi-automatic) before we call the real logout program.

If the $PATH variable gets changed so /usr/bin has higher priority than /usr/local/bin or if you call the real program directly as /usr/bin/xfce4-session-logout then you will bypass our version of the program and persist-save will not get run automatically at shutdown. Our mechanism might also get broken if the /usr/share/applications/xfce4-session-logout.desktop file gets changed to use the full path to the real xfce4-session-logout.

We have done the same thing with the "reboot" and "halt" programs. If DRP is enabled and you run either "reboot" or "halt" from the command line then we will first call persist-save before shutting down or rebooting. If you use the full path to the commands: /sbin/root, /sbin/halt then you will bypass our versions and persist-save won't be run automatically.

Static Root Persistence and Live Shutdown
One of the beauties of Dynamic Root Persistence is that persist-save is run while the system is fully up and running so it is trivial to make sure the rootfs file and the partition it resides on are cleanly unmounted. We don't have this luxury with Static Root Persistence (SRP) because the root file system must be unmounted before we unmount the rootfs file and the partition it lives on. We solve this problem by running pivot_root in the /init script in the initrd (technically, the initramfs) of the Live system and then running switch_root during shutdown. On the Live system there is a small set of tools based on busybox that is stored entirely in RAM. It lives in the /live directory. The switch_root command turns the filesystem inside-out and makes what was originally /live into the root filesystem. This gives us the fulcrum we need to unmount the normal root filesystem and still have access to common Linux/Unix commands for cleanly unmounting the rootfs file and the partition it lives on. We always run the Live shutdown this way even if there is no persistence enabled. Because of the /live fulcrum, this method of shutting down is more robust than the standard Debian shutdown procedure. Perhaps someday this more robust way of shutting down will become common practice.

We have our own Live versions of the sendsigs and umountfs shutdown scripts that initiate the process described above. They both call the program /live/bin/umount-live. You can see it in action in the first screen shot below. More detail is available by using the uverb= boot parameter. The second screen shot shows the output with uverb=7. The default value is 6. You can use the ubp= boot parameter to set breakpoints during the Live shutdown. setting ub=a (lowercase "a" for almost all). This can even allow you to run a shell after all the filesystems have been unmounted.

[taydui]

I found that persistent feature works well for both static and dynamic but remaster one terminates early with null error and nothing created.

[BitJam]

I found that persistent feature works well for both static and dynamic but remaster one terminates early with null error and nothing created.

Thanks! There should be a log file at /var/log/live/remaster.log (or something like that). Could you post it please? Maybe we should move this to a new thread?

If you can't get the log file, then I'd like to know more specifically when/where in the remaster-live process it terminated early. You can try running "sudo remaster-live -c -v" in a terminal window. The -c option tells it to stay in the terminal (--cli) and the -v option (--verbose) tells it to print a little more. Still, most of the info I want should be in the log file.

Has anyone else tried to remaster the Live system?

If a non-colorized version of the log file is not available then a simple trick to get rid of the colors is to cat the file in a terminal window and then copy and paste from there. gzipping the log file and attaching it is another good solution. If you need to post from a different machine then you can copy the log file to your usb stick (assuming you are running a LiveUSB) with:

Code: Select all

sudo cp /var/log/live/remaster-live.log /live/boot-dev

IOW, the LiveUSB you booted from is mounted at /live/boot-dev.

Thanks again.

[taydui]

Here you are!
Thank you for your respond, i tried it again.
1st try using remaster gui: failed!
2nd try using command line: WOW it worked!
I attached 2 log files so you can check.

[BitJam]

@taydui, there is a bug in the antiX-common.sh library that had hard-coded "roxterm" as the terminal emulator. The crash happened because roxterm does not exist on MX-14. The fix is to change line 21 of that file to and replace "roxterm" with "/etc/alternatives/x-terminal-emulator". Here is a patch which also fixes the GUI_FILER:

Code: Select all

--- /live/linux/usr/local/lib/antiX/antiX-common.sh	2012-12-13 05:52:01.000000000 -0500
+++ /live/aufs/usr/local/lib/antiX/antiX-common.sh	2014-02-10 03:12:43.308476250 -0500
@@ -18,11 +18,11 @@
 # This is needed for restarting
 CMDLINE_ARGS=("$@")
 
-       GUI_TERM="roxterm"
+       GUI_TERM="/etc/alternatives/x-terminal-emulator"
       TERM_OPTS="--geometry=+50+50 -e"
  TERM_TITLE_OPT="--title"
-      GUI_FILER="rox"
-     FILER_OPTS="--new -d"
+      GUI_FILER="thunar"
+     FILER_OPTS=""
 
         ARCHIVE="archive"
 

I've also attached the patch as a file.

Again, thanks for your help, taydui.

[taydui]

Everything works well now.
Thank you !