The sections that follow detail aspects of the release.
Note that throughout this document where you see
i686 listed, read x86_64 for the
64-bit release.
Following are the minimum system requirements for running the unexicon distribution:
| CPU Arch: | i686 or x86_64 |
| CPU Speed: | >1GHz |
| Memory: | ≥1G |
| Disk Drive: | ≥32G |
The sections that follow details the steps necessary for preparing boot media of various types.
Unexicon distribution ISOs are multi-purpose and can be used directly to prepare a USB flash drive, SSD, HDD, CD or DVD. Because the distribution is compact, and runs unconstrained in 32G of disk, we highly recommend the use of medium sized, high-speed USB 2.0 flash drives or SATA 3.0 SSDs. See the unexicon hardware page for a reference hardware design.
Unexicon runs compact on a notebook (used for management or development) from an 8G USB flash drive. For a full blown workstation, a 16G to 32G USB flash drive is preferred.
sudo wodim dev=/dev/sr0 image.soimage.iso is the name of the
downloaded ISO image,
and /dev/sr0 is the device name assigned to
your CD/DVD burner: try lsblk(1) to discover it.
sudo dd if=image.iso of=/dev/sdx
sudo sync
sudo eject /dev/sdx
where image.iso is the name of the
downloaded ISO image,
and /dev/sdx
is the device name assigned to the USB flash drive: try
lsblk(1) to discover it. Take care with the device
name or you will overwrite the wrong drive: maybe your hard drive!
All existing data on the drive is lost.
ESC when prompted to get a boot
menu and select "Unexicon i686 rescue".
The system boots and copy the live image to RAM. At the login prompt,
the live medium should be removed. Login as unexicon.
(Any live distro can be used for this purpose. I usually keep a current
copy of RIPLinuX
handy.)
sudo dd if=image.iso of=/dev/sdx
sudo sync
where image.iso
is the downloaded ISO image,
and /dev/sdx
is the device name assigned to the SSD/HDD: try
lsblk(1) to discover it. Take care with the device
name or you will overwrite the wrong drive. All existing data on the
drive is lost.ESC key when prompted to
enter the boot menu.
Select "Unexicon i686 install" from the
boot menu and the system is installed and booted.Unlike many Linux distributions, installation menus and selections
are not required: the live medium installs itself automatically (upon
boot selection) to the drive on which it booted. This means that you
must dedicate the drive to unexicon.
Selecting "Unexicon i686 install" from
the boot menu when the live image is booted installs the system. See
Boot Menu Selections later in this document for a
description of boot menu selections.
Unexicon currently uses a GRUB 2.00 boot loader with a custom unexicon boot script. The sections that follow detail the booting process and options.
To boot the system, insert the prepared medium into the computer. This may be the USB/SSD/HDD or CD/DVD as described above. Select the boot order from the computer's BIOS setup and select the installation medium as the boot medium. If your machine is too old to boot a USB, there are some tricks for using a special purpose CD that chain boots the USB. Once BIOS setup is complete, boot the system.
To control the boot process of servers without display or keyboard,
the boot script for unexicon detects the presence of
USB0 and COM1 serial ports.
A USB0 serial port is present when a USB serial cable is
plugged into the computer. See the unexicon hardware page
for a suitable USB to USB null modem cable. When detected, the boot
script outputs boot messages and menus to the port, as well as accepting
input from the port. Serial port connections must be set for
38400 baud, 8 data bits, 1 stop bit and no parity (38400 N 8). When
detecting the USB0 serial port, you will see the
message:
Testing for USB0 serial port... ...yes.
displayed on the local or IPMI console. An ignorable error is
displayed instead of "...yes." when detection fails.
A COM1 serial port usually present as server
motherboards still ship with 16550A RS-232c DB-9 COM1 ports.
When detected, the boot script outputs boot messages and menus to the
port, as well as accepting input from the port. Serial port connections
must be set for 38400 baud, 8 data bits, 1 stop bit and no parity (38400
N 8). When detecting the COM1 serial port, you will see
the message:
Testing for COM1 serial port... ...yes.
displayed on the local or IPMI console (and USB0 serial port, if
active). An ignorable error is displayed instead of
"...yes." when detection fails.
Boot messages and menus are output to all active serial ports as well as the local or IPMI console. Input is accepted from all serial ports as well as the local or IPMI console.
When active serial ports are detected and
"Set auto console" is in effect (see Advanced Boot Settings), the boot script instructs
the kernel to use the serial port as console. The USB0
port is used in preference to the COM1 port when both are
present.
When the system boots you will see a GRUB boot message and then the following message will appear while the boot program is initializing:
Hold SHIFT key for non-graphical menu.
Holding down the SHIFT key at or before this point and
any time before the boot loader initializes will result in the display
of a non-graphical menu (on the local or IPMI console). When the
SHIFT key is held through the boot process, or when the
previous boot failed, the boot menu will be presented. (Note, the
SHIFT key being held down can only be detected reliably
from a locally attached keyboard. IPMI and serial consoles will not
necessarily signal the SHIFT key being held down at
all.)
The reason for the SHIFT key procedure is that
the GRUB boot loader does not support all known graphical terminals and
can generate errors and fail to load when it attempts to configure
graphical terminals that it does not support. Holding the
SHIFT key on the local console allows the operator to
bypass graphical terminal configuration and boot an otherwise unbootable
system.
The boot script will next detect serial ports as described in the
previous section. After detecting serial ports, if the
SHIFT key was not held down on the local console and the
previous boot succeeded you will see the prompt (on the local or IPMI
console, and any configured serial ports):
Press ESC for Unexicon Boot Menu...
and a 659 Hz tone (low beep) will be generated once on the PC speaker
for 120 milliseconds, and the boot program will wait for 3
seconds for an ESC key. If the ESC key
is not pressed before the 3 seconds expires, the boot program
will display the message:
Press ESC for Unexicon Boot Menu... 3 2 1...booting.
and a 880 Hz tone (high beep) will be generated once on the PC
speaker for 120 milliseconds, and the system will boot into the last
default selection from the boot menu. When the ESC key is
pressed before the 3 second timer expires, the boot program
will display the message:
Press ESC for Unexicon Boot Menu... 3 2 1...menu.
and the boot menu will be presented.
When a menu is presented, you will be given a set of selections. The exact set will depend upon whether the boot medium has been prepared or whether an installation has been performed on the boot medium. The following options may be presented:
The following selection is only presented when the system has not yet been installed (or restored from being overwritten with a new ISO image):
Unexicon i686 installESC is pressed when
prompted.Once the system has been fully installed, the following selections are presented instead:
Unexicon i686 installedcurrent installed
system. This boot selection is saved and used as the default boot
selection for future reboots. This selection is also the initial
default after installation. This boot selection is saved as a future
default.Unexicon recovery...If the system is only partially installed (e.g. installed to a small 4G USB flash drive), the following selection is presented instead:
Unexicon i686 persistent/var/local.The following selections are always presented:
Unexicon i686 rescueUnexicon live...Unexicon advanced settings...This submenu provides selections for booting the live system from the live image in the first partitions of the drive or CD. Except where noted, the selections in this menu for a writable boot medium are saved and applied as the default for subsequent boots.
The following selections are always presented:
Unexicon i686 copytoram/var/local. The operator may,
however, mount /var/local after login. The objective is to
not touch a drive that may require recovery. On reboot, all changes
made to the system are lost unless the operator mounts
/var/local.Unexicon i686 non-persistent/var/local. Because cached download packages are stored
there, packages may be installed rapidly. On reboot, all changes made
to the system are lost (with the exception of cached packages and
unexicon applications that store their data in the data
volume.)The following selections are only present when the system is installed:
Unexicon i686 persistent/var/local.Memory test (memtest86+)Unexicon provides advanced carrier software upgrade with
checkpoint and rollback of the system image. The boot options in the
recovery boot selection submenu provides
fine-grained control over the process.
None of the selections made in this submenu are saved: whatever default
was present prior to the selection will be used as a default on the next
reboot.
The selections are as
follows:
The following three selections are always presented:
Unexicon i686 currentcurrent installed
system, regardless of whether a checkpoint is set or not. It has the
same effect as selecting the installed option from
the main boot menu, except this boot selection is not saved.Unexicon i686 checkpointcurrent system, discarding any previous checkpoint,
and boots into the current system. This has the
effect of committing the changes to the system since the last
checkpoint reflected in the current system, or
establishing a new checkpoint after a rollback.The following two selections are only be presented when a previous
checkpoint is in effect:
Unexicon i686 previouscheckpoint. The current system is not affected, but
any changes made to the booted system are included in a future
rollback.Unexicon i686 rollbackcheckpoint and
boot the rolled back system. It has the effect of overwriting
current with previous and then
booting current.The following selection is a shortcut for booting into the "fallback" initial RAM disk of an upgraded system when the "default" initial RAM disk proves unbootable:
Unexicon i686 fallbackcurrent installed
system, using the "fallback" initial RAM disk, regardless of whether a
checkpoint is set or not. Its sole purpose is to boot the system to
repair the "default" initial RAM disk.See Online Upgrades in this document for information on using the recovery boot options.
When the operator selects any of the entries in this submenu, the settings resulting from the action is displayed for 3 seconds and the operator is returned to the main menu. The settings in this submenu affect the boot parameters for any boot of the system and, in some cases, are saved for subsequent boots. The possible selections are as follows:
The following three selections affect the target into which the system will boot:
ssh login only.The following three selections affect the use of a serial console by the booted kernel:
USB0 port is detected, the kernel will be set to boot with
ttyUSB0 as a serial console; otherwise, if an active
COM1 port is detected, the kernel will be set to boot with
COM1 as a serial console; otherwise, the kernel will be set
to boot with the local or IPMI console.ttyS0 as a serial console, regardless of whether an active
COM1 port is detected or not. The setting is stored and
used for all subsequent boots.COM1 console.ttyUSB0 as a serial console, regardless of whether an
active USB0 port is detected or not. The setting is stored
and used for all subsequent boots.USB0 console.The sections that follow detail the partitioning of drives, logical volume management, and custom partitioning.
The USB/SSD is automatically partitioned by the bootstrap loader when
the USB/SSD is prepared by selecting the
Unexicon i686 install boot selection in
the main boot menu. The boot medium is partitioned in such way that a
new live ISO image can be overwritten to the medium without destroying
an installed system or persistent data.
The bootstrap loader detects when the boot medium is a CD, DVD or
other read-only media and will not offer to partition the drive in the
boot menu. Otherwise, when
Unexicon i686 install is selected from the
boot menu, the makeusb cheat code is added to the
boot to signal the bootstrap loader to prepare the USB/SSD by creating
any necessary partitions. If the drive contains any partitions other
than the 1st primary partition, the bootstrap program will not touch the
drive at all. This means that a drive in the system can be custom
partitioned makeusb will not alter its
configuration.
To prepare a USB/SSD boot medium, the bootstrap loader establishes 3 primary partitions as follows:
iso9660 partition.ext4 partition with a filesystem
label of unxcowspace. If a ext4
filesystem already exists at cylinder 512, the bootstrap program will
not touch it. If the drive has less than 1024 cylinders, the remaining
cylinders from cylinder 512 are allocated to the second partition.LVM2 partition.The 4th primary partition or 5th, 6th, 7th extended partitions are available for use for custom installations.
The 3rd primary partition on the USB/SSD extends from cylinder 1024
through to the end of the disk and is configured as an
LVM2 partition. If a volume group named
Unexicon already exists (likely at cylinder 1024),
then the bootstrap program will not touch it. Otherwise, the bootstrap
program creates a physical volume using the 3rd primary partition and
creates a volume group named Unexicon.
Unexicon/boot (LABEL=unxboot)Unexicon volume group is of sufficient
size, a boot volume is established. If the
boot volume already exists, the bootstrap program
will not touch it; otherwise, the volume's contents are created from the
live image. The live image is block copied into the volume. The
contained ext4 filesystem is expanded to the size of the
volume, and then some configuration is performed on the root filesystem
contained to change it from a live image to an installed image. The
filesystem is relabelled as unxboot.
Unexicon/swap (LABEL=unxswap)Unexicon volume group is of sufficient
size, a swap volume is established. If the
swap volume already exists, the bootstrap program
will not touch it; otherwise, a swap filesystem is established and
labelled unxswap.
When the volume group is of insufficient size to allocate a
swap volume, the system will be unable to suspend to
RAM.Unexicon/snap (LABEL=unxboot)Unexicon volume group is of sufficient
size, a snap volume is established. If the
snap volume already exists, the bootstrap program
will not touch it; otherwise, a volume is established.
When the volume group is not of sufficient size to establish a
snap volume, the unexicon checkpoint
and rollback features will be unavailable.boot
volume and is initially established as a checkpoint of the installed
system image. As a snapshot, it appears to have a disk label the same
as the boot volume and appears to contain an
ext4 filesystem.Unexicon/data (LABEL=unxdata)Unexicon volume group is of sufficient size,
a data volume is established.
If the data volume already exists, the
bootstrap program will not touch it; otherwise, one is established. An
ext4 filesystem is created on the volume and the filesystem is labelled
unxdata.
This volume will be mounted on /var/local by a live,
persistent or installed boot.* |
size |
boot |
swap |
snap |
data |
|---|---|---|---|---|---|
| ¶ | CD/DVD | — | — | — | — |
| § | ~2.0 G | — | — | — | ~1.0 G |
| § | ~4.0 G | — | — | — | ~3.0 G |
| † | ~8.0 G | 2.0 G | 2.0 G | — | ~3.0 G |
| ‡ | ~16.0 G | 4.0 G | 4.0 G | 2.0 G | ~5.0 G |
| ~32.0 G | 8.0 G | 8.0 G | 4.0 G | ~12.0 G | |
| ~64.0 G | 12.0 G | 12.0 G | 6.0 G | ~34.0 G | |
| ~128.0 G | 16.0 G | 16.0 G | 8.0 G | ~88.0 G | |
|
¶
Useful for rescue boot only. § Useful for CD/DVD replacement. † Not recommended for production. ‡ Checkpoint constrained. |
|||||
How the volume group is set up depends on the size of the physical volume (USB/SSD/HDD). The table, at the right, summarizes the allocations.
data volume. The volume can grow to the entire
volume group size (from 0.5 to 2G, nominal 1G).
The system will only be able to run live and with minimal
persistence and will be unable to suspend to RAM. Not usable for a
deployment platform.data volume. The volume can grow to the entire
volume group size (from 2 to 5G, nominal 3G).
The system will only be able to run live and with minimal
persistence and will be unable to suspend to RAM. Not usable for a
deployment platform.swap,
2G to boot and the remaining space (1 to 7G,
nominal 3G) to data.
The system will be able to run live or installed and suspend to RAM,
but will be unable to perform checkpoint and rollback. Space will be
constrained for a full blown workstation: not usable for a deployment
platform.boot,
4G to swap, 2G to snap and the
remaining space (1 to 13G, nonminal 5G) to
data.
The system will be able to run live or installed, suspend to RAM and
perform checkpoint and rollback. Checkpoints are limited to 2G in block
changes between the current and checkpointed system image. Checkpoints
will be lost for updates greater than this size. Space is adequate for
a full blown development workstation. Not recommended for a
deployment platform due to checkpoint constraints.boot,
8G to swap, 4G to snap and the
remainder of the disk (4 to 18G, nominal 12G) to
data. The data volume can be resized to make room
for a data snapshot volume.
The system will be able to run with all features without size
constraints. This is the minimum size recommended for a deployment
platform.boot,
12G to swap, 6G to snap and the
remainder of the disk (17 to 65G, nominal 34G) to
data. The data volume can be resized to make room
for a data snapshot volume.
The system will be able to run wtih all features without size
constraints.boot,
16G to swap, 8G to snap and the
remainder of the disk (55G or larger, nominal 88G) to
data. The data volume can be resized to make room
for a data snapshot volume or other needed volumes. Primary partition 4
or extended partitions 5, 6 and 7 are available for additional physical
volumes.
The system will be able to run wtih all features without size
constraints.Unlike some distributions that provide custom partitioning as part of
their install process, unexicon establishes the necessary
partitioning itself. However, because the install
option to the bootstrap program will be ignored if the disk is already
partitioned or the volume group exists, it is possible to custom
partition a USB/SSD/HDD using the rescue image
before booting it for the first time or installing it.
The sections that follow detail the networking setup.
Unexicon networking is set up to be as automatic as possible. In many network configurations it is possible to not do any network configuration on the unexicon platform whatsoever.
In general, no network interface IP address configuration is necessary for a unexicon platform.
Each unexicon platform attempts to obtain network addresses
for all of its interfaces on VLAN ID 0 (i.e. the
base ethernet) using DHCP. When DHCP fails to obtain an address, IPv4
link-local (zero-net) addresses in the
169.254.0.0/16 network will be assigned using proper
IPv4 zero-net link-local procedures.
mDNS and DNS-SD procedures will be established to advertise services
from all platform regardless of IP address assignment.
Static IP addresses can be assigned using the
dhcpcd-ui(1) tool from the system-tray of a
graphical login; however, it is recommended that you establish a proper
primary DHCP server for static assignments instead, when necessary, and
in all but the most trivial of network configurations.
IP addresses on VLAN ID 0 are only necessary for
contacting the outside world, as most inter-nodal communications (even
with management stations) is performed over the VLAN ID
557 bridge VLAN. See VLANs and Bridging
in this document for more information on VLAN ID
557.
Unexicon platforms are already configured to observe and support many DHCP server fields, including default routes, NIS servers, NTP servers, routers, and others. See /etc/dhcpcd.conf for the entire list. The list is much longer than normally supported by a default Linux installation.
It is not necessary to define IP addresses on the local ethernet to unexicon platforms at all, provided that some platform (even a unexicon box with a non-link-local interface) can NAT and provide a default route out of the link local network. Any unexicon platform with an established public address will automatically perform this role.
Also see Routing in this document. Using a number of routing protocols, a unexicon platform can also find its way out of a link-local network without additional IP address assignments.
To automate unexicon platform networking to as high a degree as possible, the platform establishes an STP bridged VLAN that traverses all non-public interfaces. This bridged VLAN is used for inter-platform communications, self-organizing fault-tolerant clustering, and management discovery. To accomplish this, each unexicon platform performs the following on boot (after establishing VLAN ID 0 IP addresses and configuration):
VLAN ID 557
on each non-public interface.VLAN ID 557 interface is locally bridged
with a non-addressable spanning-tree protocol (STP) bridge.10.55.0.0 and network mask
255.255.240.0, but only in the address range
255.255.248.0, permitting 2048 IP
address assignments.VLAN ID 557 interfaces until it can obtain an
address in the 10.55.0.0 address range.Your network should be configured to:
VLAN ID 557 traffic: a WAN brouter should
bridge or trunk VLAN ID 557 traffic between
otherwise isolated LANS, particularly where unexicon
platforms
need to cooperate between sites (as is the case for SS7 STPs, for
example).10.55.0.0/255.255.248.0 range.10.55.8.0/255.255.248.0
address range.10.55.0.0/255.255.248.0 address range
as primary DHCP servers. Each secondary unexicon DHCP
server on the bridged VLAN will backup the primary DHCP server(s).Firewall configuration is automatic. A unexicon
platform
uses a ferm(1) script to establish
iptables(8) based firewalls automatically.
The firewall treats all interfaces with public network addresses with suspicion, and trusts all interfaces without public network addresses.
To facilitate automatic routing and full connectivity, each unexicon platform acts as an IP router and participates in a number of routing protocols. Each platform participates in RIP, OSPF an BABEL protocols. Each platform redistributes its routes and actively participates on all private-network interfaces. Passive RIP, OSPF and BABEL operation is performed on all public interfaces.
To facility tightly synchronized timing between unexicon platforms, each platform participates as both a NTP server and NTP client. It utilizes unicast connections to all NTP servers advertised by DHCP servers. It also participates in broadcast on the local LAN and multicast on trusted interfaces. Configuration is automatic and need not be adjusted. If a number of low-stratum NTP servers are already configured on your network, each platform will converge on them. In the absence of local NTP servers, any unexicon platform with a route to the public network will home off of NTP pool servers.
To facilitate zero-configuration networking, each unexicon platform participates in multicast-DNS and DNS service discovery protocols on all trusted interfaces. Each platform advertises a list of services including HOST, SSH, XDMCP, VNC and SNMP.
Each graphical-booted unexicon platform runs an XDM (X Display Manager) and advertises willingness to manage remote X11 clients by responding to broadcast queries. Each platform can establish X client sessions and provide XDM login services. In addition, XDCMP services are advertise using mDNS and DNS-SD. XDMCP discovery tools are included in the live image that provide network discovery of unexicon platforms in a local network. By also participating in the bridged VLAN, unexicon platforms running on management stations are able to obtain a graphical login to any unexicon platform in a local network. Using the facilities described under PPTP in this document, all platforms can also participate in management from a centralized NOC.
Each unexicon platform will configure itself for remote
logins from NIS users when provided with an
nis-servers option from a DHCP server on network
boot. NIS servers may also be established manually (by editing
/etc/nisdomain and enabling the domainname,
ypbind and autofs systemd services). As with
other situations, centralized administration with a properly configured
primary DCHP server is recommended for all but trivial networks.
Each unexicon platform is capable as acting as a VNC server or client using PPTP.
When acting as a PPTP client and a a PPTP server is identified by a
DHCP server, the platform will establish a VNC connection to the PPTP server
and offer routes to the NOC to other platforms on the network. Static PPTP
server definitions can be established using the
nm-applet(1) tool that appears in the system tray of
a graphical login to the platform; however, we recommend that DHCP servers
be configured to centralize administration in all but the most trivial
of networks
When acting as a PPTP server, each unexicon platform will
accept incoming connections and proxy the remote client in a local LAN
in the address range 10.55.4.0/21. When internet
facing, the unexicon platform will perform this function
automatically. When acting behind a firewall, you can DNAT PPTP traffic
to the server and it will automatically serve a unexicon
NOC on the local LAN to the PPTP client.
The suite of automatic networking provided by a unexicon platform supports local direct network connections using active USB cables. Active USB cables can be directly connected between a mobile management station (e.g. a notebook running unexicon as a management station) and any unexicon platform. Simply connecting the cable between the management station and a front USB port on the platform will establish a zero-configuration network between the two boxes and advertise to the management station all available services.
See the unexicon hardware page for more information on availability and supported cables.
Unexicon, unlike some server-only distributions, is tuned for graphical login accounts. Both platforms acting as management stations and deployment platforms provide graphical boot and login services using lightweight window managers and an integrated unexicon XDE desktop environment.
Management an analysis applications, however, should of course be run from dedicated management stations rather than being run on a deployment platform directly.
The live, persistent and installed systems have two user accounts
defined: root and unexicon.
Both accounts are assigned default passwords that must obviously be
changed.
Normal Linux user account tools and commands can be used to manage these user accounts.
rootunexicon administrative
account.unexiconunexicon user account is assigned user id
1000 and group 1000.wheel group and
almost all other administrative groups.unexicon user account has
sudoers privilege to execute commands as
root without being prompted for a password. Remote
logins to this user are permitted./home2/unexicon:
/home2 is used instead of /home to avoid
conflict with NIS autofs mounted home directories.Due to the unique layout of the unexicon drive partitioning, it is possible to upgrade the
live image on an installation by simply overwritting the USB/SSD/HDD
with the new ISO image. Upon booting the
"Unexicon i686 install" boot menu
selection, the previous partition table will be restored and only the
live image in the first primary partition and outdated persistent
snapshots in the second primary partition will be altered. The logical
volumes in the third primary partition will remain untouched. A
subsequent boot into the
"Unexicon i686 installed" boot menu
selection will reboot into the untouched installed system. In this way
the live image and boot scripts can be upgraded on an installed
distribution. Follow the same steps outlined above under "Preparing an SSD."
Software modules provided on the unexicon modules page attempt to automate the software installation and management as much as possible. Modules can be installed from a unexicon system by merely clicking on the provided link.
Nevertheless, those that are responsible for maintaining
unexicon platforms should familiarize themselves with the
Arch Linux pacman(8) and
yaourt(8) package management tools starting with the
Arch
Linux pacman wiki page and the manual pages for these commands
provided on the unexicon live image and installed
systems.
Unexicon provides software repositories compatible with the Arch Linux package management tools and core repositories available at the Arch Linux website and mirrors. The unexicon repository definition and software signing keys are incorporated into the release and live image. The Arch Linux repositories provide thousands of binary packages supported in its core repositories.
The unexicon repositories served from the unexicon website currently provide 232 binary software packages that are maintained by unexicon and not provided elsewhere as binaries, only provided in the AUR as source, or not provided elsewhere at all. 138 of these packages are included in the live image's 771 installed packages. See the unexicon software page for a full listing of software included in the live image.
The unexicon distribution is designed to permit full
checkpoint and rollback of online upgrades for installed systems. The
Unexicon/snap volume is used to perform the checkpoint.
After upgrade and stress testing, the upgrade checkpoint can be
discarded and the upgrade committed, or the system can be rolled back by
booting into the checkpoint device-mapper snapshot image and later
discarding the upgrade. The operational database in the 3rd partition
is excluded from the rollback to allow database updates to persist
across the rollback.
The checkpoint, rollback and commit capability for software upgrade is performed as follows:
ESC key is used to bring up the boot
menu.Unexicon recovery..." is selected
from the main boot menu.Unexicon i686 checkpoint" is selected
from the submenu, and the system boots into a checkpointed system.pk-applet(1) in
the system tray on the unexicon login, or executing
yaourt -Syu./dev/mapper/Unexicon-snap device and comparing the
changes with the root directory.Unexicon i686 previous" from the boot
recovery submenu. This will boot into the system as it was before the
upgrade. The system can be compared online with the upgraded system by
mounting /dev/mapper/Unexicon-boot and comparing the
changes with the root directory.Unexicon i686 rollback" from the boot
recovery submenu. This will boot into the system as it was before the
upgrade, and the upgraded system is abandoned and discarded.Incremental checkpoints of the system can be performed at any time by
selecting "Unexicon i686 checkpoint" from
the boot recovery submenu. Bear in mind, however, that the previous
checkpoint is discarded when this item is selected. Only stable and
trusted system configurations should be checkpointed. Stable and
trusted deployed systems should be checkpointed on a regular backup
schedule to avoid loosing stable changes since the last checkpoint.
A checkpointed system can have its system image backed-up to
offline storage by mounting the
/dev/mapper/Unexicon-snap
device and dumping the filesystem from the device to the off-line
storage.
A checkpointed system can have its system image restored
from offline storage by mounting the
/dev/mapper/Unexicon-snap device and
restoring the filesystem to the device from off-line storage.
The checkpointed system can then be run or rolled back by rebooting
using the "Unexicon i686 previous" or
"Unexicon i686 rollback" options (resp.)
from the boot recovery submenu.
Note, however, that the /dev/mapper/Unexicon-snap
device should not be backed-up or restored when the system is booted
with "Unexicon i686 previous," because in
that case the "/dev/mapper/Unexicon-snap" device is
mounted as the root filesystem.