Several doubts about savestate

Forum Forums Official Releases antiX-21/22 “Grup Yorum” Several doubts about savestate

Tagged: 

  • This topic has 18 replies, 5 voices, and was last updated Feb 22-8:51 pm by Brian Masinick.
Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
    Posts
  • #75948
    Member
    ctcx

      Tried savestate function on a USB stick made with Live-usb-maker, which seems to be default enabled when making USB this way.

      —If theoretically regular files and directories can also be supported, what difference would there be with persistence mode? Even assuming savestate is seemingly thought for “smaller saves”.

      —There are “general” and “machine” state config files. But, how to configure the “user” part? It currently just copies automount.conf and default-desktop both from ~/.desktop-session.
      (And how does default.desktop work? At boot it doesn’t really follow the set “default desktop”…)

      —Finally, can savestate be used with live CD/DVD? As in, someway specifying which device the savestate config files are in…

      Thanks beforehand again.

      #75955
      Anonymous

        >> can savestate be used with live CD/DVD?
        ^-v
        quoting download.tuxfamily.org/antix/docs-antiX-19/FAQ/boot-params.html (available via link provided in antixforum headerbar):

        savestate (LiveUSB Only)
        Save certain “state” files across reboots even without persistence enabled. Also save certain machine-specific state files across reboots. You can control which files get saved by editing the files /live/boot-dev/antiX/state/general-state-files and /live/boot-dev/antiX/state/machine-state-files. Those files and the directory they are in will be created automatically the first time you boot the LiveUSB. This is enabled by default and it is “sticky” so once you enable it it will stay enabled until you turn it off. See below.

        nosavestate (LiveUSB Only)
        disable saving state files. See description above. This too is sticky so when you use it saving state will stay disabled until you re-enable it.

        additional note:
        savestate is implicitly ON by default; use the nosavestate boot parameter if you wish to switch it off.

        p.s.
        This information is also available via the forum search.
        It was last parroted to someone who had neglected to read the docs by Xecure, on Dec 11, 2021, within post #72769

        • This reply was modified 2 years ago by Brian Masinick. Reason: From skidoo
        #75959
        Anonymous

          —If theoretically regular files and directories can also be supported, what difference would there be with persistence mode? Even assuming savestate is seemingly thought for “smaller saves”.

          —There are “general” and “machine” state config files. But, how to configure the “user” part? It currently just copies automount.conf and default-desktop both from ~/.desktop-session.
          (And how does default.desktop work? At boot it doesn’t really follow the set “default desktop”…)

          My response here would be phrased differently if you had described “what you are trying to accomplish yet have not found a way to do so”

          No, savestate is not intended for “smaller saves”. It accomplishes “general” and “machine” state saves; independent of persistence, it preserves alsa sound settings, network settings, across reboots (and/or if it detects that boot is occuring on a different, aka not previously seen, machine). Bear in mind: during each liveboot, we have the opportunity to invoke persistence (or not) for the current boot session. If persistence is selected, peruser saved details are saved within the rootfs file or homefs file (depending on the currently-selected persistence mode), and are only referenced later if/when the relevant persistence mode has again been selected.

          To fully understand the nitty-gritty details of how savestate works and/or to tweak its functionality,
          you would need to unpack the initrd.gz and refer to the save_state() and restore_state() functions within the script /etc/init.d/liveusb-save

          ^— The hyperlink points to a viewable copy of the script (perhaps not up-to-date with that found in antiX 21) residing in the antiX live-initrd.gz sourcecode repository at gitlab

          someway of specifying which device the savestate config files are in ?

          The expected paths of the state files are hardcoded (are unaffected by use of the bdir= boot parameter).

          • This reply was modified 2 years ago by Brian Masinick. Reason: From skidoo
          #75963
          Anonymous

            excerpt from a 2015 post by BitJam which I found in the antixforum archive
            antixlinux.com/forum-archive/antix-15-b3-v-saving-state-on-the-liveusb-t5639.html

            General state files are saved across all machines. This is being used to remember wireless networks and passwords. Machine state files are saved and restored on a machine by machine basis. If you only use the LiveUSB on one machine then they act like general state files but if you move the LiveUSB between machines then machine state files will only be restored to the machine they were stored on.

            The reason for this is a conflict between making the LiveUSB work on different machines and saving the alsa volume. The file that stores the alsa volume also contains hardware specific information and will cause errors if it is used on a machine that has different hardware. To make a LiveUSB that has persistence general purpose (so it works on more than one machine) then we need to delete the volume information. Machine dependent state files keep a separate copy of the asound.state file for each machine the LiveUSB is run on. Machine are identified by a machine-id which is a hash of the files /sys/class/dmi/id/board_*.

            The restoration of general state files and of the desktop session file is disabled if persistence is enabled. But the files are still stored at shutdown and will be available on the next non-persistent boot. The machine state files aways get used unless saving state is disabled. This should prevent alsa error when you move the LiveUSB between machines.

            Let’s wait for someone else to clarify // verify this detail:
            “The restoration of general state files and of the desktop session file is disabled if persistence is enabled.”
            (I’m unsure whether this detail is still true nowadays, seven years later, for antiX 21)
            edited to add:
            Yes, this detail appears to still be accurate. Per the github-resident copy of live-usb-save, restore_state() within the live-usb-save script contains the following inline comments:

            
                # Always restore machine specific state files
                restore_state $root_dir/$MSTATE_DIR "$(state_files "$file_list")" "$(mach_id)" $cmd
                # Only restore general state files and user files if root persistence is not enabled
                # Not saving state when I enable persistence was a pain.
                # We'll see.  Maybe just restore it the first time?!
                #test -e /live/config/persist-root && return
            • This reply was modified 2 years ago by Brian Masinick. Reason: From skidoo
            #76028
            Member
            ctcx

              Once again apologies. Though, FWIW, I did read that thread in the old forums; just perhaps wasn’t able to fully understand everything…

              During the weekend I was doing tests with the persistence functions. At one point, I noticed some “restore state…” thing in the live-init logs; noticed the antix/state directory in the live USB, and searched about it.

              It seemed to me as if an “abbreviated” (and quicker?) version of persistence, designed primarily for saving configuration files and perhaps some regular files and directories, by using a regular directory instead of a “filesystem”.

              So what I wanted to “accomplish”, if possible, was selecting the user-related stuff to be copied as well just like the general and machine cases. But looking at the script, it seems only those 2 desktop-related files are hardcoded to be copied on the user side…

              I also already suspected that savestate function was exclusive to LiveUSB, but I thought it’d be “harmless” to still ask just to be sure. Guess not…

              Well, I think I was perhaps expecting an excess from savestate function.
              Sorry again, and thanks for your help.

              #76034
              Anonymous

                No apology necessary here. I’m pleased to know you’re interested in “digging in and exploring under the hood”. In retrospect, I suppose I should have led with the content of my second post here as the FIRST post, then more gently mentioned in my followup post: “This information detail is covered in the boot-params.html doc.”

                I was doing tests with the persistence functions. At one point, I noticed some “restore state…” thing in the live-init logs

                Persistence involves a separate mechanism.
                The save_state() and restore_state() routines, bound to the savestate|nosavestate cheatcode, are unconditionally performed during each antiX liveboot session ~~ irrespective of whether persistence has been elected for the current session.

                what I wanted to “accomplish”, if possible, was selecting the user-related stuff to be copied as well

                [..]

                primarily for saving configuration files and perhaps some regular files and directories, by using a regular directory instead of a “filesystem”.

                > using a regular directory instead of a “filesystem”

                After invoking the “dostore” cheatcode (the flag for which remains set until//unless you specify “nostore” during a subsequent session)
                you can save files to ~/LiveUSBStorage/ or a subdirectory thereunder
                and utilize a script called from your user’s ~/{.icewm,.fluxbox,.jwm}/startup file to copy them into place

                Howabout the prospect of stuffing select files into (and extracting// restoring from) an archivefile instead of a “filesystem”?
                If that’s of interest to you, refer to my discussion of xtra.tgz in post #15568
                (a separate post within that topic also discusses the related doxtra|noxtra cheatcode)

                “persistence” (er, the antiX persist-save command)
                achieves the goal of faithfully saving all files which have not been (per file, or via wildcarded exclusion patterns) specified withing an “exclusion” file.
                ( you might be interested to inspect, and edit AsRoot, persist-save-exclude.list and the other /usr/local/share/excludes/*.list files )

                • This reply was modified 2 years ago by Brian Masinick. Reason: From skidoo
                #76036
                Member
                ctcx

                  Howabout the prospect of stuffing select files into (and extracting// restoring from) an archivefile instead of a “filesystem”?

                  Certainly interested.

                  Already read the post there. Just a couple of doubts:
                  —If opting for the xtra.tgz, how should I put files/directories there to build it? Should I create the full directory paths for each thing (/home/<user>/.config/geany/[…], /home/<user>/.mozilla, /etc/[…]), just put plain files/directories directly there, or some other way?

                  —This feature is also exclusive to the LiveUSB, right?

                  Thanks yet again sir.

                  PS: you may want to edit the link to the post; while it does work, it seems “incorrectly” posted…

                  #76093
                  Anonymous

                    Yes, xtra.tgz is is only consulted during antiX live boot.

                    how should I…

                    Example:
                    First, populate a textfile with files to be added into the tgz file.
                    ( You might, instead, choose to use a text editor to create & maintain the file )

                     echo "/home/demo/.fluxbox/menu" >> /home/demo/xtralist.txt
                     echo "/home/demo/.icewm/menu"  >> /home/demo/xtralist.txt

                    Second, test successful creation of the xtra.tgz file:

                     cd / && sudo tar -czv --files-from home/demo/xrtalist.txt -f tmp/xtra.tgz && cd /tmp
                     
                     tar --list -f /tmp/xtra.tgz

                    sudo as part the test command because once you are confident the desired files are being added into the xtra.tgz, your tar command can directly place the file “-f live/boot-dev/antiX/xtra.tgz”

                    • This reply was modified 2 years ago by Brian Masinick. Reason: From skidoo
                    #76117
                    Member
                    ctcx

                      Just tested the thing… OUCH

                      I’m sure I followed your suggested steps. In the xtra.tgz I put some user config files (i.e., from $HOME directory) and some system ones (from /etc, /var/lib, and others).

                      Rebooted… desktop totally unable to load. It returns to slimski login screen, and any attempt to login results in the same.

                      So entered tty to try searching what happened, if I could… and found to my surprise that entire /home/<user> is empty! Except precisely for the files and directories included in xtra.tgz. WTH!? On the other hand, the system files and directories seemed to copy themselves correctly, without entire system been gone (hell, otherwise it wouldn’t boot).

                      I was trying to see if there was a hint in the initrd init script (there’s a copy at /live/init), but so far I still fail to find something meaningful…
                      But still trying.

                      By the way, the “noxtra” parameter does work as expected; though haven’t been able to test the stuff related to legacy BIOS menu and the F8 option…

                      Well, these were my findings at least until now.

                      #76121
                      Anonymous

                        I did not follow through (as you did) to test. It’s been a couple years since I last utilized the xtra.tgz mechanism. When I did use it, it worked as described//expected.
                        AFAIK, the copy_xtra() routine hasn’t been tweaked//changed across the past 5+ years.

                        re: “a hint in the initrd init script”
                        Here’s the copy_xtra() routine within the live init: copy_extra()

                        The following test seems to produce the desired result. What detail am I missing?

                        .

                        
                        echo "hello" >> /tmp/shoe.txt
                        tar -czv  /tmp/shoe.txt -f /tmp/xxxtra.tgz
                        ###     tested with, and without, the following step
                        ### mv /tmp/shoe.txt /tmp/oldshoe.txt
                        gunzip -c /tmp/xxxtra.tgz | tar x -C /
                        • This reply was modified 2 years ago by Brian Masinick. Reason: From skidoo
                        #76208
                        Member
                        ctcx

                          Have you tried tar-ing /home/demo stuff?
                          Because, yes, as already mentioned, non-home, system files (under /etc, /var, /tmp, etc) gave no problems. Only “home” stuff.

                          For the notes, I’m booting LiveUSB with no “persistence” options at all (no persistence, frugal, savestate, etc).

                          Er, at least on AntiX 21 the init script overall has indeed undergone several changes, and including the copy_xtra() function. As also mentioned, there’s a copy in /live/init when booting the live system. And the one in the Gitlab link is unfortunately outdated.

                          Well, at least for me it still keeps giving the same result specifically with “home” stuff. What am I missing? Or is it again just the USB stick in particular I’m using?

                          #76212
                          Anonymous

                            is it again just the USB stick in particular I’m using?

                            Naw, I’ve just led you down a bad path.
                            Back in 2014, the intended purpose xtra feature was to livepatch and test antiX liveboot ISOs during betatesting (inject select modified system files and immedietely test following reboot, rather than distribute a new ISO for each set of small incremental changes). As such, the mechanism apparently wasn’t intended to replace per-user files ( pathed under /home )

                            Have you tried tar-ing /home/demo stuff?

                            No, my experimentation involved only system files (pathed under /usr)
                            (a detail which I had forgotten when suggesting its use in 2019, and in this current, topic. Sigh, sorry.)

                            the init script overall has indeed undergone several changes, and including the copy_xtra() function

                            So (guessing) copy_xtra occurs too early in the init script ~~ later in the script, some other routine notices that /home/* exists and doesn’t attempt to (create and) repopulate it?

                            • This reply was modified 2 years ago by Brian Masinick. Reason: From skidoo
                            #76215
                            Member
                            ctcx

                              So (guessing) copy_xtra occurs too early in the init script ~~ later in the script, some other routine notices that /home/* exists and doesn’t attempt to (create and) repopulate it?

                              No. What I meant is that, in general, more stuff has been added.

                              And yes, for a moment I thought the same, that copy-xtra perhaps happened before all home-related mounting/copying stuff. But this is not the case. In this regard, the script is still similar.

                              When using the xtra tgz instead of the directory -as in my case-, the only thing copy_xtra virtually does is a simple unpacking.
                              So, despite happening after all the home-related stuff, it’d still not explain the issue. Perhaps actually in the home-related functions?
                              I’ll still try to search a bit more.

                              #76289
                              Anonymous

                                > later in the script

                                or within the /live/etc/init.d/live-init script

                                • This reply was modified 2 years ago by Brian Masinick. Reason: From skidoo
                                #77842
                                Member
                                ctcx

                                  Thanks once more, skidoo.

                                  I think I found where the issue is:
                                  http://gitlab.com/antiX-Linux/Xlated-initrd/-/blob/master/etc/init.d/live-init#L1043
                                  Actually I had since a while ago, but damn forgot to report here……

                                  Now I’d like to ask: considering this savestate functionality started up as an “experiment”, would it be worth to try fixing it?
                                  I’m not sure whether this is still considered “experimental”, but if made fully functional, I think it could serve as an interesting, additional “shorter” form of persistence.

                                  Thanks again.

                                Viewing 15 posts - 1 through 15 (of 19 total)
                                • You must be logged in to reply to this topic.