Alien Pastures

My thoughts on Slackware, life and everything

Author: alienbob (Page 1 of 176)

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

February 27, 2025 / / 7 Comments

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

Taking over maintenance of slackpkg+

February 27, 2025 / / 28 Comments

Hi all,

At least temporarily I am going to take over the maintenance of slackpkg+, the extension to slackpkg which allows you to manage the installation and upgrade of Slackware packages from 3rd-party repositories.

Slackpkg+ is developed by Matteo Rossini (zerouno) but zerouno has not been able to contribute for the past couple of years. As a consequence, slackpkg+ has some issues when used in Slackware-current.
It’s impossible to communicate with him directly so I had some conversations with his family in the past which resulted in my maintenance-takeover of his other product, slakfinder.

And now I am welcoming pull requests and patches for my fork of slackpkg+. I want to have a release as quickly as possible, taking care of open issues.

Note: zerouno was working on an enhanced version of slackpkg+ which could communicate with slakfinder. The code for that slakfinder API has never been published even though you can find a ‘dev’ version of a slackpkg+ package which contains the calls to that API.
Therefore I am going to ignore the ‘devel’ or ‘test’ version of slackpkg+ which can be found in zerouno’s repository. I will accept patches and pull requests only for the ‘master’ branch.

When zerouno is able to resume his work again, I will gladly hand maintenance back over to him. I am not a software developer but I appreciate properly working tools.

Hope to see some suggestions soon.
Eric

Update 20250301:
I have released slackpkg+ 1.8.1 which addresses the most glaring issues due to the changes in Slackware-current over the past three years.
The repository at https://slackware.nl/slackpkgplus/ has been updated. I kept the https://slackware.nl/slackpkgplus15/ URL for backward compatibility.
See also https://github.com/alienbob/slackpkgplus/releases for the release notes and the git commits.

Update 20250304:
I released slackpkg+ 1.8.2 which includes all fixes and pull requests that were available. Please share any remaining bugs but also improvement proposals.

Let me remind you who started the war in Ukraine and how

February 19, 2025 /

I am going to spit 77 million people in the face here, and it needs to be done. I am raging. If you live in the USA and do not want to be confronted by my ‘leftist’ or ‘commie’ political views then unsubscribe from this blog and get the fuck out.
Listen carefully. Blatant lies are coming from the Oval office with the intention to destroy an ally.

The war in Ukraine did not start in 2022, and it was not started by Ukraine.

In February of 2014 Russia invaded Ukraine and annexed Crimea. NATO shied away from aiding Ukraine because of a justified fear of escalating the conflict. And in July of 2014, Russians shot down a commercial airplane over eastern Ukraine, killing hundreds of passengers. Hard work of a journalist collective provided the proof which held up in court.

In the years that followed, Russia kept arming and fueling the hatred of separatists in the eastern Ukraine. Why? Possibly because with the occupation of the Donbas, Russia now has control over 40% of Ukraine’s mineral riches. It’s always about the money, right? Or is the hunger for power stronger than greed?

In 2022 Russia invaded Ukraine from multiple fronts. Not because of what the traitor in the Oval office tells you – that  Ukraine started this war because of their request to join NATO – no, that request was sent to NATO in 2002, TWENTY years before Putin started his ‘special operation’. The invasion of Ukraine was ordered by a mad Russian dictator whose pride was hurt when the West kept ignoring him as a serious partner on the world stage.

Remember this account from what happened during those initial days?

This is not what happens if you pre-empt a strike because you fear your opponent. This is brutal sadism, trademark of Russian warfare where the state, not people, is the only thing that counts.

Those of you who put a traitor in the Oval office have made yourselves complicit, not just because you have enabled the autocracy or even dictatorship which is being created in the USA as we speak. But also complicit in the possible destruction of a European country: Ukraine. Your president with his delusions of grandeur will try again to grab Canada, Panama and Greenland and will leave Ukraine defenseless against Russia’s aggression. He does not care about you. He is a narcissist.
Next may be the start of an all-out war in Europe because Putin sees an opportunity. The USA now believes that Russia is not the enemy and Europe is its own enemy. And who the fuck cares about that in the USA?
I don’t understand you assholes who put this conman on a throne. All because you could not tolerate a black woman in the Oval office?
You don’t believe this? The orange guy keeps doing exactly what he has been telling you for years. There’s no reason to believe that he will change all of a sudden.

Fuck you all, maggots.

And indeed, I have disabled comments to this article. Suck it up.

Let’s Encrypt SSL certificate expiry warning emails

February 12, 2025 / / 5 Comments

If you use Let’s Encrypt to secure the traffic to your web server, mailserver or other situations where you need a SSL-encrypted data exchange, you are probably using the dehydrated script to manage those certificates to ensure that they will be renewed on time (Let’s Encrypt SSL certificates only have a 90-day lifespan).

