Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 322 other subscribers

My Favourites

Slackware

Calendar

September 2017
M T W T F S S
« Aug    
 123
45678910
11121314151617
18192021222324
252627282930  

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current

Meta

Build box: step 1, install Slackware

The new computer with its Ryzen CPU created some issues for me. To start with… I had not considered the possibility that a Ryzen CPU would not have an embedded GPU and so I did not order a graphics card. Bad idea!
I ended up ripping a GPU from one of my other computers (the only PCI-express card I could find) and plugging that into the new computer. That gave me a working video instead of a monitor that kept falling asleep.

Next came Slackware. When I booted the Slackware 14.2 installer, it did not give me a network connection. The Slackware Live Edition (based on slackware-current) worked properly on the other hand. But the graphics card I plugged into the computer did not work too well with the nouveau driver – whenever I started Chromium, it was inevitable that the computer would lock up after some time. Initially I blamed this on the computer hardware and feared that I bought a dead duck, but once I stopped running Chromium in the graphical desktop of Slackware Live, the system would remain operational. Since it is not going to be used as a desktop system and I will access it only remotely, that buggy nouveau driver is not a big issue and I could still install the binary Nvidia blob if needed.

So, the question became: I want to run a stable Slackware release on my new build server, but how am I going to install it? I was facing two major issues:

  1. The installer of Slackware 14.2 does not support NVMe boot devices (the new type of SSD hard drives with a M.2 PCI-express interface)
  2. The Slackware 14.2 installer lacks network capability on this new hardware, so I would have to perform a local install

I could spend a USB stick, putting the Slackware 14.2 DVD ISO on it, but then I still would have to patch the installer and I would not have a network connection after reboot. Considering the fact that slackware-current’s kernel works much better and NVMe support was added to the -current installer recently, I decided on a different approach.

I used a slackware-current based liveslak to setup the computer with Slackware 14.2 and then added a 4.9 kernel using the configfile for this kernel as found in slackware-current.

