Updating a Testing Partition Without Rebooting
Some of the computers in the house network have testing partitions. For example, there is a Slackware 15.0 partition on some computers although the active system partition is Slackware 14.2.
These testing partitions tend to be used sporadically and in spurts. Keeping systems patched is important. Falling too far behind with patches sometimes causes headaches. Commonly these partitions are updated during active testing, which is done by booting into that partition. Rebooting to patch is okay but not always desired or convenient.
chroot environment helps keep testing partitions updated. Important is the environment is configured so the updating tools act as though the environment is legitimate. File paths are important. In the house network are local Slackware repositories from which all systems are updated.
A mount point is needed to use a chroot environment. Many people recommend bind mounting the following directories of the host:
Bind mounting contains a presumption the chroot environment is much the same as the host. This is not the case with the house network testing partitions. The host environment is Slackware 14.2 and the testing environment is Slackware 15.0.
The testing partition is a different partition on most of the systems. A local file that is synced across all systems in the house network contains comments to identify those partitions.
A shell script helps coordinate these changes.
mount -t proc none $CHROOT_MOUNT_POINT/proc
mount -o bind /dev $CHROOT_MOUNT_POINT/dev
mount -o bind /dev/pts $CHROOT_MOUNT_POINT/dev/pts
mount -t sysfs none $CHROOT_MOUNT_POINT/sys
mount -o bind /tmp $CHROOT_MOUNT_POINT/tmp
Working in a chroot environment is elusive in some ways. Mostly a chroot environment is intended to limit privileges and access to a portion of the file system by changing the root of the file system. A chroot environment does not change the environment. Little things like hostnames and environment variables do not change inside the chroot environment. A user can forget the environment is a chroot.
To help not forget, the shell script wrapper temporarily modifies the
.bashrc file in the testing partition. The temporary changes include the
PS1 variable to identify the testing partition hostname in yellow color and add the text
(!chroot!) in red color. The changes include a yellow color caution banner when entering the chroot environment.
With these changes the shell script enters the chroot environment:
chroot $CHROOT_MOUNT_POINT /bin/bash
After exiting the chroot environment the shell script wrapper restores the original
.bashrc and unmounts the mounts.
The laptop has a 64-bit testing partition and a 32-bit partition. Trying to chroot into the 64-bit testing partition from the 32-bit is not a good idea.
A chroot is not intended to replace containers or virtual machines. Because a chroot is a limited environment, the script wrapper is intended to update patched packages and little more. The environment is not treated like a normal environment. Basically, get in, update, and get out.