Let’s Encrypt offers an automated service running on their end (you don’t have to do a thing) which sends you reminder emails when any of your LE SSL certificates is nearing its expiration date. You will get the first warning 30 days before that expiration.
For me that email has been a lifesaver on multiple occasions. I use their certificates on multiple servers and sometimes the client fails to renew a certificate for whatever reason. I do not monitor all my servers all of the time so it is possible that I miss these errors and run the risk of running a web service with an expired SSL certificate. Quite annoying for my users.

However, in a recent communique Let’s Encrypt have announced that they will end this free alerting service. They also suggest that you could switch to a 3rd-party free email service if you want to keep receiving email alerts for expiring certificates but I thought that this would be a good time to write a script that does the same thing and runs on my own server, no 3rd-party needed.

Dehydrated is part of Slackware since its 15.0 release. There are other tools that do a similar job, such as certbot or acme.sh. In this article I will focus on dehydrated but the script can easily be adapted to be used with one of these other ACME clients.

I wrote and uploaded a script called “check_letsencrypt_cert_expiry.sh” which you can schedule as a weekly cron job. It starts sending warning emails 15 days before the expiration date of a certificate, but that value is configurable in its configfile “check_letsencrypt_cert_expiry.conf” which looks like this:

# Configuration for the check_letsencrypt_cert_expiry script

# When to start sending warning emails;
# Allow this value to be set on the commandline:
WARNDAYS=${WARNDAYS:-“15″}

# From and to email addresses:
FROMEMAIL=”<sender_email_here>”
OWNEREMAIL=”<receiver_email_here>”

Make sure to write valid email addresses for the sender and receiver. If you do not use a valid sender domain, the receiving mailserver may block your email (GMail is really strict about this for instance).

There’s also an email template, see “check_letsencrypt_cert_expiry.tpl“, which will be used by the script to draft the message you will receive. Feel free to modify that text of course. I used most of the email text which is sent by Let’s Encrypt itself.

You can schedule this script to run once per week for instance. An example of a cron line can be found in the header of the script, it looks like this:

# Schedule this script via root’s cron to run once per week:
45 2 * * wed /usr/local/sbin/check_letsencrypt_cert_expiry.sh

If you don’t want to wait until the script is triggered to send you an email, you can force this trigger manually on the command-line. You might want to test whether you get the email at all (GMail sent my first email to SPAM for instance). Just define WARNDAYS with a value that is higher than the SSL cert lifespan in days, like this, as root:

# WARNDAYS=111 ./check_letsencrypt_cert_expiry.sh

You can find the script and accompanying files here: http://www.slackware.com/~alien/tools/le_expiry/ or any of my mirrors.

Have fun! Eric

The bit-rot of 32bit Linux

February 8, 2025 / / 19 Comments

Interest of software developers in the use of their product on 32bit Operating Systems has been declining for years. Build tests are only done on 64bit OS’es nowadays. For obvious reasons: there are not so many computers left in the Western world that only support 32bit software.
The thing is, there’s still a lot of old computer hardware in use outside of the wealthy West. Slackware is one of the few remaining Linux distros where the 32bit flavor is just as relevant as the 64bit variant. Yes, you may question the value of running really new software on really old hardware, but I think that is the users’ choice and if you happen to live in a country where a 2025 computer amounts to a year of salary, then I would want also those people to enjoy modern software and security patches.

I can’t recall how many patches have been needed to make source code compile on 32bit Slackware for instance, but in most cases there would be a way to patch the source or circumvent the error. Patrick Volkerding does this for the distro core and I do something similar for the packages in my own repository. And we sigh and complain to each other when compilations fail due to the restrictive 32bit address space, the inability to specify either “lib” or “lib64” as the LIBDIR, the use of architecture-specific assembly code and CPU instructions, etcetera.

But like with everything that’s left to rot in a corner, it’s getting increasingly difficult to keep 32bit Linux alive. I am running into huge time-sucks when packaging complex pieces of software. Specifically, I have not been able to compile 32bit Chromium since the 132 release despite all of my attempts. And now LibreOffice joins that list: I have been unable to compile the 25.2.0 release on 32bit Slackware 15 and -current.

So.
I will give up my attempts to create 32bit packages for future Chromium and LibreOffice releases. It has already taken way too much of the little time I have left after my regular day-time job. If I run into more of these programs that won’t allow me to compile 32bit binaries, those will quickly be added to that list as well.
I will ask again: if there are people among you (readers) who really need their 32bit programs, I need you to come up with the patches to make that work.

As long as there is a 32bit Slackware, I will keep maintaining my multilib repository of course: there’s nothing for me to actually compile there now that gcc and glibc packages in 64bit Slackware support multilib; the work is reduced to simple re-packaging. But once Patrick decides that 32bit Slackware goes the way of the dodo, then also multilib for Slackware will disappear. It would really be a shame though, but there’s simply no longer any kind of movement that is sufficiently influential to be able to sway software developers and keep 32bit Linux instances running to do their unit testing.

Looking at the Wine emulator, that one can be built so that it no longer needs 32bit libraries, but it would lose the capability to run 16bit Windows programs. I guess that’s where DOSbox would come in to save the day.

But be forewarned: the 32bit OS has become an endangered species.

Eric

« Older posts

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