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

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

  • This topic has 8 replies, 2 voices, and was last updated Jan 10-3:06 pm by olsztyn.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #2890
    Member
    skidooskidoo

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

    Probably intended to “avoid bloat” within the remastered linuxfs file, the provided (default) “excludes list”
    /usr/local/share/excludes/live-remaster-exclude.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
    and
    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.

    • This topic was modified 2 months, 1 week ago by Brian Masinick. Reason: Requested edit by skidoo, masinick edited

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #2904
    Member
    skidooskidoo

    ( 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

    tip:
    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)

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #2906
    Member
    skidooskidoo

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

    tip:

    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

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #13227
    Member
    skidooskidoo

    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.

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #14617
    Member
    skidooskidoo

    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.

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #19851
    Member
    skidooskidoo

    .

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #48063
    Member
    skidooskidoo

    In a recent topic, we discussed keeping an eye on “when (sync) and how much”
    data has cumulatively been written to the persistence device during a liveboot session.
    To monitor that detail, I place the following line into ~/.conkyrc

    ${color6}${execi 5 iostat -p | grep -v loop | cut -c 1-8,51-80 | tail -n +5}

    it produces output similar to this commandline

    
    $ iostat -p | grep -v loop | cut -c 1-8,51-80 | tail -n +5
    
    Device:   kB_read    kB_wrtn
    sda          4207          0
    sda1         3635          0
    sdb       1773573        119
    sdb1      1773033        119
    sdc        826602       5143
    sdc1       826074       5143

    One further improvement would be right-alignment of the columnar data displayed by conky.
    (achieving that may require use of a conky “template”)

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #49546
    Member
    skidooskidoo

    https://gitlab.com/skidoo/odds-n-ends/-/raw/master/pchanges_dryrun.sh

    #!/bin/bash
    ###     pchanges_dryrun.sh
    ### Utility script for antiX livesession "dynamic root persistence" users.
    ### Generates a textfile containing a list of changed files slated
    ### for addition into to the roofs during a persist-save operation.
    ###
    ### Useful for honing  /usr/local/share/excludes/persist-save-exclude.list
    ###
    ### When launched with commandline option -d
    ### the script will also output to terminal the verbose stat/details of
    ### each file, along with a tally
    ### total number of files, and total BYTES slated for sending to rootfs
    ###
    ### NOTE: The script attempts to call LEAFPAD editor to display the output file.
    ###       Edit the script to change to your preferred editor, or none

    ___________________________________________
    When requesting help, pasting the output from inxi -Fzr command will provide important relevant details:
    antiX version//edition ~~ stable vs testing repos ~~ live vs installed vs virtualbox ~~ hardware specs

    #49558
    Member
    Avatarolsztyn

    @ skidoo:
    I want to thank you for such elaborate analysis and tips for remaster process. I am one of those users for whom remaster is one of the most important tools of antiX, so I have read this with great interest, although it will take me some time to understand all details, as I am coming from user perspective rather than a developer perspective.
    So my understanding is that much of this analysis seems to contain a guidance to how remaster process can be improved but also a part of it reminds the user to follow due diligence principle and close all running programs before start of remaster process.
    So I am looking forward further perfection of the remaster process (which is already the best out there)…
    Thanks and Regards…

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