Install Slackware on an online.net Dedibox BareMetal Server

This tutorial explains on how to install and boot Slackware Linux on online.netDedibox BareMetal Server Start Family. It is focused on servers that you don't have the physical access to and those that don't support remote exposure of the hardware (i.e. no KVM over IP). The setup of this kind of servers is possible through a Web interface. Fortunately or not, this interface doesn't natively support Slackware installation. No worries, we will manage nonetheless.

Although the very first parts of the tutorial are Dedibox server specific, the rest is more generic. This means that the information provided here applies equally to other hosting offers, which just must provide similar rescue OS (more on the rescue OS down below). Conversely, the first parts apply well to Linux distributions other than Slackware. If you need fine grained control over the installation process on the Dedibox server, you're in good place.

1. Dedibox rescue OS

The rescue OS is an operating system that you can boot your server into using the Web interface. This OS allows you to perform maintainability tasks, should your main operating system fail to boot or should you need to access the server, while bypassing your main OS. There are multiple versions of the rescue OS to choose from; we will be using Linux based one.

You can (and should) connect to the rescue OS over SSH. One of the characteristics of the rescue OS is that it is volatile, meaning that changes made to it are lost after reboot. But more importantly, the SSH host keys are regenerated every time the rescue OS is booted, which results in the SSH host's key fingerprint being changed too, whenever you reboot. This makes checking the authenticity of the server a bit cumbersome.

One of the ways to verify the host's authenticity is to open online.net technical support ticket, asking to provide you with the rescue OS host's key fingerprint. And because the fingerprint changes with every reboot, it is not desirable to reboot the machine during Slackware installation. No big drama, it is possible to successfully install and then boot Slackware into its full glory with only a single reboot at the end of the journey. You can also connect without ensuring the host's authenticity, have a play and even trial installation. Once you are familiar with the environment, you can reboot again into the rescue OS, ask the technical support for the fingerprint, cleanup the hard drive and perform the final installation and setup. Just beware that without verifying the host's authenticity you are susceptible to MITM attacks. Although the rescue filesystem is volatile and you can wipe the disk content to make sure it is clean and safe, still, the hardware itself might be the target of the attack. And nowadays, hardware is actually running software (firmware) more often than not.

2. Serial console

The Web interface provides a serial console option, which allows you to interact with the server hardware. It is of somehow limited use with the rescue OS (i.e. no login possible), but can be fully utilised with the main OS. If properly configured, it will allow you to see the boot process of the main OS and also to have a terminal login, should the SSH connection be not available for whatever reason. (But don't expect anything fancy, it's just a serial console after all).

It turns out that, it is actually possible to log in into the rescue OS using the serial console. At least it works when Ubuntu 16.04 amd64 is selected as rescue OS. Unfortunately, this tutorial was written with the assumption that it was not possible (which actually was the case!). For that reason, some steps are more complex than they would be if the serial console was available from the beginning. This applies especially to the server's SSH authenticity verification step. Unfortunately, I won't update the tutorial to accommodate for this discovery.

3. Making the rescue OS available

If you've just purchased a fresh server, it should come with no operating system pre-installed. Unfortunately, it means also that the rescue OS is not available yet.

