Alien Pastures

My thoughts on Slackware, life and everything

Levi

Animals enrich our life. Caring for pets makes you a better person. Letting your kids grow up together with animals in/around the house helps them learn the value of care and compassion.

We’ve had cats for almost 30 years now. The original sisterhood – two Holy Birman sisters – passed away ten and twelve years ago, and we adopted two Holy Birman half-brothers soon after, along with all their neuroses and traumas accumulated while being with their first family.
They were already more than eight years old when we took them into our care, and we knew that their time with us might not be that extensive. Still, we embraced them, they fully became part of our little circle and they in turn accepted us as their new humans.

Eventually old age takes its toll and today we had to euthanize Levi. He was deaf, demented, unable to care for and groom himself any longer, and his health had been deteriorating rapidly those last few months.

Levi was a beautiful cat, with a character made of gold. Never raised a claw against us, protesting only with his voice.
The gentle giant (he was almost 6 kilograms in his prime, almost twice the size of the females we had before) – he is no more. And I will miss him.

RFC: How to build my Wine package

I have a question for you – hence the “Request For Comment” in this post’s title.

I have been compiling a Slackware package for the Wine emulator for a long time now. The 64bit wine package contains both the 64bit and the 32bit Wine binaries and libraries.  It therefore also requires that you made your 64bit Slackware into a multilib system.

For a while now, Wine can be built in another way than I have been doing it traditionally. The “WoW64” build aka “Windows on Windows64” allows you to run 32bit Windows binaries on a pure 64bit Slackware Linux OS, no multilib required.
Caveats of a switch to a WoW64 build of Wine for Slackware:

  • The WoW64 build does not support 16bit Windows binaries.
  • You may have to re-create your 32bit Wine prefixes.
    Meaning, the Windows programs which you already have installed on your computer have been written to what’s called a “Wine prefix”, basically a subdirectory in your homedirectory (the default location is ~/.wine/).
    Usually you would not bother with the concept of the Wine prefix, but it allows you to isolate various Windows programs from each other. Suppose you need to install additional Windows libraries via tools like winetricks (the same script is called ‘protontricks‘ if you use Valve’s Proton instead of Wine). but the DLL requirements are conflicting between Windows programs. Then you install each program into its own Wine prefix.
    Bottomline: it may cost you some one-time work to get your programs going again.
  • There’s some reports about performance regressions in Wine 9.x under WoW64 for 32bit Windows programs that invoke OpenGL calls directly. I can not confirm that this has been addressed in Wine 10.x
  • Valve’s Steam gaming platform still requires multilib on your computer.

Therefore I would like to hear your opinion about whether or not to switch from traditional multilib Wine to the new WoW64 Wine.
With “you” I mean actual users of my Wine packages. I am not interested in random replies.

Let me know below!
Eric

Migrating my infrastructure

Roughly the last 12 months have been really hard on my server infrastructure – the servers that I rent and which host sites like slackware.nl, docs.slackware.com, download.liveslak.org, git.slackware.nl and several more.
An un-ending DDoS attack mostly by IP addresses from Chinese origin that keep requesting to download Slackware ISO files, many per second, effectively saturating bandwidth. Combine that with a massive onslaught of AI bots that roam the Internet scraping web content to feed to their LLM models. I have been mitigating these attacks and annoyances using web access control (because blocking all of China on IP level probably is exactly what the Chinese government is trying to achieve here: making sure that Chinese folks lose access to free and open source software).  Eventually these were also killing the Apache httpd daemon because that is where the access control is happening.
I am sure you’ve experienced that: when downloading an ISO from slackware.nl or running a “slackpkg upgrade-all” with slackware.nl as the package mirror, connections are aborted randomly.

So I had to make a decision: to deal with this in some way and improve the user experience for the average Slacker.

I have begun migrating my services away from the single physical host (and its hot standby) which has been running all these services sofar. They are being spread onto multiple (also more performant) new hosts.

Completed so far:

In progress; migrating slackware.nl, download.liveslak.org, git.slackware.nl, git.liveslak.org to a third server. Basically this affects all the mirror data that users want to download.
This part is actually more complex  and time-consuming due to the use of MSQL databases that need to be migrated as well (slakfinder for instance), multiple cron jobs to keep data in sync and backed-up and just a lot of data to shuffle around.

I aim to actually switch the various domains and hostnames to their new IP addresses somewhere in the next week. Expect a (hopefully) short downtime for the services mentioned above. If you get “file not found” errors or web sites go missing, just be patient and wait half an hour. If things take a concerning turn, leave your comments below this article and point me to the things that broke without me seeing it.

I hope to have informed you properly and timely 🙂

Cheers Eric

LibreWolf is now in my Slackware repository

Resulting from a request in one of my other blog pages, I have added a Slackware (15.0 and -current, 32bit as well as 64bit) package for LibreWolf.

The LibreWolf version number “137.0.21” is a combination of the version of Firefox on which the release is based, and the release iteration of the LibreWolf developer community.

LibreWolf is a custom and independent fork of the Mozilla Firefox browser, with the primary goals of privacy, security and user freedom.

The LibreWolf browser implements sane defaults for increased protection against tracking and fingerprinting techniques, and adds security improvements compared to its Firefox upstream codebase. All telemetry, data collection and other annoyances that come with the Firefox browser have been disabled or removed altogether.
By default, DRM is disabled as well because Digital Rights Management is considered restrictive towards consumers of digital media. You can however enable DRM in the browser settings if you want to watch DRM-protected video content for instance.

