This is mostly a followup to my earlier post on testing Slackware 14.2. Since then, I have spent a little time using the installed slackware. So here are some of my notes.
In my earlier post, I noted that slackware does not use repos in the way that many distros do. I got back a comment, informing me that the Slackware user community is maintaining repos, and that there are package managers available to access those repos.
It’s always great to see this kind of involvement of the user community.
I had installed Slackware onto its own partition. However, I also have an encrypted LVM on that box, which I use with opensuse. So I wanted to be able to access that from Slackware. The encrypted LVM includes a home volume and a swap volume, and I wanted to mount those. Specifically, I wanted to mount the home volume to “/xhome” so that I could add symbolic links to it. And I wanted to use the swap volume as swap for slackware.
My first step was to add an entry to “/etc/crypttab”. I then rebooted. And, as expected, I was prompted for the LUKS encryption key.
After that reboot, I checked “/dev/mapper”. And it seemed that crypto had been setup, but the logical volumes had not been made available. I checked the documentation. That indicated that a configuration was required, but that manually accessing the LVM would automatically create the configuration for next time. So I used:
# vgscan # vgchange -a y
which made the volumes accessible.
I rebooted again. But the volumes were still not accessible.
The next step was to examine the startup script at “/etc/rc.d/rc.S”. And I quickly found the trouble. That script handles the LVM before it handles the crypto. So I move a few lines around to change the order. I then rebooted again. And, this time the LVM volumes were available after booting.
I’m not sure why they handled the script that way. It is possible to have a plain (unencrypted) LVM, and to encrypt volumes within that LVM. The order of commands in the original “rc.S” would have handled that. But that’s a rarer combination than the fully encrypted LVM. Before it went to “systemd”, the startup scripts for opensuse used to handle this by going through the crypto twice. I think they called it “early crypto” for the first pass and “delayed crypto” for the second pass. Instead of changing the order in “rc.S”, an alternative solution would have been to handle the crypto in an “initrd”.
After making sure that the encrypted LVM was reliably accessible after boot, I added a couple of lines to “/etc/fstab” to mount the home and swap volumes. That has been working well.
I noticed that the system had an IPv6 address, but no IPv4 address. It seemed that DHCP was not working as it should. As a workaround, I assigned a fixed IP address. And that worked. It still picked up an IPv6 address via router announcements.
I later looked at “/etc/dhcpcd.conf”. I uncommented the line “clientid” and commented out the line “duid”. After that change, DHCP began to work properly.
While experimenting with this problem, I briefly tried “NetworkManager”. That did not help. However, after reverting to a fixed IP, I noticed that NetworkManager was still running. This seemed wrong, though it did not cause any problems. It turns out that slackware enables NetworkManager by changing the permissions of “/etc/rc.d/rc.networkmanager” to make that script executable. However, it does not turn off the execute permissions when reverting to DHCP or a fixed IP. I manually changed those permissions, so that NetworkManager is not running.
Slackware is still defaulting to use “lilo” for booting. I originally depended on booting with the grub menu for opensuse. But I later ran “liloconfig” to setup lilo. I told it to boot from the root file system (“/etc/sda8”). I’m still using grub to chainload to lilo booting. And “lilo” is working as well as ever. I’ll note that grub2 is part of the software, so I could run “grub-install” if I wanted to switch to grub.
I later decided to try building an “initrd”. The script “mkinitrd_command_generator.sh” in the directory “/usr/share/mkinitrd” suggests a suitable command. I used that command. I then edited “lilo.conf” to add an entry for the generic kernel that used the “initrd”. I ran “lilo” to rebuild the boot setup. I tested it, and that is working well.
I also experimented with the instructions for opening the LUKS encrypted system within the “initrd”. This requires adding “-C device -L” to the “mkinitrd” command line. That works. And the encrypted LVM is opened earlier in the boot. However, the prompt for the encryption key is surrounded by so much screen clutter, that it is hard to see. So I reverted to allowing “/etc/rc.d/rc.S” to handle the encrypted LVM.
Back when I was regularly using Slackware, I would edit system scripts and configurations as needed. It turned out that Slackware is a very good system for learning and practicing some linux system administration. And that remains true today.