- This topic has 8 replies, 2 voices, and was last updated Jan 10-3:06 pm by olsztyn.
-
Posts
-
Anonymous
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 years, 4 months ago by Brian Masinick. Reason: Requested edit by skidoo, masinick edited
( 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.dbAcross 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.dbtip:
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 updatedbBy 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…
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” behaviora 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.
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 5143One further improvement would be right-alignment of the columnar data displayed by conky.
(achieving that may require use of a conky “template”)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 noneolsztyn
@ 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…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters
- You must be logged in to reply to this topic.