To enable the rescue OS: using the Web interface, go to your server management page: Server → Server list → (server name) Manage. If the only option you see is [INSTALL], then the rescue OS is not available and you have to first install one of the offered operating systems. (Purist's note: choose the operating system wisely, as the icon associated with this OS is going to represent your Slackware system thereafter). Once the OS installation is complete, you are going to be presented with more options: [REBOOT], [RESCUE], [SERIAL_CONSOLE] and [INSTALL]. You're ready to go now. Just don't boot the rescue OS yet.

4. Preparing rescue OS access over SSH

Be careful not to overwrite your workstation's SSH keys in ~/.ssh

We are now about to create two SSH keys pairs. One pair is going to be used to login into the rescue OS and the other (only public key part) for rescue OS authentication. Type the following on your workstation:

Using the Web interface, go to your SSH keys management page: logged in as (username) → SSH keys and add the auth_key.pub and login_key.pub public keys. Note that after the successful addition, the page is not automatically refreshed and to actually see the keys, you have to click SSH keys link on the left hand side.

Uploading the keys through the Web interface has the effect of making them available to the rescue OS. When the rescue OS boots, the keys are simply appended to the ~/.ssh/authorized_keys file for the particular user.

These keys might be safely removed from the Web interface once you are done with the Slackware installation.

5. Booting and connecting to the rescue OS

Using the Web interface, go to your server management page: Server → Server list → (server name) Manage. Enable the serial console by clicking on the [SERIAL_CONSOLE] button and follow the guide. The console will be opened in a new browser tab. Note that the console connection has expiration time, so it won't stay there forever. Also, there are not many messages appearing related to the rescue OS booting, but it's still better than nothing. Rescue OS takes some time to boot and being able to see it can let you calm down a bit (just keep in mind that there is some time between the moment the messages stop appearing and the moment you can actually connect over SSH). The reason you need to start [SERIAL_CONSOLE] before [RESCUE] is that, the [SERIAL_CONSOLE] button disappears once you boot with the rescue OS.

Now go back to server management page and click on [RESCUE]. When prompted for the operating system selection, choose [Ubuntu_16.04_amd64] and then click on [CLICK_HERE_TO_LAUNCH_THE_RESCUE_SYSTEM]. After a while, you will be presented with the details needed to connect to the rescue OS over SSH. You can also switch to the [SERIAL_CONSOLE] output window to monitor what is happening.

Once the rescue OS is fully booted, connect to it from your workstation:

$ ssh username@x.y.z.w -i ./login_key

When asked Are you sure you want to continue connecting (yes/no)?, answer yes.

It might be a good idea to temporarily add the rescue OS SSH host's key fingerprint to the ~/.ssh/known_hosts file on your workstation. This will allow you to re-login back (e.g. in the case of a broken connection) into the rescue OS without the need for repeating the authentication procedure described below. Just remember to remove the fingerprint after you are done or if the authentication procedure described below fails.

Once logged in, to authenticate the rescue OS, on the server side type the following:

$ cat ~/.ssh/authorized_keys

and then compare the public keys printed on the terminal with auth_key.pub and login_key.pub public keys you generated previously. If both the keys between the server and the workstation match, you are secure to go. (Again, if you want to understand the details, refer to the aforementioned LinuxQuestions.org thread).

Now, on the server side, I suggest you to first start the screen program and then log in as root (the password is given on the rescue OS connection details page):

$ screen
$ sudo su -

(Being paranoid, I change the user and root passwords provided by online.net).

I will not go into details of screen program, but the reason we want to use it, is its ability to maintain the remote terminal opened, even if the SSH (or rather network) connection breaks or you accidentally close the terminal window on your side. Normally, such an event would break the installation process. If that happens to you, and you use screen, then you can regain the remote terminal (with all the started commands still executing!), by simply connecting over SSH and then re-attaching to the so-called screen session:

All of the above means also that you cannot stop remote command execution by just closing the local terminal window; screen session will be maintained on the remote end until you explicitly close it. BTW, you can also use this functionality to lower the network traffic during installation phase, i.e. once the packages started installing and need no attention, you can detach from the session and then re-attach some time later to check the status. You use Ctrl+AD keyboard combination to detach from screen session. Check the Internet on how to use the screen program (the man page is actually enormously long).

6. Setting-up Slackware installer environment (chroot)

The main motivation behind this HOWTO is the fact that online.net does not provide direct method of Slackware installation on their Dedibox servers. And that is great! The point is, if such a method existed, it would be something unfamiliar to a Slackware user: a GUI/Web based installer. Whereas being dropped to the Slackware's installer shell allows you to install and configure the system the way you want (TM). All the advanced options are available without much hassle. And we're going to use them all. :-^

The procedure detailed below is known and common. We're going to chroot into the unpacked Slackware initrd image and run setup from within there.

Our Slackware chroot will be running out of Ubuntu rescue OS, which is running out of RAM based filesystem. The size of the RAM filesystem is ~8.0 GiB (that depends on the total amount of system RAM). Hint: 8.0 GiB is more than enough to hold the full Slackware packages tree, if need be (i.e. if you want to download the packages before running setup).

Once you chrooted, you might want to play with the TERM environment variable, which is going to influence the way that dialogs are displayed. By default, TERM=linux and it does not work well if you use screen or are connecting from terminal emulator running under X.

For best results with screen, use the following:

$ export TERM=screen

and if you do not use screen, but are connecting from within X:

$ export TERM=xterm

Finally, for the bare virtual terminal (VT), leave the default:

$ export TERM=linux

Welcome to the Slackware Linux installation disk!

7. Partitioning

You can now partition the disk to your liking, with two exceptions. In this tutorial, I'm going to use separate partition to be mounted on /boot directory. This directory will hold the kernel, initrd and bootloader config file. Which brings us to the second exception: as the bootloader, I'm going to use syslinux installed to MBR, which means the disk has to use MBR label type. If you need GPT, you're on your own.

The filesystem of the /boot partition has to be supported by syslinux. ext4 will do the job just fine. And when it comes to the size, 128 MiB is sufficient.

The following instructions will destroy the data on the disk.

You can use your favourite partitioning tool, e.g. fdisk, cfdisk, etc. I'm going to use parted. Note that the disk should be in “unmanaged” state, that is, services like LVM2 or software RAID (mdadm) should be deactivated. I had a lot of headache releasing the disk from the control of LVM2, when I was playing with it (but I managed ).

By the way, the disk is already going to contain the partition table, which was created when we were installing one of the stock OS-es in order to enable the rescue OS. The partition table can be wiped with the following commands:

$ dd count=1 bs=512 conv=notrunc if=/dev/zero of=/dev/sda
$ partprobe

The following parted commands will create the MBR label and the /boot partition:

Having the /boot[/dev/sda1] partition in place, you can partition the remaining space in the way that suits your needs. I'm going to use LVM2 to manage the disk, so I create one big partition [/dev/sda2] that is going to be passed to LVM2. The setup procedure for enabling LVM2 is described in Appendix A. The following parted command will create the required partition:

$ # Passing "-a optimal" automatically aligns at the last sectors of the disk.
$ # The start and end offsets have to be given explicitly:
$ parted -a optimal /dev/sda mkpart primary 129MiB 100%
$ # Set the 'lvm' flag only if you plan to use LVM2 for managing the disk.
$ parted /dev/sda set 2 lvm on

8. Slackware installation (setup program)

If you prefer to download the required packages yourself, instead of letting the setup program do it for you (I actually prefer it that way), now is the time.

I want to use rsync to download the packages beforehand. Since Slackware chroot does not provide rsync command, we have to leave Slackware chroot for a moment, use rsync from Ubuntu rescue OS and then come back:

Having all the partitions in place, it's now time to run the setup program and perform the installation as you know it. Just remember to format and mount the /boot partition when prompted by setup. When prompted, skip LILO installation, as we're going to use syslinux instead. If you downloaded the packages beforehand, point the setup to the pre-mounted /packages directory. Otherwise, use setup to download the packages for you.

Don't reboot the machine when the setup program offers to at the end of the installation.

9. Freshly installed Slackware chroot

Yes, one more chroot to deal with. The configuration of the freshly installed system is best performed from the actual system itself. And we're going to do exactly that. When the setup program finished its job, it has left the Slackware root filesystem (and some additional ones) mounted on /mnt. And there is nothing preventing us from chrooting into this directory, meaning that we can actually “log in” into the freshly installed system without rebooting.

This system is somehow limited (i.e. there are no services running), but has all the tools needed to perform the final configuration steps before rebooting the server.

To avoid any unpleasant surprises, we mount some possibly needed filesystems, before chrooting:

This configuration will enable the messages to appear on the serial console. I also specify some kernel parameters (printk.time=0quiet) to considerably silence its output (error messages would still appear). As I do not want to bother with IPv6, I disable it at kernel level (ipv6.disable=1). As you can see, we will be using the generic kernel with initrd. This is the only way (that is, by means of initrd) the LVM2 can be made functional.

Note that the kernel and initrd paths specified in syslinux.cfg have to be relative to the /boot directory. This is because syslinux is unable to read from LVM2 based root partition, so something like /boot/vmlinuz-generic would not work (/ is on LVM2 partition in my case).

As the comment says, refer to the mkinitrd.conf man page for details. In particular, make sure your MODULE_LIST, ROOTDEV and ROOTFS are defined correctly. If you don't need LVM2 support, you can set LVM=“0” (or comment it out).

The notable thing is how the KERNEL_VERSION is automatically derived, not for the running kernel, but rather for the installed kernel (which might be newer or older than the running one). /etc/mkinitrd.conf is sourced by the /sbin/mkinitrd script, so it is possible to use shell commands within the config file. On standard Slackware installation, you will find that /boot/vmlinuz-generic is actually a symlink:

will simply extract the version number from the installed kernel image.

And finally, to create the initrd, run the following command:

$ mkinitrd -c -F

Note that it is not necessary to run any syslinux related commands after creating or updating the initrd image. This is different from LILO, where you have to run lilo command after changing the initrd image.

13. Enabling serial console access

As of now, the serial console configuration in /boot/syslinux.cfg allows for interacting with the bootloader and also to see the kernel messages, but it does not allow for root login over serial port. If you want to enable it, then uncomment the following line in /etc/inittab:

s2:12345:respawn:/sbin/agetty -L ttyS1 9600 vt100

and the following line in /etc/securetty:

ttyS1

You might also want to comment out the follwing lines in /etc/inittab:

tty[1-6] are for the standard VT login prompts, but since we have no keyboard and no display, we cannot make any use of them.

14. Finalising the installation

We're done with the installation and initial configuration of the Slackware Linux. You can now prepare the system for reboot and, well, reboot. Before doing that, you might also consider looking at the Appendix B, where I explain how to prepare the SSH stuff, so that after rebooting, you can connect to the server with SSH right away. (Otherwise, you will have to log in over serial console to perform the other configuration tasks).

First, prepare the hard disk to safely survive the reboot phase. Note that, I only (u)mount /mnt/boot and /mnt partitions as these are the only hard disk partitions I have. If you have more mounted disk partitions, you should umount them too:

Remember that the disk has already been partitioned using MBR in the “Partitioning” chapter and /dev/sda2 already exists. The following set of commands will activate LVM2 on /dev/sda2 and create the partitions (the LVM2 partitions are going to sit on top of /dev/sda2 partition):

The good thing about LVM2 is that you can easily add more partitions later on.

I have chosen partition sizes that suit my current needs, leaving significant free space. LVM2 can easily grow the sizes later on if needed.

I haven't created the swap partition. The server has more than enough of RAM. But if needed, it can be easily added later on.

B. SSH server configuration (before rebooting)

You have to be in the chroot of the freshly installed Slackware system to perform the configuration steps detailed below.

If you enabled the sshd service during setup, it'll be automatically started the next time the Slackware system boots. Unfortunately, you won't be able to connect to it for two reasons:

the host keys are not generated yet, so you won't be able to verify host's authenticity and of course you don't want to connect without being able to verify it,

user's public key authentication is not set up and of course you don't want to be logging in using password authentication.

To solve the first issue, we need to manually perform the task that would normally be done by the Slackware init scripts when the system boots for the first time. Generating the host keys basically boils down to the following command:

$ ssh-keygen -A

And then to obtain the host's key fingerprint (I stick to RSA):

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Setting up public key authentication is a bit more cumbersome, but still far from being rocket science. :-^ First, you need to upload your public key from your workstation to the server. Run the following command on the workstation:

$ scp -i ./login_key ~/.ssh/id_rsa.pub user@x.y.z.w:~

NOTE: The above command uploads ~/.ssh/id_rsa.pub public key, but for the transfer authentication, it uses the very same key you uploaded earlier using the Web interface.

Now, back to the server, create the required ~/.ssh directory:

$ mkdir ~/.ssh

I told you to use the screen program at the beginning, right? Now we will make use of it. The public key that you uploaded above has been placed in the user home directory of the Ubuntu rescue OS. We need to rename it to the authorized_keys file in the ~/.ssh directory of the fresh Slackware installation: