When I read the release announcement and release notes for Slackware Linux 13.0, I thought it might be interesting to try to add it to MMS, my Dual Atom Multi-Boot Mini-Server. I knew that it wouldn’t be trivial, for two main reasons:
– I multi-boot openSolaris and several Linux distributions, and that only works using the GRUB from openSolaris, so I have to be careful not to replace that when I make a new installation.
– The last time I looked at Slackware Linux, they still used the LILO bootloader. So not only did I have to be careful not to overwrite the openSolaris GRUB, I would have to figure out how to boot Slackware from GRUB on my own.
The installation turned out to be easier than I expected in some ways, but more difficult in others.
First, be aware that Slackware is not a distribution for Linux beginners, and probably not even for casual users. It expects that you know quite a bit about Linux administration, and it doesn’t spend a lot of time or effort on hand-holding or “doing things for you”. The first good example of this comes up right away – there is no LiveCD, as most popular Linux distributions have these days, there is only an installation DVD. Along the same lines, there is no fancy-looking graphical installation process, like Ubiquity or Anaconda, there is just a rather old-fashioned looking ASCII/text installation process. That installation process is quite straightforward, though, and it gives you plenty of control over what will and will not be installed.
Near the end of the installation process you get into the section pertaining to LILO. First, it asks if you would like to create a USB stick to boot LILO. This is an excellent idea – it gives you the chance to dual-boot Windows and Linux without having to overwrite the Windows bootloader. There is a problem with that, however – not all computers are able to boot from USB sticks, and even those which can do not always automatically give the USB stick priority over the hard disk in the boot sequence. That can lead to considerable confusion, when installation finishes, the computer simply reboots to Windows, and the entire Linux installation seems to have “disappeared”. If this has happened to you, go into your computer BIOS setup and check to see if USB devices are bootable and are listed in the boot sequence ahead of the disk drive.
Once the USB boot stick is created (or not), the next question is about installing LILO. As I have to keep the openSolaris GRUB as my bootloader, I simply told it not to install LILO. Whew, that was a relief, I was afraid it might install LILO without asking, and then I would have had to go back and repair or reinstall the openSolaris GRUB.
After the installation completed, I rebooted with the USB stick plugged in, and it Slackware came right up. Hooray! Remove the USB stick and reboot, and the openSolaris GRUB comes up. Good stuff. This isn’t the way I want it for the long term, though – I want everything to be listed and bootable from GRUB. To do that, I had to learn about Slackware kernels and initrd.
In a nutshell, the problem is this. Slackware installs with two kernels – one called “huge”, which contains pretty much every device driver and module known to man, and one called “generic”, which contains only the absolute minimum and uses loadable modules for everything else that it needs. It boots by default from the huge kernel. If you want to use the generic kernel, you have to create an initrd.gz file which contains at least the modules required to ready your hard drive and complete the boot. I decided to take the obvious (easy) path of booting the huge kernel first, and once that was working figuring out how to boot the generic kernel.
There are two kernels of each type in Slackware, one for single-processor systems and one with multi-processor/mult-core/hyperthreading support (which has ‘smp’ in its name), and one with only single-processor support. The choice was easy on my Dual Atom system, but in fact they recommend running the SMP kernel even on single processor systems whenever possible. I have set up more than enough dual-boot systems to know the kernel boot syntax for GRUB, so I added the following to the openSolaris GRUB menu.lst file:
title Slackware Linux 13.0
root (hd0,8)
kernel /boot/vmlinuz-huge-smp-2.6.29.6-smp root=/dev/sda9 vga=794 ro
For the first trivial boot, that was all it required! Reboot the system, choose that line from the GRUB boot menu, and Slackware Linux came right up. I would prefer to specify the root partition by UUID, because my systems tend to be a bit variable in terms of partition names, but I found out the hard way that the Slackware Linux kernel doesn’t understand that. Ah well.
The next step was to figure out how to boot the generic kernel, which requires figuring out how to create the appropriate initrd.gz filesystem. The note in /boot/README.initrd is very good, and combined with reading the mkinitrd man page, I had a pretty good idea what I needed to do. Because I am using an ext3 partition for Slackware, I needed to create an initrd image with the modules to support that included. The README file is a bit misleading on this; you don’t have to list the dependent modules in the mkinitrd command, it will find and load those modules on its own. On the other hand, I don’t think the README puts nearly enough emphasis on the fact that you have to give the mkinitrd command the exact name of the kernel you are going to be booting, so that it can find the right modules – and if you are going to use the SMP kernel, you have to specify that in the name as well. So the command that I ended up using, after some experimentation, was this:
mkinitrd -c -k 2.6.29.6-smp -m ext3
Note that you do not have to specify the root filesystem type and location (-f and -r options) to the mkinitrd command . This produces a file called initrd.gz; for convenience and consistency, I renamed that to initrd-2.6.29.6-smp.gz and changed the GRUB boot specification to this:
title Slackware Linux 13.0
root (hd0,8)
kernel /boot/vmlinuz-generic-smp-2.6.29.6-smp root=/dev/sda9 vga=794 ro
initrd /boot/initrd-2.6.29.6-smp
I shutdown and rebooted one more time, and it came up running the generic kernel and everything works just fine.
Once I got the boot configuration working the way I wanted, I was still confronted with a significant problem – Slackware came up with a plain old text “login: ” prompt on the console. That gave me warm fuzzy feelings of nostalgia inside, because of all the years I have spent working on VT100 (or even LA-36) consoles, but it isn’t what I wanted my fancy Mini-Server to look like. Come to think of it, the installation process hadn’t even created a “normal user” login, there was only a “root” login. So the first thing I had to to was use “adduser” to create my own login name, then I logged in and confirmed that “startx” got me an Xfce desktop (I had selected Xfce during the installation process). After a bit more investigation I learned that the Slackware default runlevel is 3, which is multiuser with a text console; changing that to 4 starts an X11 seesion manager on the console. It surprised me by starting KDE, when I had already seen Xfce come up with “startx”, but when I looked at the rc.4 script, it looks like it only knows about Gnome (GDM), KDE (KDM) and plain old XDM, so I’m going to have to work on that a bit more.
So, there is plenty more to do, but at least I now have Slackware Linux loaded and working on MMS, along with openSolaris, CentOS, Debian, openSuSE, and Fedora 11 & 12. What fun!
jw 3/9/2009
