skidoo wrote:thread title reads"snapshot"

but you're talking about installer?

antiX-Snapshot produces an ISO file. The contents of the ISO are installed via the cli-installer. Refer to the earlier posts in the topic to get the background.

ouch, sounds patronizing.

So, you're"posting your observations"... and???
If there's a problem to solve, let's solve it.
If the observations simply amount to"a solution looking for a problem", yep, I also find my thoughts following that path.

In my prior post, perhaps I should have written"let's address backup/snapshot considerations first, and defer install-time considerations"?

A backup ISO will usually be employed to create bootable external media in order to conduct a restoration.
Doing this as part of the backup creation is optional. A user may be tempted to defer doing it until a restore is to be done because:

Per my usage, the ISO is nearly always immediately fed to antix2usb in order to merge the content of the persistence savefile into the squashfs.
(not"in order to conduct a restoration")
Occasionally, I might generate an ISO just to gauge the size delta of the resultant ISO after adding/removing a batch of packages.
So, to me, the installer (cli or gui) represents a separate, unrelated, application.
Further, although others may choose to do so, I would not utilize an ISO store my"backup (with intent to restore) datasets".

antiX-Snapshot produces an ISO file. The contents of the ISO are installed via the cli-installer

???
By default, doesn't cli-installer install contents of the running system's rootfs, not contents of an ISO?

Take a step back:
To me, antix"snapshot" seems like a misnomer. The name suggests it's a homebrew, distro-specific, LuckyBackup -ish utility.
Although it's nearly perfect (in its flexibility), its default excludes list is geared toward remastering
(which is contrary to the goal"creating a backup" which faithfully preserves all user content, machine-id, etc.)

I've modded the"snapshot" script to achieve point-in-time backups and to periodically freshen the squashfs on my liveUSB pendrives.
Sans gui, linear workflow:
__ run a chained cleanup script, and prompt to run bleachbit --} continue/exit
__ perform rsync to remote work_dir (minus sourced excludes list paths) --} continue/exit
__ 'mksquashfs -comp xz' of remote work_dir --} continue/exit
__ create genisoimage --} continue/exit
__ apply isohybrid --} exit

From your initial two"observation" posts, it seemed our thoughts were following the same track.
Although I had followed the antix2usb (vs dd) route...
...the initial runs were fraught with confusion/frustration/disappointment, even though I had RTFM, and the"other" (mepis, online) FM.
At this point, I've become fairly convinced that"a single, confusingly flexible, script" isn't an ideal approach.
User confusion would be reduced by renaming the existing"snapshot" script to"remastershot" or"snapremaster"
and by introducing a separate, separately documented(!)"antixbackup" script ~~
one which utilizes rsync, vs chroot...copyemptydirs...copyselectdirs...excludeselectitems
and for which the docs encourage:
-- choose remote rsync target
-- preserve resultant work_dir to speedup future backups

skidoo wrote:ouch, sounds patronizing.

It is one of the problems of using a public forum. Misinterpreting the meaning of a brief message is easily done.

skidoo wrote:So, you're"posting your observations"... and???
If there's a problem to solve, let's solve it.
If the observations simply amount to"a solution looking for a problem", yep, I also find my thoughts following that path.

Usually I do this type of thing in private and bring back the outcome. This time, and for no particular reason, I thought to publically record the work in progress.

Off Topic Start
Incidentally, to my eyes, the above quote is an example that might easily be taken as offensive.
Off Topic End

skidoo wrote:Per my usage, the ISO is nearly always immediately fed to antix2usb in order to merge the content of the persistence savefile into the squashfs.
(not"in order to conduct a restoration")

There has been some speculation in the forum that antiX might most often be used in a conventional hard disk installation (subject to fallible recall). The present line of investigation looks at the potential of using snapshot as a backup mechanism of files owned by root in those circumstances.

skidoo wrote:...I would not utilize an ISO store my"backup (with intent to restore) datasets".

I agree. The earlier posts contain various references to separating root owned files from user owned files in order to treat them differently.

skidoo wrote:???
By default, doesn't cli-installer install contents of the running system's rootfs, not contents of an ISO?

antiX-Snaphot produces a bootable ISO. The contents of the ISO are governed by the exclusion list. In the investigation scenario, all user owned files are excluded. Booting the system from such an ISO, the running antiX is the one that was backed up. Running the installer thereby installs the backup.

skidoo wrote:So, to me, the installer (cli or gui) represents a separate, unrelated, application.

When used in the above scenario it is integral and essential.

skidoo wrote:I've modded the"snapshot" script to achieve point-in-time backups and to periodically freshen the squashfs on my liveUSB pendrives.

The investigation scenario lends itself to the creation of multiple"point-in-time backups" if desired, thereby allowing a choice of historical backup dates. Potentially these might all be accessed from a single suitable storage device. Additionally, the backup may be restored from various media e.g. CD/DVD, USB hard disk, USB sticks/pendrives.

OBSERVATION
The antixsnapshot (+ gui) script contains a fallback configuration and a pointer to a primary configuration. The latter contains a pointer to an exclusions file.

IDEA
Use alternative versions of the files tailored to the role of backup. The changes are principally alternative configuration values.
Pros

• Enables backup and snapshot to be identifed, configured, and run as discrete items
• Executable scripts are functionally similar. (Note: This might present an opportunity to have a single script perfoming both tasks but employing a different configuration for each)

Cons

• Trivial amount of additional disk space required circa 27k

SUGGESTION
antixsnapshot (+ gui) incorporate a means to specify a configuration file as command parameter, $1

TESTED

• Revised and renamed version of each file
• Backup created
• Backup restored

RESULT
Success. All work as expected (ref items to polish identified in previous posts)

OBSERVATION
After restoring the backup, but before rebooting, grub.lst (grub.lst-wanted) was manually copied from the backup to overwrite the new version (grub.lst-unwanted-1) created during the running of cli-installer. On first reboot grub.lst-wanted is used as expected. On second and subsequent reboot grub.lst-wanted is overwritten with a further version grub.lst-unwanted-2, thereby loosing the customisation contained in the desired copy.

QUESTIONS

1. Are grub.lst-unwanted-1&2 created as a result of running the installer i.e. would they still be created if GRUB was not reinstalled during the restore of the backup?
2. What is the trigger used to overwrite grub.lst before the second bootup?
3. Does grub.lst-unwanted-2 exist as a file before it overwrites grub.lst-wanted i.e. does it exist before the first bootup? If yes, where?

If you watch close on a standard install, the first boot up of the newly installed system will have a very simple, usually 1 item grub menu. After the install, there will be the standard"update-grub" menu.

There are hooks in rc.local on the live side that do certain things. In the past I've had an issue installing from a liveusb where the rc.local that gets installed is still the live version. You might also want to check fstab and see if it is correct as well.

dolphin_oracle wrote:There are hooks in rc.local on the live side...

Of course there are. As soon as I read that it sparked my memory to work again. I have been down a similar track about 18 months ago (custom builds on USB of antiX-12-Full), and worked with those in the same file. Don't know how or why I forgot, but your memory jogger helped a lot.

Thanks.