Steps taken:

  • Obtain a recent ISO of the Slackware Live Edition which is based on slackware-current (for instance, the 2.7 GB bleeding edge version or else the 700 MB XFCE based edition)
  • Write the ISO to a USB stick and boot liveslak. Now you have a proper graphical environment where you can query Google/DuckDuckGo and download anything you need.
  • We can not use the “setup2hd” of liveslak because that will install slackware-current and I want 14.2. So, download the smallest installer we can get:  slackware64-current-mini-install.iso which contains just the kernel and the installer (no packages) and is slightly more than 100 MB in size:
    # wget http://bear.alienbase.nl/mirrors/slackware/slackware64-current-iso/slackware64-current-mini-install.iso
  • Download my “extract_initramfs.sh” script which makes it easier to extract the initrd.gz file containing the installer:
    # wget http://www.slackware.com/~alien/tools/extract_initramfs.sh
  • Partition the SSD drive. The M.2 interface results in a character device /dev/nvme0 and a namespace block device /dev/nvme0n1. The first partition on this device will be called /dev/nvme0n1p1. The installer in Slackware 14.2 can not handle this new namespacing format. The one in -current can.
    This is a UEFI computer, and I want Slackware to use this. That requires a FAT partition which will be used as the EFI system partition. Slackware will mount this partition at /boot/efi. I created a 100 MB partition of type EF00 (EFI system) and formatted this with:
    # mkdosfs -F32 -s 2 -n “EFI” /dev/nvme0n1p1
    The remainder of the disk is partitioned with swap (yes even with 64 GB of RAM it is still a good idea to add some swap space), and additional partitions are created for /, /boot, /var, /tmp and /home .
  • Extract the installer from this mini ISO into a new directory “/root/initrd64-current“:
    # mount -o loop slackware64-current-mini-install.iso /mnt/tmp
    # sh extract_initramfs.sh /mnt/tmp/isolinux/initrd.img /root/initrd64-current
  • Get the installer running in the terminal while we are still in a liveslak graphical Desktop Environment:
    # mount -o bind /dev /root/initrd64-current/dev
    # mount -o bind /proc /root/initrd64-current/proc
    # mount -o bind /sys /root/initrd64-current/sys
    # chroot /root/initrd64-current
  • Inside this chroot-ed installer environment, run the ‘setup‘ command and proceed as usual with the installation of Slackware64 14.2 from a network server. The liveslak has already taken care of the network connectivity. I have NFS and HTTP servers at home, providing package trees but I pick NFS because that is much faster. I pointed the installer to a Slackware64-14.2 package source and did a full install (first time ever that I installed the Emacs package, go figure).
  • At the end of the installation, do note yet exit! Instead, run “chroot /mnt” to enter the freshly installed system. Configure slackpkg with a suitable mirror, then run:
    # slackpkg upgrade-all
    This will install all the latest patches including the latest kernel.
  • Finally, blacklist the kernel-generic and kernel-modules so that slackpkg will never replace our kernel accidentally.
  • Create an initrd (the /usr/share/mkinitrd/mkinitrd_command_generator.sh script will help you finding the correct parameters) and copy the generic kernel and this initrd to the EFI partition. This is the elilo.conf file I ended up with:
    # cat /boot/efi/EFI/Slackware/elilo.conf
    chooser=simple
    delay=50
    timeout=50
    default=slackware142
    image=vmlinuz
        label=huge142
        read-only
        append="root=/dev/nvme0n1p7 vga=normal ro"
    image=vmlinuz-generic-4.4.75
        label=slackware142
        initrd=initrd_4.4.75.gz
        read-only
        append="root=/dev/nvme0n1p7 vga=normal ro"
  • Now that the Slackware 14.2 installation is complete we have to ensure that we add a working kernel to it. I want to use the kernel as found in slackware-current because I know the 4.9.x series is good (liveslak proved that) and because slackware-current contains a kernel config that I can just re-use. Download the kernel source, and the kernel packaging scripts so that we can compile a kernel and its modules manually but still can wrap the results in package format and install those. Warning – when you try this at home, the actual kernel version may have moved beyond the “4.9.44” which I use in the example below. Just substitute the actual version instead:
    # CWD=$(pwd)
    # lftp -c “open http://slackware.osuosl.org/slackware64-current/source; mirror k”
    # cd k/
    # tar -C /usr/src -xf linux-4.9.44.tar.xz
    # cp config-x86_64/config-generic-4.9.44.x64 /usr/src/linux-4.9.44/.config
    Now we can compile that kernel (yes I compile kernels as root):
    # cd /usr/src/linux-4.9.44
    # make oldconfig
    # make -j 15 all
    # make install
    Now that the kernel is installed as /boot/bzimage and the modules as /lib/modules/4.9.44 we use the Slackware packaging scripts to create two packages:
    # cd $CWD/k/packaging-x86_64/kernel-generic
    # ./kernel-generic.SlackBuild
    # cd $CWD/k/packaging-x86_64/kernel-modules
    # ./kernel-modules.SlackBuild
    The two packages in /tmp can then be installed using “installpkg”. Do not use “upgradepkg” with your kernels – you will want to keep at least one previous kernel. The kernel-modules package will essentialy overwrite what’s in /lib/modules/4.9.44 but now with a package, we can control it through the package manager if needed. The kernel-generic package will have installed the new kernel as /boot/vmlinuz-generic-4.9.44. Copy that kernel to the EFI partition, and create a new initrd in the same location to match the kernel:
    # cp /boot/vmlinuz-generic-4.9.44 /boot/efi/EFI/Slackware/
    #  $(/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.9.44 -r -a “-o /boot/efi/EFI/Slackware/initrd_4.9.44.gz”)
    Add a section for the new kernel to elilo.conf. You can just copy the existing section for “label=slackware142” and change the version numbers. Make sure that the “default” keyword has this new label as its value. We want the new kernel to boot by default.
  • Exit the installed system’s chroot:
    # exit
  • Then exit the installer’s chroot:
    # exit
  • We are almost done. Unfortunately the eliloconfig of Slackware 14.2 did not add a Slackware entry to the computer’s EFI boot menu. So now that we are back in liveslak we need to fix this omission using the eliloconfig of slackware-current which is part of our liveslak:
    # eliloconfig /setup2hd /dev/nvme0n1p7
    This assumes the installed system is mounted under /setup2hd and the root partition is /dev/nvme0n1p7 . Change the parameters to match your situation. This time you will see that the Slackware entry is being created.
  • Reboot the system.
  • Have fun!

If I have omitted anything or steps are unclear, let me know. Now that I have Slackware on it, I can start thinking of how to add a virtualization solution. Either use my old scripts that wrap qemu and are very convenient and versatile, or go for qemu with libvirt and manage my virtual machines with virt-manager. The possibilities are endless. But first I need to get on with virtualizing my current server’s OS… its LAN services must stay operational but then in a VM on the new hardware.

Comments

Comment from Jen
Posted: August 21, 2017 at 23:00

There was some issue with the Ryzen cpu and Linux. Not sure if you’re one of the ones affected, but: https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response

So the segfaults you have might not be video card related.

Comment from alienbob
Posted: August 21, 2017 at 23:10

The segfaults happen during parallel compilation tasks where the CPU is stressed. I compiled the linux kernel twice in a row – on 15 of its 16 cores, and that took 7.5 minutes both times, without any issue or error.
The issue seems to affect older batches of Ryzen, perhaps I have one that’s new enough.

Comment from cwizardone
Posted: August 22, 2017 at 00:26

