My thoughts on Slackware, life and everything

Category: Me (Page 6 of 27)

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.

New server arrived in the post

The hardware I ordered for the new build server arrived today – all components assembled and tested.

I am too tired to connect and boot the thing, so all I provide today is a pic of the package.

Then I have a lot of installation and configuration work to do the next couple of days… so I should hope that the downtime maintenance weekend at the office is going to be canceled.

New build server was ordered

OK, so I got frustrated too many times when waiting for packages that were compiling. My current build machine with its AMD ‘Athlon II X4 640’ CPU and 8 GB of RAM, is now 5 years old and obviously no longer quite fit for the tasks I need it to perform. Compiling Chromium for 64bit Slackware in a virtual machine took more than 24 hours last week (yes, for a single package). Basically, that convinced me to empty my stash of donated funds (thanks to all of you Slackware supporters) and order the most powerful midi tower I could buy for that money. What else is that money for, after all. Well, beer perhaps 🙂
Because the computer’s location will be the attic of my own house, its components (Seasonic PSU, Scythe CPU cooler, and the ‘be quiet Silent Base’ case itself) are chosen to minimize noise – it’s actually going to be sitting next to a bedroom wall.
The CPU I chose with the help of a friend, and after some consultation of my hardware store, is an AMD Ryzen 1700 at 3,0 GHz, along with 64GB of Corsair RAM (DDR4 at 3,0 GHz) but I am going to slightly overclock both. I added a 500GB Samsung 960 EVO SSD (NVMe) as well as a 4 TB Western Digital Red SATA disk.

With that machine I will be able to parallellize my build efforts and that means, I can give you more updates and still spend more time with my family. The whole hardware order costs slightly more than 1700 Euros which sounds like a lot (Robby pointed me to Ebay discard servers for a couple of 100 dollar) … while rackmount servers are cheap, you can not put them in your home because of the noise.
But it’s going to be worth it. And I will still have money left in my donations account to keep paying the rent for the ‘bear‘ server for at least another year. And then it’s rock bottom.

I will give more information when I actually get the hardware, install Slackware on it and create a virtual machine environment. I am not yet sure if I will keep using my own custom scripts to create ‘on-demand’ virtual machines or that I will switch to using virt-manager.
And I can finally also consider another “TODO” project that has been on the horizon for a long time: using Jenkins CI for ‘continuous build’ of my own (and Slackware’s) packages.
I will try to document as much of it as I can. I am sure that more people consider using virtualization to fence off processes, or create predictable (Slackware) OS environments using VM snapshots, or produce predictable builds. It’ll probably take months to get that point though… I am not in a hurry.

Again, thanks for all the donations during the past years that enabled me to do this purchase. You will hopefully benefit from it. Return on investment so-to-speak.

Eric

Poll: who needs 32bit packages for latest Plasma 5?

During the past week I have been spending time on getting the latest KDE Frameworks, Plasma and Applications built. The new Applications 16.12 was quite a bit of work due to the splitting of tarballs in many smaller ones. Also, the Slackware 14.2 and -current versions have now diverged sufficiently that the packages I compile on 14.2 are no longer guaranteed to work on -current, so that introduces additional work.

This effort took much longer than I am comfortable with. I do not have as much time available as I used to have due to “real life” – meaning my new job is quite a bit more demanding than my previous one.
This made it clear to me that I have to start making decisions about my Slackware activities, with more detail than what I said in the past along the lines of “updates may come less frequent”. It is obvious that I can not keep releasing a new set of ‘ktown‘ packages every month, for both 32bit and 64bit platforms, and for both Slackware 14.2 and -current. I have a few options:

  1. stop releasing 32bit packages for Plasma 5 (ktown repository)
  2. stop releasing Plasma 5 for Slackware 14.2 and start focusing on -current exclusively

I tend to lean into option (1) and therefore wrote this blog post. Who is using my Plasma5 (ktown) packages on a 32bit Slackware OS?

If there are users running a 32bit Slackware-current OS then this could mean a stop to new Plasma5 releases for Slackware 14.2. Updates to the graphical desktop does not have priority at this time in the development cycle of Slackware-current which means I will have to keep maintaining my ‘ktown’ repository for a while to come.

Bottomline: I will have to make one of the two above choices, and I will listen to you – the users of my packages – to help me make that decision.

Brabantse worstenbroodjes

Time for a new post about baking, a detour from the incessant talk about Slackware Linux and Open Source Software.

Today’s topic is “brabantse worstenbroodjes” aka dutch sausage rolls. I wrote about these worstenbroodjes on Google+ (in the Art of Baking community of G+) after I had baked a first batch early last year. Recently I revisited and revised the recipe when I made a new batch to “celebrate” my last day as an IBM employee. My colleagues loved them.
The most important revision is my spice mix, which is more complex than the simple initial attempt, which contained way too much salt. I also opted for pure beef instead of a pork/beef mix. These worstenbroodjes are halal / kosher.

Some background:

In March 2016, the brabantse worstenbroodjes were added by Unesco to the natoinal list of “immaterieel cultureel erfgoed”. In english this is called the Intangible Cultural Heritage List. That sounds big, but actually it is simply a new way to preserve old traditions for future generations. In this case, a tradition originating in the southern region of the Netherlands: Noord-Brabant is a province of the Netherlands. Sausage rolls were initially created as a means to conserve meat by rolling the meat into bread dough and cooking it. Traditionally the brabantse worstenbroodjes were consumed only at special events with a religious context: at the end of Carnival, late tuesday night as a means to compensate for all the alcohol (further south people would consume herring on rye bread instead); and when coming home from night mass on Christmas Eve. Essential part of the tradition is that worstenbroodjes are meant to be shared with friends and family as part of a get-together event.

IMAG0744 worstenbroodjes

On to the recipe:

The brabantse worstenbroodjes are made from yeasted bread dough, which is wrapped around a sausage of beef & pork mincemeat spiced with salt, pepper, nutmeg, mustard (and other spices if you like, but the nutmeg is essential).

My recipe will create 30 worstenbroodjes consisting of 35 grams dough and 35 grams meat.

Dough:

  • 600 gr flour
  • 11 gr salt
  • 22 gr sugar
  • 170 gr water (lukewarm)
  • 170 gr milk (lukewarm)
  • 11 gr fast-action yeast
  • 45 gr butter (softened)

Sausages:

  • 1000 gr mincemeat (either beef or else a mix of beef and pork)
  • 1 egg
  • 25 gr spice mix
  • 25 gr breadcrumb

Spice mix (together will be ~ 25 gr):

  • 1 tsp salt
  • 2 tsp nutmeg
  • 2 tsp white pepper
  • 1 tsp paprika powder
  • 1 tsp onion powder
  • 1 tsp ginger powder
  • 1 tsp coriander powder
  • 1 tsp garlic powder

Execution:

  • Mix flour, sugar and yeast together in a bowl.
  • Combine the water and the milk and heat until lukewarm. Melt the butter and mix the salt and molten butter through the lukewarm fluid.
  • Pour the wet ingredients into the dry ingredients. Mix together during circa 2 minutes with a spoon.
  • Leave this mix to rest for 15 minutes. The process is called autolyse – it ensures that the flour will absorb all the moisture.
  • Dump the dough onto your work area (which you dusted with a bit of four first) and knead for 6 to 10 minutes until you have a supple dough.
  • Place the ball of dough in a bowl and cover the bowl with some plastic wrap or a moist towel.
  • Next comes the “bulk rise” which is the period in which the yeast consumes part of the sugars in the flour which causes the dough rise to roughly twice the original volume.
    • Leave the covered bowl at room temperature for about an hour, or until the volume of the dough has doubled.
    • If you are adventurous and want a deeper, more complex flavor in your dough, don’t leave the dough at room temperature but instead, immediately place the bowl in the refrigerator for at least 10 to 12 hours, but mot more than 5 days. On the day you want to bake the worstenbroodjes you should take the dough out of the fridge 2 hours in advance to give it time to warm up to room temperature,
  • Divide the dough into 30 pieces of 35 grams each. Roll the pieces into small balls (see video below if you do not know how to do this). Cover the dough balls with plastic wrap or a moist towel.
  • While the balls are resting, mix the mincemeat with the egg and spices. Add as much breadcrumb as you need to create a firm meat mixture.
  • Divide the meat into pieces of 35 grams and roll them into sausages using the flat of your hand. The first video below shows you how. Store the sausages in the refrigerator while you work on the next step.
  • Use a small rolling pin to flatten the individual dough balls. Roll them into ovals that are roughly the same length as your sausages.
  • Combine dough and meat into a sausage roll: take a dough oval, place a sausage on top. Fold the ends of the oval over the ends of the sausage by stretching the dough a little. Grab a side of the oval and stretch it over the sausage.Take the other side and pinch the seam with two fingers. Roll the sausage roll under your two flattened hands to make the seam disappear and seal the meat into the dough completely.
  • Place the rolls on a baking tray which has been covered with a baking sheet (paper or silicone). Cover with plastic wrap and leave to rise at room temperature, for at least 45 minutes. This is an essential step. It will create air inside the bread and help prevent tearing of the sides of the bread roll while you are baking it.
  • Pre-heat the oven to 190 degrees centigrade (conventional oven).
  • Optionally if you want a nice shine on top of the worstenbroodjes, combine an egg with a tablespoon of cream and brush the bread rolls with the egg mix. I skip this step.
  • Bake the worstenbroodjes at 190 centigrade during 25 to 30 minutes until they are a golden brown.

When you want to add some extra complexity to the flavor, you should try making these rolls with a dough that has been developing in the fridge for at least 48 hours.

This is an ideal snack which should be eaten straight out of the oven but still tastes great the next day when cold. You can freeze them after baking if you want. Heat them up again when it’s time to eat them, straight from the fteezer into a pre-heated oven during 12 minutes at 180 degrees centigrade.

Video references:

Enjoy this recipe!

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders NorenUp ↑