antiX live-remaster: collected usage tips, observations, options…

Forum Forums antiX-development Documentation antiX live-remaster: collected usage tips, observations, options…

  • This topic has 5 replies, 1 voice, and was last updated Mar 29-12:20 pm by skidoo.
Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #2890

    note: this will be a moderated topic.
    Posts to correct misinformation or to provide additional info are welcome.
    Any questions / help requests posted to this topic will be moved or deleted.



    tip (or, avoiding a potential “gotcha”):

    Probably intended to “avoid bloat” within the remastered linuxfs file, the provided (default) “excludes list”
    contains a line
    var/cache/man/* (yes, without a leading slash character)
    which instructs the live-remaster utility to not carryover the content of manpages cache.

    Unless you are creating a remastered system intended for use by “good ol’ Aunt Nellie, who just wants to surf da net”,
    I recommend outcommenting that line (to do so, add a # character to beginning of line, then save edited file).

    Otherwise, until/unless you perform sudo mandb -c while running the remastered system…
    …attempting to lookup manpages via man -k somecommand or apropos somecommand
    will result in “whatevercommand: nothing appropriate
    after headscratching (or when your supported users report “manpages is busted”),
    regenerating the manpages cache from within the remastered system’s live-session results in a “bloated” persistence savefile.


    ( the following “tip” is relevant to performing both live-remaster AND persist-save operations )

    Each time the locate (aka mlocate) command is invoked,
    the command consults the content of /var/lib/mlocate/mlocate.db

    Across various linux distributions (liveboot and installed), how, and when, the mlocate.db “gets automagically updated” differs.
    Many systems perform a check during each boot, and silently launch a background process which (creates, if missing or) updates the mlocate datastore.

    Toward dodging user {{{er, distro reviewer}}} perception that a liveboot system seems “sluggish”
    (due to CPU load of backgrounded updatedb operation on low-spec machines, or slow i/o writing to persistence media)
    an up-to-date updatedb datastore is provided within the antiX iso.

    On demand, we can sudo updatedb to manually freshen the datastore
    During extended liveboot sessions, I’ve often found it desirable/necessary to repeatedly do so.
    If performed often, the update operation completes quickly.
    Conversely, if an updatedb operation (automated, or manual) has not been performed recently and many file changes have accumulated, completion of an update operation may take several minutes.

    Your manual intervention sudo updatedb (or not) prior to performing live-remaster or persist-save operations
    determines whether the resulting savefile, or remaster, will contain a fully up-to-date copy of /var/lib/mlocate/mlocate.db

    1) Install the GNU ‘time’ utility (sudo apt-get install time)
    It enables you to “wrap” a commandstring
    (commandstring, meaning a single command, with or without +optional args… or command1 && command2 …or command1;command2 -arg1|foo>>outfile)
    and does not return the command prompt until the wrapped commandstring has completed.

    2) Form a habit of using time to wrap your calls to updatedb:
    sudo time updatedb

    By doing so, you’ll avoid the pitfall of initiating a save/remaster while the running-in-background updatedb rebuild is still underway (and the datastore is not yet complete)


    “common sense”, execpt we {me, raises hand} may become complacent, or might forget if rushed to perform a shutdown…


    In the context of performing backup (rsync, luckyBackup, etc.)
    or performing a manual (on-demand, dynamic root persistence) persist-save operation
    or shutdown of a persistent save-at-shutdown livesession (any, not specific to antiX) system:

    neglecting to “Close/exit” individual programs prior to (backup, or save, or) exiting a desktop session
    can result in lost or incomplete program data.

    — Many text editors do not perform timed “autosave”.
    (and backup is blind to any in-memory changes to a draft/WIP document open in editor at time of backup)

    — Firefox (and other web browsers which maintain a set of “Session” files), after you’ve closed its window(s)
    still needs several (YMMV) seconds to finish on-disk housekeeping.
    Performing persist-save (or shutdown abruptly) with ff running, at next launch the ff SessionManager may report “Last Session Crashed”. Even if you are able to “Restore last session” or “restore previous session”, you can expect to discover that any bookmarks added during that prior session have been lost.

    — Many programs (see “a related post”, below) suffer non-obvious consequences if they are abruptly terminated, or are “backed up” while running. Some programs do not write to disk any recently changed preferences/settings until they are File}}Exit closed. In any context, not just in persistent livesession… clicking the all-too-convenient “X icon in window titlebar” incurs the risk of lost program data.

    a related post:
    understand (and workaround) the geany editor “save session” behavior


    a tip applicable to both persistence, and remastering:

    If you customize the “excludes” lists ( they reside in /usr/local/share/excludes directory ), place backup copies of the edited files elsewhere, for safekeeping. This is necessary because the files residing within that directory may be overwritten with fresh copies each time an upgraded version of the “antix-libs” package is installed.


    The recent topic at MX forum Mount /tmp as tmpfs
    reminded me to mention a few additional “collected usage tips, observations, options” points here.

    chattr +i (set immutable) is impossible during livesession because one or several of the aufs|overlay layers are tmpfs mounts

    A while back I tested “Does use of atime mount option make the system noticeable slower?”
    I had expected that, during livesession + toram + root_only persistence, it would not.
    To my surprise, yes, using the atime option did cause the system to seem noticeably slower.
    FWIW, the RAM on that system was only (!) 667MHz ~~ or 800MHz DDR2. I haven’t retested using faster RAM.

    In the course of testing the above, I also discovered (realized) that the persist-save considers only mtime.
    Hmm, mtime ??? ctime ~~ said differently, persist-save doesn’t care about files bearing a changed atime.



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