Do you want to use a distro we do not offer as standard if you have a particular Xen file system image that you'd like? If so we can support that.
Just pop in an order and in the order comments request a temporary partition separate from the default file system image we will give you. If you already have a server, you can mount one of the backups instead and overwrite that.
You can upload your image to that file partition. Something like the following command can copy up a file system image:
# run this from your PC or where ever. dest is your VPS IP
dest=0.0.0.0
rsync --rsh=ssh --compress --recursive --times --owner --group --one-file-system --numeric-ids --links --archive \
--exclude '/proc/*' --exclude '/sys/*' \
--exclude /boot /* $dest:/backups/
You may need to 'tweak' a few things on the resulting image.
Newer server installs such as debian 12 may mostly work as is. Enable our key if you would like us to log in and provide support.
# install the main rimuhosting ssh key, so we can help manage the server
grep -qai rimuhosting $CHROOT/root/.ssh/authorized_keys || (mkdir -p $CHROOT/root/.ssh; echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBufK3VvFDfjRAswyZibINSWLILZ4sTGuW8ffF5tmMRouGbA55SbUqjOeDQgBfUs0HRp5K34Qnw608DEhZwz6or5nSWXS3GKGBJFR+yPgkvoU4dwymKn54Y/kH0LkTtgCv2bSfnUJcWvXfxpgEnnMr3iUmVY2WvsWt4TWADsfQ6Kw== rimuhosting" >> $CHROOT/root/.ssh/authorized_keys)
The following commands are an example and are for older installs like Centos6, but they show solutions to things you may see. You probably should not copy/paste them unless you are confident in what they will do.
# CHROOT=/
# the location from where you will ultimately be trying to boot
CHROOT=/backups
# you will need these devices
for i in 1 2 3 4 5 6 7 8 9 ; do
mknod $CHROOT/dev/xvda$i b 202 $i
done
# set from where you can log in using the rimuhosting console over ssh feature
if [ -e $CHROOT/etc/securetty ] && ! grep -qai tty0 $CHROOT/etc/securetty ; then
echo "tty0" >> $CHROOT/etc/securetty
fi
if [ -e $CHROOT/etc/securetty ] && ! grep -qai 'vc/0' $CHROOT/etc/securetty ; then
echo "vc/0" >> $CHROOT/etc/securetty
fi
# in the VPS we stop it by sending it a ctrl-alt-del signal. So we want it to shutdown when it gets this (not reboot)
if [ ! -e $CHROOT/etc/inittab.orig ]; then
cp $CHROOT/etc/inittab $CHROOT/etc/inittab.orig
fi
# we want something like this in inittab to shut down the vps on cad ca::ctrlaltdel:/sbin/shutdown -h now
sed --in-place 's#ctrlaltdel:/sbin/shutdown.*#ctrlaltdel:/sbin/shutdown -h now#' $CHROOT/etc/inittab
# just need the one console running
for ((i=2;i<7;i++)); do replace "$i:2345:respawn" "#$i:2345:respawn" -- /backups/etc/inittab; done
replace "1:2345:respawn:/sbin/mingetty tty1" "co:2345:respawn:/sbin/mingetty --noclear console" -- $CHROOT/etc/inittab
# make sure we have these devices
/sbin/MAKEDEV -d $CHROOT/dev random urandom net
# NPTL / TLS does not work well with VPS setups. Easiest to just move it out of the way
mv $CHROOT/backups/lib/tls $CHROOT/backups/lib/tls.broken
# disable 'unnecessary' services. Or use update-rc.d if that is your distro poison
for i in cups gpm haldaemon hplip apmd ip6tables iptables kudzu acpid alsamixer
netfs nfslock nifd pcmcia smartd ; do /sbin/chkconfig --del $i; done
If you are running a newer debian variant, the eth0 is named enx0 or similar. This can fix that back to eth0 (required)
# To aviod eth0 being renamed, create
# the appropriate link to mask systemd from doing that.
# This issue affects el9 and above and Debian12 and above, but
# prex-empt this probblem in other distros too by adding the mask
# in case they upgrade systemd.
mkdir -p ""/etc/systemd/network
ln -s /dev/null ""/etc/systemd/network/99-default.link
If you are running a distro that requires recompilations ( **cough** gentoo **cough** ), please keep it to a minimum. The VPS is running on a host with other users. And long compiles (e.g. over 30 minutes) or frequent recompiles are not fair on other VPS users.
In /backups/etc/inittab you should have just one getty line: co:2345:respawn:/sbin/mingetty --noclear tty1
Setup /backup/etc/fstab so it looks like your main /etc/fstab file system. When we boot up your /backup partition we will change it to xvda1 (when at /backups it is probably running as xvda2). i.e. leave the / entry in /backup/etc/fstab as it was originally (and maybe remove the /backup entry since that will likely not be there after the boot up to the /backup parititon when it is mounted as /).
Checklist:
When you're done with the setup, let us know and we will reboot your VPS with the new disto filesystem at /dev/xvda1. Be sure to let us know the root password; where your network is configured; and where there is an equivalent to rc.local on your distro so we can manually add network or sshd setup to the boot up process to get you going.
If the new file system won't boot up we can restart you with your original file system.
Also note that you should be able to access your VPS (even if it does not come up with the network working) via our console-over-ssh feature.
Note that working with custom vps images can be a bit fiddly. We are happy to help (as with anything) though we do ask that you submit any work requests for getting the custom VPS image working under the paid type support ticket.
A support fee will apply to customers setting up a custom VPS image. It will be the greater of $30 or $60/hr spent helping get the image remotely accessible.