OsMutation: reinstalling an OpenVZ or LXC VPS by swapping container files

Why a container can change operating system

OsMutation exists for a specific situation: a cheap VPS sold as an OpenVZ or LXC container arrives with a distribution you do not want, and the provider will not change it. The README's explanation of why the operation is possible at all is the key to the whole tool.

OpenVZ and LXC are container virtualisation technologies where the host operating system kernel is shared between the host and every container on it. All the applications and runtime libraries an operating system needs are packed together inside the container itself rather than in the kernel. So when you want to replace the operating system, you can replace the files in the container. The README is direct about the rest: pay attention to the order of actions, because there are dependencies between the files.

That reasoning also explains the limits. Nothing here virtualises a machine or installs a kernel. A container is a filesystem with a configuration, and replacing a filesystem is a different and much smaller job than reinstalling an operating system on a virtual disk. The target systems, Debian, CentOS and Alpine, are chosen because they can run in a container and share the host kernel.

The audience is therefore not general server administration. It is providers, resellers and anyone with root inside an OpenVZ 7 or LXC container whose image needs to change.

Where the operating system images come from

The script does not build its own images. The README names two sources.

LXC templates are downloaded directly from images.linuxcontainers.org, the Linux Containers image archive. OpenVZ 7 templates are extracted from the official OpenVZ 7 ISO, which is a different route: instead of downloading a prepared template file, the script works from the distribution media itself.

Both routes matter for anyone planning an update cycle, because the first depends on an external image server being reachable and the second depends on the ISO being available in the form the script expects. The repository's own release tags record which images were fetched and when, with names such as LXC-202604202238, described as images fetched on 2026-04-20 at 22:38, and two earlier ones on 2026-04-13 and 2026-04-06. Those tags are a weekly refresh of the image set rather than a release of new code.

The project credits a community gist as the inspiration for the approach, and the To Do list includes support for a custom template source, which tells you that today the source list is fixed.

Running the reinstall script

The documented usage is a single command that downloads the script, makes it executable and runs it. The wget form is the one the README lists first:

wget -qO OsMutation.sh https://raw.githubusercontent.com/LloydAsp/OsMutation/main/OsMutation.sh && chmod u+x OsMutation.sh && ./OsMutation.sh

If wget is not what you have, the same thing with curl works:

curl -so OsMutation.sh https://raw.githubusercontent.com/LloydAsp/OsMutation/main/OsMutation.sh && chmod u+x OsMutation.sh && ./OsMutation.sh

In both cases the script is fetched from the repository's main branch over HTTPS, saved locally, made executable and started. There is no configuration file and no flag to set in the documented usage, which means the choices it makes for you are hard-coded rather than negotiated.

Two things to keep in mind before running either line. The first is the notice in the README: a fresh system will be installed and all old data will be wiped, so back up anything important first. The second is that you are executing a script you just downloaded, as root, inside a container whose entire purpose is to be overwritten. Reviewing the script before running it, rather than after, is the only chance to see what it does.

The tight variant for small disks

There is a second script for containers whose disk is small. The README describes it as for VPS whose disk is less than 1 GiB and marks that support as experimental. It is fetched from a different path in the same repository, OsMutationTight.sh rather than OsMutation.sh:

wget -qO OsMutation.sh https://raw.githubusercontent.com/LloydAsp/OsMutation/main/OsMutationTight.sh && chmod u+x OsMutation.sh && ./OsMutation.sh

The repository root holds three scripts, OsMutation.sh, OsMutationTight.sh and OsMutationKvm.sh, plus a takeover.sh.

One detail in the command above is worth noting rather than repeating blindly. The wget -qO flag saves the download under the name OsMutation.sh even though the URL points at OsMutationTight.sh, so the local filename and the remote file differ. The script still runs, because that is what the command executes, but the file on disk is not named after what it contains, and if you keep several versions around you will need to track that yourself.

For a small disk the difference the tight variant makes is a matter of footprint, since the standard image set has to fit in a container that may have less than a gigabyte to work with. The README calls this experimental, so treat the small-disk path as something to try on a disposable container rather than on one holding data.

What it will not do, and the script in the tree that suggests otherwise

The README states the limits plainly. OpenVZ 7 and above is supported, but OpenVZ 6 is not. Virtual machines are not supported, and it names kvm, xen and vmware as examples.

The reason for the version boundary is structural. The OpenVZ 7 templates are extracted from the official OpenVZ 7 ISO, so the script's toolchain assumes the layout of that release. OpenVZ 6 has a different filesystem arrangement, and nothing in the README suggests the extraction path was ever adapted for it.

Now the interesting part. The repository tree contains a file called OsMutationKvm.sh, which suggests a variant for KVM guests exists in the code even though the README says virtual machines such as kvm are not supported. The README does not mention that file, does not describe when it works, and the To Do list does not mention it either. Whether it is a work in progress, a workaround for a specific provider, or something that predates a change of mind, the documentation does not say. If you need KVM support, that is a question for the author rather than something to try on a machine you care about.

The broader point is that the script's supported surface is narrow by design, and the narrowness is a property of the container model rather than a lack of effort. Replacing files in a container is a well-defined operation; doing the same to a virtual machine means installing an operating system, and that is a different project.

The To Do list is a useful list of known gaps

The roadmap at the end of the README is short and specific, and it reads more like a list of known gaps than a plan.

Support for a non-interactive mode by accepting arguments is the first item, and it is the one that most affects automation. As documented, the script runs interactively, which means an automated reinstall pipeline has to drive a terminal session rather than call the script and check an exit code.

Support for a custom template source is second. Today the LXC templates come from images.linuxcontainers.org and the OpenVZ 7 templates from the official ISO, and there is no documented way to point the script at an internal mirror. For an organisation that has to install from its own artefact store, or that runs where external downloads are blocked, that is a hard stop rather than an inconvenience.

The remaining items are the usual edges: support for more operating systems, a fix for the networking bug of CentOS under LXC, and automatic configuration of the IPv6 network. The CentOS networking entry is the one to watch if you plan to install CentOS in an LXC container, since the README is telling you in advance that the network configuration is broken in that combination. Automatic IPv6 configuration is not yet there, so a container that needs IPv6 will need that set up by hand.

Maintenance, licence and the risk of a remote script

The project is not archived. The last push to the repository was on 2026-04-20, and the release tags before that show a weekly cadence, with image sets fetched on 2026-04-20, 2026-04-13 and 2026-04-06. The tags carry a timestamp rather than a semantic version, so they record what was pulled rather than what changed in the code.

The licence is GPL-3.0, with a LICENSE file at the repository root. That is the copyleft licence, which means a derived version of the scripts carries the same obligations, and it is worth noting that the project is distributed in a form that most users run rather than modify. This is a description of the terms rather than legal advice.

The structural risk is the distribution model itself. The documented usage downloads a script from a GitHub raw URL over the network and executes it immediately as root inside a container whose filesystem it is about to replace. There is no checksum, no signature and no pinning to a release tag in the documented command; the URL points at the main branch, so the content can change between the moment you trust the command and the moment you run it. For an operation this destructive, fetching a tagged release and reading it first is the more careful path, even though the README does not suggest it.

Editorial conclusion

Adopt OsMutation if you run OpenVZ 7 or LXC containers on a host where you control the container filesystem and you need to change the distribution without rebuilding the virtual machine, particularly when a provider's stock image is unusable. Do not use it on OpenVZ 6, on KVM, Xen or VMware guests, or anywhere the data on the disk still matters, because the operation wipes it. Verify first that your container platform exposes the template sources the script needs, that the disk size fits the target image, with the tight variant documented as experimental below 1 GiB, and that the image you fetch is the one you intended to boot before you let it replace the filesystem.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. LloydAsp/OsMutation on GitHub
3. Project website
4. README
5. Releases