[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

This is an old revision of the document!


Install Slackware on an online.net Dedibox BareMetal Server

This tutorial explains on how to install and boot Slackware Linux on online.net Dedibox 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.

Fortunately, there is an alternative method that does not involve the engagement of the technical support. You can read the full details on LinuxQuestions.org: Verifying host authenticity (SSH) after logging in, over then accessible secure serial terminal. In the tutorial itself, I will only focus on how to get the thing done.

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: ServerServer 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:

$ mkdir dedibox_rescue_os_keys
$ cd dedibox_rescue_os_keys
$ ssh-keygen -t rsa -f login_key -N ''
$ ssh-keygen -t rsa -f auth_key -N ''

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: ServerServer 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.

It is still possible to access the serial console, even if the [SERIAL_CONSOLE] button is not visible. You just need to go to https://console.online.net/en/server/state/XXXXX/bmc address, replacing XXXXX part with the actual number of your server.

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:

$ screen -r
$ # Sometimes, detaching the session first is needed:
$ screen -rd SESSION_PID

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).

Now, let's setup the Slackware installer chroot:

$ mkdir -p ~/slackware-chroot
$ cd ~/slackware-chroot
$ wget https://slackware.osuosl.org/slackware64-14.2/isolinux/initrd.img
$ gunzip -cd initrd.img | cpio -dvim
$ mount --bind /proc proc
$ mount --bind /sys sys
$ mount --bind /dev dev
$ mount --bind /dev/pts dev/pts
$ mount --bind /run run
$ touch etc/resolv.conf
$ mount --bind /etc/resolv.conf etc/resolv.conf

And run the chroot:

$ chroot ~/slackware-chroot /bin/bash --login
$ cd
Mounting /etc/resolv.conf provides DNS to the chroot.

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:

$ parted /dev/sda mklabel msdos
$ # Start at 1 MiB in the hope of a correct alignment:
$ parted -a optimal /dev/sda mkpart primary 1MiB 129MiB
$ # Set bootable flag:
$ parted /dev/sda set 1 boot on

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

Let the kernel know about the partition changes:

$ partprobe

Let's verify the result:

$ parted /dev/sda print
Model: ATA SAMSUNG MZ7LN256 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  135MB  134MB  primary  ext4         boot
 2      135MB   256GB  256GB  primary               lvm

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:

$ # Exit from Slackware chroot:
$ exit
$ mkdir -p ~/slackware-chroot/packages
$ cd ~/slackware-chroot/packages
$ # Download only: a, ap, d, l, n packages series (I don't need GUI apps),
$ # pay !attention! to the "." at the end of command line:
$ rsync -vaz rsync://rsync.osuosl.org/slackware/slackware64-14.2/slackware64/{a,ap,d,l,n} .
$ wget https://slackware.osuosl.org/slackware64-14.2/slackware64/CHECKSUMS.md5
$ # Verify the checksums of the downloaded packages:
$ grep -P "\./(a|ap|d|l|n)/" CHECKSUMS.md5 | md5sum -c --quiet
$ mkdir -p ~/slackware-chroot/patches
$ cd ~/slackware-chroot/patches
$ Download patches, pay !attention! to the "." at the end of command line:
$ rsync -vaz rsync://rsync.osuosl.org/slackware/slackware64-14.2/patches/packages .
$ wget https://slackware.osuosl.org/slackware64-14.2/patches/CHECKSUMS.md5
$ # Verify the checksums of the downloaded patches:
$ grep -P "\./packages" CHECKSUMS.md5 | md5sum -c --quiet
$ # Return to Slackware chroot:
$ chroot ~/slackware-chroot /bin/bash --login
$ cd
$ # Remember to update TERM as described earlier:
$ export TERM=screen

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:

$ cd /mnt
$ mount --bind /run run
$ mount --bind /dev/pts dev/pts
$ # Only needed if you downloaded the patches and want to apply them:
$ mkdir run/patches
$ mount --bind /patches/packages run/patches
$ # Enter Slackware Chroot (tm):
$ chroot /mnt /bin/bash --login
$ cd
$ # Remember to update TERM as described earlier:
$ export TERM=screen

10. Applying patches

The following set of commands will apply all the available patches and let you know of any .new files to deal with:

$ find /run/patches -name \*.txz -exec upgradepkg {} \;
$ find /etc -name \*.new

11. Bootloader (syslinux)

The following set of commands will install the syslinux bootloader:

$ extlinux --install /boot
$ dd count=1 bs=440 conv=notrunc if=/usr/share/syslinux/mbr.bin of=/dev/sda

Then, create the syslinux config file:

$ cat << EOF > /boot/syslinux.cfg
PROMPT  0
TIMEOUT 0
DEFAULT vmlinuz-generic
SERIAL  1 9600

LABEL vmlinuz-generic
  KERNEL vmlinuz-generic
  APPEND console=ttyS1,9600 printk.time=0 quiet ipv6.disable=1 ro
  INITRD initrd-generic.gz
EOF

This configuration will enable the messages to appear on the serial console. I also specify some kernel parameters (printk.time=0 quiet) 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).

12. Initial RAM disk (initrd)

Create the initrd config file:

$ cat << EOF > /etc/mkinitrd.conf
# mkinitrd.conf
# See "man mkinitrd.conf" for details on the syntax of this file
#
#SOURCE_TREE="/boot/initrd-tree"
#CLEAR_TREE="0"
OUTPUT_IMAGE="/boot/initrd-generic.gz"
KERNEL_VERSION="$( readlink /boot/vmlinuz-generic | rev | cut -f1 -d- | rev )"
#KEYMAP="us"
MODULE_LIST="ext4"
#LUKSDEV="/dev/sda2"
#LUKSKEY="LABEL=TRAVELSTICK:/keys/alienbob.luks"
ROOTDEV="/dev/vg0/rootfs"
ROOTFS="ext4"
#RESUMEDEV="/dev/sda2"
#RAID="0"
LVM="1"
#UDEV="1"
#MODCONF="0"
#MICROCODE_ARCH="/boot/intel-ucode.cpio"
WAIT="0"
EOF

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:

$ ls -l /boot/vmlinuz-generic
lrwxrwxrwx 1 root root 22 Dec 13 00:44 /boot/vmlinuz-generic -> vmlinuz-generic-4.4.38

So the following code:

KERNEL_VERSION="$( readlink /boot/vmlinuz-generic | rev | cut -f1 -d- | rev )"

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:

#c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux

and the following lines in /etc/securetty:

#tty1
#tty2
#tty3
#tty4
#tty5
#tty6

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

A. Setting up LVM2 disk management

B. SSH server configuration (before rebooting)

 howtos:slackware_admin:install_slackware_on_a_online.net_dedibox_baremetal_server ()