All tests conducted on real hardware

TEST RIG
antiX version 13.2-Full-Stable 32-bit
Kernel 3.7.10-antix.7-486-smp
Hard disk partitions sda1=OS+APPS, sda2=HOME
File system format ext4 for each
All upgrades applied
Single user account


The antiX info re Snapshot refers to capturing (almost) the entire system to an installable ISO. The objective of theses tests is to explore whether it works when only system owned elements are collected.

BACKUP1
All items in ~ commented out in exclusion list
- home/* added to exclusion list

Unmodified antixsnapshot.conf used

ISO produced in isohybrid format

Bootable USB stick produced via dd

System booted from USB stick

Observation
The GRUB boot screen displays a message"This is a 32-bit computer. You cannot use 64-bit software on it."
Question
I recall this being produced on early 13 series but then susequently fixed. Was this one missed?

Observation
The values presented in the GRUB boot screen are the shipped defaults i.e. Language=English (US), Desktop ROX-IceWM, etc.
Question
As the ISO is a backup of a system with tailored settings is it possible for these to be presented as the default values in the GRUB screen? Of course these may not have been picked up if they are referenced in the excluded ~.

Observation
The boot up completes OK upto the point of log-in, which fails. This is expected as the user home area was excluded from the backup. Login as root displays the default Debian IceWM desktop.
Question
What is the command to issue at this point in order to install the backup? The shipped installation ISO runs antixsources.sh and minstall neither of which can I find in the backup.

the cli-installer is still available on an installed system. That's what I used with my antix-core snapshots.

dolphin_oracle wrote:the cli-installer is still available on an installed system.

Thanks, yes selecting the command line option in the GRUB screen boots to a CLI.

For non-technical users, restoring the snapshot from a GUI environment is likely to be a more comfortable experience during a stressful time. I will make an unresearched guess that most non-technical users will have conducted their original install of antiX via the GUI installer. So it is still an open query.
QUESTION
In the set up described in the opening post, after booting the snapshot and logging-in as root to a GUI environment, how does one start the snapshot installation procedure and carry it out within the GUI?



Notes on installing (restoring) snapshot in CLI mode from GRUB screen

OBSERVATION
An option to install to the MBR is offered. Doing this also overwrites the existing copy of the GRUB menu.lst. In turn this loses any customisations added to it.
SUGGESTION
It will be useful to capture a copy of the MBR during the creation of the snapshot. During the restoration of a snapshot, an option to restore the copied MBR might be included. In this way the original state is preserved and customisations retained.

OBSERVATION
During restoration of a snapshot, an option is offered to specify the hostname of the system. Unless the value entered precisely matches the value in the snapshot, networking might not work.
SUGGESTION
The assigned hostname is contained within the snapshot. The restoration procedure will be improved by automatically using this as the default value.

QUESTION
In the set up described in the opening post, after booting the snapshot and logging-in as root to a GUI environment, how does one start the snapshot installation procedure and carry it out within the GUI?

ANSWER:
You can't (at the moment). Only the cli-installer allows for installation of a snapshot.

you can however run the cli-installer in a terminal window.

Regarding the question of the mbr, just make a copy of it using dd before creating your snapshot so you can write it back to your disk. Slightly different to this particular subject, but, I did a remaster snapshot & wrote it to a pendrive as a live system for installation to multiple computers, so I would not want the original disk's mbr writing to them, so I think this is the right way to have this set up.

EDIT: Also, I would want different hostnames for different machines, so having that option presented, is also correct, I believe..

fatmac wrote:Regarding the question of the mbr, just make a copy of it using dd before creating your snapshot so you can write it back to your disk.

Thanks for the command. I am not looking to do this for myself. I am exploring from the perspective of a non-technical user creating a backup of their system using tools provided by antiX (ref posts 1 and 3). The approach divorces the backup of user owned files from root owned files. This thread is recording my observations and ideas of ways in which backing up the latter might be improved.

fatmac wrote: ..as a live system for installation to multiple computers, so I would not want the original disk's mbr writing to them...

This is an equally valid use to the one being explored. The suggestion is that the MBR of the original disk is available as an option rather than being the only possible choice.

fatmac wrote: ...I would want different hostnames for different machines, so having that option presented, is also correct, I believe...

The current restoration of a snaphot defaults to offering the same hostname (antiX1) as the shipped ISO installer. This is obviously OK when the machine is the only antiX system on the site. Like you, I also work on sites where there are multiple antiX systems, each with unique hostnames. These have to be specified manually, either when installing from the shipped ISO or (as in your case) from a customised installation snapshot.

When the snapshot is used as a backup, it is specific to one machine. In such a case a successful and working restoration requires the hostname contained within the backup is used. Again this is intended to be an option rather than exluding all other possibilities.

When used as a deployment tool as you describe, the hostname will need to manually entered to ensure it is different on each deployed system. The suggestion is that snapshot restoration defaults to offering the hostname that is included in the snapshot. This will leave you in the same position i.e. editing the field to enter a different one manually.

OK, I see what you are aiming at.

In simple terms you want the original machines settings, including the mbr, to be diplayed as the defaults for restoration, without changing anything else in the program, so that a non techie can just hit the enter/return key all the way through to restore the system snapshot to their machine.

anticapitalista wrote:

SamK wrote: QUESTION
In the set up described in the opening post, after booting the snapshot and logging-in as root to a GUI environment, how does one start the snapshot installation procedure and carry it out within the GUI?

ANSWER:
You can't (at the moment). Only the cli-installer allows for installation of a snapshot.

OK. For the moment, I'll park looking at the GUI mode and continue with the CLI mode.

OBSERVATION
Having excluded /home/*, a snaphot ISO of antiX-Full can easily exceed 700MB. This is exacerbated if it is produced as an isohybrid which automatically increases the size of the resulting ISO. For similar reasons that the shipped ISO is kept under 700MB, it is probably beneficial to try and handle the backup ISO so it can be used by aged hardware that does not natively support booting from USB.

IDEA
Using third party software
At creation

• Produce the snapshot ISO
• Produce a PLOP (or similar) boot manager ISO/IMG

At restoration

• Create a boot loader CD/floppy from the PLOP ISO/IMG
• Create a bootable USB device from the snapshot ISO
• Boot the system using both

Pros

• Single method works on ancient and modern kit
• Requires no change to current snapshot creation routine
• Kit that natively supports USB booting may disregard use of PLOP at restore time
• Trivial amount of storage space used by PLOP

Cons

• Extra stage is needed to accommodate old kit
• PLOP is not part of antiX/Debian

IDEA
Using shipped software
At creation

• Produce a snapshot ISO
• Produce a boot ISO of minimal size from the source system. It will contain only the files required to boot the system, access an external USB storage device, and begin the restoration process

At restoration

• Old kit
  • Burn the minimal ISO to CD and use to boot the system
  • Access the USB device containing snapshot
  • Restore the backup from the snapshot on USB
• Modern Kit
  • Boot using the USB device and begin the restoration

Pros

• Single method works on ancient and modern kit
• Kit that natively supports USB booting may disregard use of minimal boot ISO at restore time
• Uses software that is part of antiX/Debian
• Potential to implement via use of two different exclusion lists, one for each ISO

Cons

• Extra stage is needed to accommodate old kit
• Requires snapshot creation routine to be run once for each ISO
• Uses more storage space and will take longer to create than PLOP alternative

SamK, the existing antiX Live boot system is extremely versatile. If the compressed filesystem to too large to fit on a cd then just create a bootable antiX cd without the /antiX/linuxfs file and put the /antiX/linuxfs file on a usb stick. When you boot from that cd with the usb stick plugged in, the system will automatically use the linuxfs file that is on the usb stick with no changes made to the boot parameters. This is because by default the LiveUSB/CD will automatically look for the linuxfs file on all cd/dvd devices and on all removable/usb devices.

If you want to use a stock antiX LiveCD to boot using a linuxfs file that is on a usb stick then you will need to add a boot parameter to ensure the linuxfs file on the usb stick is always used. Otherwise we will use the linuxfs file from whichever cd/dvd or usb device first shows up and has a /antiX/linuxfs file. The easiest boot parameter to use in this case is:This will force the live system to only look at usb devices for the linuxfs file. We will no longer look at cd/dvd devices.

Likewise if you want to force it to get the linuxfs from a cd or dvd then you could use:.
If you want to force it to get the linuxfs file from an internal hard drive partition then use: These can be combined with commas. For example, the default configuration is: so by default we only look for the linuxfs file on cd/dvd devices and usb devices.

While the from bootcode is the simplest way to specify where to find the linuxfs file, it is not the only way. You can use blab to specify the disk label of the partition that holds the linuxfs file you want to use; or you can use buuid to specify the UUID of that partition, or even use bdev to specify the device node of the partition. You are also allowed to mix and match these specifications with the from boot code.

OBSERVATION
On a system that has been in use for a while (or one that is being migrated to antiX) it is probable that the total size of files owned by a user will be many times larger than the size of those owned by root. Storing the backup of both types of file in a single location is likely to be a common practice. In this case the storage capacity of the backup device becomes a consideration.

IDEA
Use external hard disk. Both external USB disks and redundant internal disks exist in large numbers. The capacity of such disks is often in excess of flash drives currently available. A redundant internal disk can be reused as an external USB disk via an adaptor as similar to the one in the attached file Generic Adaptor.
Pros

• Single method works on ancient and modern kit
• Can use either a new or recycled IDE or SATA disk
• Reuse of otherwise redundant kit meshes with a primary goal of antiX
• A wide range of disk management and maintenance tools are provided within antiX
• Accommodates large size backups (potentially of different types to minimize time required)
• Enables a complete set of backup files to be kept in a physically separate location

Cons

• Reliability of reycled kit

Alternatives

• A high capacity flash drive may be used if desired
• Trivial modification to use a NAS or other LAN share

OBSERVATION
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:

• Producing separate bootable media will significantly increase the time required
• The bootable media cannot be used for anything else (e.g. small isohybrid uses entire large USB storage device)
• For a non technical user, creating a bootable USB device from an isohybrid via dd, is complicated, dangerous, and unfriendly

IDEA
Use an external hard disk that has been made bootable. Place the backup ISO on the disk. Ensure the bootloader directly boots the (unextracted) ISO file. In the booted antiX environment, conduct the restoration.
Pros

• Reduces time required because bootable storage is created once only
• Works with both standard and isohybrid backup ISO files
• Because the unextracted ISO archive is booted directly, unused disk space remains avaialable
• Unused disk space may optionally be used for a (separate and different type of) backup of user owned files
• For a non technical user, copying a single file (ISO) is uncomplicated, familiar and friendly
• Ease of restoration - simply plug-in the external disk and power up to boot the system

Cons

• Requires installation of suitable bootloader on external disk

TESTED
An external hard disk was formatted as ext4 and GRUB2 bootloader installed. A boot menu was created pointing to an unextracted backup ISO (isohybrid format and standard format tested). A restoration of root owned files was successfully conducted from both the CLI and GUI. The resulting system booted and worked as expected.

OBSERVATION
During the running of cli-installer a question is asked
"Install GRUB on MBR (Y/n)"
After answering"n" (to decline) GRUB is still installed.

SUGGESTION
cli-installer to contain an option whereby GRUB is not installed.
Alternatively, after GRUB has been reinstalled, offer an option to copy (again) the GRUB configuration file (menu.lst) from the backup to overwrite the virgin one.
Pros

• Tailored GRUB entries (video driver settings etc) are preserved rather than overwritten and lost

Cons

• An additional option is presented to the user conducting the restore

thread title reads"snapshot"

but you're talking about installer?