Live Remastering

[top]

The primary purpose of live remastering is to make it as safe, easy, and convenient as possible for users to make their own customized version of antiX. The idea is that you use a LiveUSB or a LiveHD (a frugal install to a hard drive partition) as the development and testing environment. Add or subtract packages and then when you are ready to remaster, use use a simple remaster script or GUI to do the remaster and then reboot. If something goes horribly wrong, simply reboot again with the rollback option and you will boot into the previous environment.

If you are using a LiveUSB then the LiveUSB is your target system. You can use it to install your customized version of antiX on other systems. If you are using a LiveHD then you will need to create a LiveUSB or a LiveCD from the LiveHD in order to install elsewhere.

System Requirements

[top]

There are three simple and straightforward system requirements that are needed to perform live remastering:

  • The boot device must be writable

  • The boot device must have enough free space to create a new linuxfs file

  • The development system must have been created using a "frugal install", not a fromiso install

In other words, the development system must be booted using a linuxfs file that is on a writable device that has enough free space to create a new linuxfs file.

How it Works

[top]

In order to perform a live remaster, a new linuxfs file is created in the same directory as the existing linuxfs file with the ".new" extension added. On the next boot, before the linuxfs file is mounted, the following commands are (in essence) performed in the directory containing the linuxfs file:

# mv linuxfs linuxfs.old
# mv linuxfs.new linuxfs

If the new linuxfs file makes the system unbootable then the rollback boot code should be used. It can either be added manually by the user or their can be another Grub menu entry that contains the rollback option. In this case the following two commands are (in essence) performed in the directory containing the linuxfs file:

# mv linuxfs linuxfs.bad
# mv linuxfs.old linuxfs

This reverse the previous actions except the file that was originally called linuxfs.new is now called linuxfs.bad. If you use the sqname or sqext options to change the name of the linuxfs file then these names are used instead of linuxfs. For example if you boot with sqext=e16 then we look for a file called linuxfs.e16.new etc.

WTF?

Don’t worry, antiX has automated this process for you! All you have to do is click a few buttons.

antiX Control Centre-→Live-→Remaster

You will be asked a few simple questions about how you want to save the remaster and then the application will do its work. Note that the process is quite slow and CPU intensive. Once the new linuxfs file has been created, you will be prompted to set up a new rootfs file. This is recommended.

Remastering Plus Persistence

[top]

A persistent home or a persistent can useful if you are doing remastering. A persistent home is a handy place to hold your development environment if you don’t want that environment to end up in your remaster. A persistent root is a handy way to save changes between reboots without having to go to the bother of doing a full remaster. In a mountain climbing analogy, you can think of the persistent root as a piton (or a spring loaded camming device) while remastering is setting up a new campsite or bivouac.

Live Remaster Boot Options

[top]

There are only two live remaster boot option because live remastering is almost entirely handled by a script or GUI. The only two option are to prevent live remastering and to rollback live remastering in case something goes horribly wrong.

noremaster

don’t remaster even when a linuxfs.new file is found

rollback

return to previous version after a failed remaster