Just yesterday, Sunday, my time, I drove to the nearest large computer store and bought a Asus Prime B350-Plus motherboard, a Ryzen 5 1400 CPU and 16 gigs of RAM.
Put my “old” Nvidia GT-730 video card in it and attached my existing SSD which had both winXp and Slackware64-current on it.
Booted right up into Slackware. No fuss, no muss. It won’t boot winXp, but I expected that.
In honor of the new hardware, this morning I did a fresh install of Slackware64-current, added your multilib files and several others and it has been off to the races.
I re-partitioned the SSD, putting a 100 meg EFI partition on it, four gigs for a swap file (not sure that is really needed anymore) about a 50 gig boot/system directory and the rest
is /home.
So far, so good.
The actuall “fresh” install took less than twenty minutes. The rest of the time was installing and tweaking this and that.
As I said, so far, so good.
No surprises.
I’m looking for information on editing the elilo.conf file. I would like to see a graphic come up on the screen a la lilo.conf. That can wait.
🙂

Comment from Helios
Posted: August 22, 2017 at 08:31

For many years, when I installed slackware on a new computer, I had already slackware(64)-current installed and working on some other computer. I installed then on the new computer from a DVD built from the slackware(64)-current tree. I realize that probably in many cases it had been impossible to install from the official slackware DVDs.

But generally newcomers will know only the official distribution. Is not it a problem ?

Comment from alienbob
Posted: August 22, 2017 at 08:38

Hi Helios.
No, I do not think that is a problem. Newcomers to Slackware should work with the stable release and not try to mess with -current. If they own hardware which does not work with Slackware, then there’s the LQ forum for questions and answers. Also, I created liveslak so that you can easily test new hardware for compatibility with Slackware 14.2 and -current. Just boot the Live ISO and see what works (or not).

Comment from D.L.C. Burggraaff
Posted: August 22, 2017 at 11:31

9 out of 10 cases I just restore on the new computer a backup of the install on the old one.
There are some minor things to be taken care of — /etc/udev/rules.d/70-persistent-net.rules, /etc/fstab and /etc/hosts come to mind — but that is all.

Comment from Alexander
Posted: August 22, 2017 at 16:10

14.2 almost works with NVMe. The installer simply doesn’t search for a EFI partition on an NVMe disk. This can be fixed by a minor modification of the script /usr/lib/setup/SeTEFI in initrd.img inside usbboot.img. Details (obvious) are in this post: http://www.linuxquestions.org/questions/slackware-14/requests-for-current-20151216-a-4175561577/page60.html#post5538267

In this way I already installed 14.2 on 3 computers with NVMe SSDs.

Comment from BrianA_MN
Posted: August 22, 2017 at 16:39

Congrats Eric on the new hardware and also Thank you for this detailed writeup. I plan to print it out for my next hardware upgrade of both laptop and desktop. Cheers

Comment from cwizardone
Posted: August 23, 2017 at 10:44

The only problem I’ve had with the new Ryzen chip, so far, is
VirtualBox. The most recent version, doesn’t see the USB ports…. Well, I should say VB as host sees them, but the “guest” does not. Doesn’t matter switch way I set the preferences.
Perhaps, Oracle has a new version in the wings.

Pingback from Links 23/8/2017: Chrome OS For Work, GNOME 3.25.91 | Techrights
Posted: August 23, 2017 at 18:24

[…] Build box: step 1, install Slackware […]

Comment from cwizardone
Posted: August 23, 2017 at 18:37

Well, the problem with VirtualBox and USB ports is not the fault of the CPU or VirtualBox.
Turns out, “….all USB devices connected to the USB 2.0 and USB 3.0 ports are controlled by the xHCI controller.”
And, according to Intel, “…the Intel xHCI USB driver is not supported on Windows XP or Windows Vista,” and Xp is what is running as a VirtualBox guest.
Had I known that I would have shopped for a different motherboard….. OTOH, I wouldn’t be surprised if USB support is the same on all recent motherboards.

Comment from Slax-Dude
Posted: August 25, 2017 at 16:25

Hi Eric,

Congrats on the new server! (I’m so jealous!)

As for virtualization, I hope you go the libvirt route, as it is the most versatile.
I use a mix of my own scripts (that use libvirt) and virt-manager.
Using virt-manager for managing VMs on a remote host (via ssh connection) is so convenient!

You can always mod your scripts to wrap libvirt instead of qemu directly 🙂

Anyway, I’ll stay tuned to your adventures with the new server as they are guaranteed to produce interesting stuff for the Slackware community.
I’m specially looking forward to your jenkins project and how you’ll integrate it with virtualization to build Slackware packages on a “clean” environment.

Best wishes,
Slax-Dude

Comment from Janis
Posted: August 28, 2017 at 07:51

Hi!

What benefits brings separate partitions for /tmp and /var?

Comment from Nate Bargmann
Posted: September 1, 2017 at 14:51

As I understand it, some like to mount / as Read Only, but /tmp and /var hold temporary files, state data, and other data that changes during system up time so they need to be Read/Write.

My prefernce is to only have /home as a separate partition and leave / as rw. Probably a bit less secure but handy for my home systems.

I think if I were to do multiple partitions that I would use btrfs and use logical mounts. That way the file system can allocate the space to a given mount point as needed. This seems to eliminate the concern of whether /tmp or /var were made big enough or too big.

Write a comment