One thing to be aware of if you start using LibreWolf is that by default, your cookies and browsing history are deleted every time you close the browser. This behavior can be disabled in the browser settings.

Firefox Sync is disabled by default in Librewolf – again for the sake of protecting your privacy, but this too can be enabled in the browser’s settings.

LibreWolf is on par with other browsers like Brave and Tor Browser when it comes to the level of privacy protection they offer to you, the user. Another comparison: Brave browser is based on Chromium whereas Tor Browser, like LibreWolf, is a fork of Firefox.

I hope that this additional choice of browser in Slackware offers some benefit to you. Note that my package contains natively compiled Slackware binaries. There’s also a LibreWolf entry on SlackBuilds.org but that one merely re-packages a binary AppImage, not specifically built on (or for) Slackware.

Let me know if I missed some feature or functionality when configuring and building the source code. You can find the packages in my repository or any of its mirrors:

Enjoy! Eric

How I switched us.slackware.nl from lilo to grub

Today I finally switched my US server from lilo to grub as its bootloader.

The reason for doing it now, is that I usually do not have a remote IP console (KVM) to that physical server which is located in a US datacenter whereas I live in Europe. This server’s storage is configured as software RAID1 and has been running for years on a Slackware huge kernel, since I was unable to make a generic kernel plus initrd work. That was many years ago.
Now this server runs Slackware-current and the recent updates to Slackware-current include automatic recreation of an initrd, followed by an update of the Grub configuration when installing a new kernel. Essentially, when you have configured Grub to boot your machine, you won’t have to re-install the bootloader until the actual grub package is upgraded to a new version.

I wanted this switch from lilo to grub to ease future upgrades. But had to wait until the server owner was able to connect a KVM and gave me access. The reason for being hesitant to just install grub and reboot are obvious: what if the server won’t come up after boot, for whatever reason? I won’t be able to fix that remotely without access to the console and maybe the BIOS.

I did my research on installing Grub to a software RAID and in the course of that, discovered that Linux does not even read the file “/etc/mdadm.conf” anymore, because the RAID metadata is written to the disks themselves and mdadm extracts it on the fly. Anyway, I also learned that there’s a peculiarity that you need to take into account when using Grub to boot off a software RAID: you need to install Grub to both of the hard drives that together form the software RAID1. I thought, well I can do that!

Then I scribbeled down some possible iterations of the “grub-install” command that I would try until one actually worked. Why that doubt about a successful outcome? Obviously because I was bitten before! I have switched a Linode server from lilo to grub last year and the grub-install command crapped out with:

grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists

What I eventually needed to do was add “–force” to the grub-install command because apparently Grub works fine with blocklists despite the error. The command eventually became:

# grub-install --recheck /dev/sda --force

… and the Linode rebooted just fine into Grub. Goes to say, Grub is at least as finicky as lilo.

Of course, when you anticipate bad things to happen, you’re jinxed and bad things will happen.
When I was ready to start the switch from lilo to grub, had a KVM connected, installed the latest kernel-generic and let that generate an initrd.img and write a Grub configuration, I proceeded with:

# grub-install --recheck /dev/sda

What I did not anticipate was the resulting error:

Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won’t be possible.
grub-install: error: embedding is not possible, but this is required for RAID and LVM install.

I had to search for that warning and the error to find out what was happening. Searching for the error message (last line) was not returning much useful information but when searching for the warning, I found the GRUB article on the Arch Linux Wiki (Arch to the rescue once again): GRUB#GUID_Partition_Table_(GPT)_specific_instructions

It is a really informative and instructive article! Basically, my disks are formatted as GPT and not equipped with a MBR. Grub’s requirements are vastly different in those two cases:

  • When installing to a MBR disk, it squeezes the ‘core.img’ code in the post-MBR gap, between byte number 512 and the start of the first partition. Now it also makes sense why disk partitioning utilities start the first partition at sector 2048 which leaves almost 1 MB for the Grub bootloader.
  • When installing to a GPT disk, Grub wants to install its ‘core.img’ to a separate “BIOS Boot Partition” (partition number ‘EF02’)

Oops… my disk was already partitioned, not leaving any space and was already running as ‘us.slackware.nl’ for years! I could not simply erase the disks and start from scratch.
Luckily the Arch Wiki article pointed out that this BIOS Boot partition can still be created, in the space before the first partition.  Modern disk partition tools, as said earlier, create the first partition at sector 2048. The trick is to use gdisk (because this is a GPT disk) and prompt it to create a new partition. Gdisk will tell you that it can create one that starts at sector 34 and will end at sector 2047. Perfect for our needs.
So, I created that partition and assigned partition type ‘EF02’ to it (equivalent to GUID ‘21686148-6449-6E6F-744E-656564454649’ and skipped creating a filesystem on it – not needed.

It turns out that this partition can be in any position order as long as it is on the first 2 TiB of the disk. In my case, it became partition number ‘4’ even though it’s physically located at the start of the disk.

After creating the partition, I re-ran the grub-install commands:

# grub-install --recheck /dev/sda
# grub-install --recheck /dev/sdb

There were no errors, I double-checked my KVM access and rebooted. The server came back up without a hickup.

I hope this write-up will help someone somewhere in the future.
Cheers, Eric

« Older posts

© 2025 Alien Pastures

Theme by Anders NorenUp ↑