Reprinted with permission from Ryan Farmer.

More Work on Debian. Purging More Internationalization and Properly Setting Up Software Repositories.

Yesterday, and this morning, I did some more work de-bloating Debian.

In my last post on the subject, I mentioned the input method editors, why they’re useless to me (as a US English user who never enters non-Latin alphabet characters), and how much RAM some of them took (over 100 MB).

Well, it turned out there was more where that came from.

Debian installs every Firefox and LibreOffice language pack as well as LibreOffice Help Packs in every language, and a fourth input method editor that I missed the last time called fcitx. Two versions of it, apparently.

Proposing to Apt that it purge *fcitx* removed the fcitx and fcitx5 packages, a bunch of non-Latin Alphabet font packages that nothing seemed to depend on except for fcitx itself. So I did that and then an apt autoremove to be sure. Making sure along the way that it wasn’t proposing anything stupid, like removing KDE or X11, and it didn’t.

That done, I went into Synaptic Package Manager where I realized there was all this Firefox and LibreOffice internationalization junk.

So I ended up clearing out (purge) over 2 GB of useless (to me) help and language packs for that.

Then I went through all of the installed packages and purged out the task-(non English Language) stuff and the various oddities that I missed the last time around.

Roy Schestowitz says Internationalization is a “feature”. I suppose it is. Debian can’t tell who will use it, but most distributions at least have an installer that removes it from the computer after it copies over the OS image and knows where the user is and how they will use the computer. (Language, locale, etc.)

Is 2 GB a lot of data (on top of what I purged out the other day when I was trying to get input method editors to quit taking 100+ MB of system RAM)?

No, it’s not. Especially on compressed BtrFS. But it just “feels” bloated. I try to leave as much room as possible for MY stuff on my SSD, and this is just another “This feels rather clumsy and ham-fisted.” thing I’ve run into with Debian.

Naturally, I know what I’m doing with Synaptic Package Manager and Apt autoremove and am not going to do something that proposes ruining the system.

If you don’t want to tear things apart, then leave it alone or possibly look into setting up a base system and then layering it with KDE meta-packages.

Then I noticed that the installer didn’t do the best job of setting up my Apt repos.

It only set up “main”. Debian also has “contrib”, “non-free”, and “non-free-firmware”.

So I opened /etc/apt/sources.list in nano, as an administrator, and edited each line to add contrib non-free non-free-firmware after main on each line.

It ended up looking like this:

Technically, I could strip out the commented-out top line and the blank line underneath it and the commented paragraph at the bottom, if I wanted to, but they aren’t doing anything so meh.

Then I ran apt update and it told me there were updated CPU firmware files for AMD and Intel processors.

The Intel one turned out to be a patch for the Downfall vulnerability, and the Debian live installer left things configured so that my firmware packages would never get updates!

After the repositories were set up correctly, and the firmware was no longer being showed as “manually installed” because of lack of a repository, I proceeded to minimize the mess of packages that the Debian installer left marked as “manually installed”.

This was easy.

sudo apt-mark minimize-manual

This proposed a long list of packages that actually got automatically installed with something else. Fixed a few dozen “manual” marks. Didn’t get everything but cleaned up the list a lot.

Finally, I noticed a quirk in my system on reboots.

Sometimes it takes a very long time to reboot, seemingly for no reason. The system will hang for half a minute and the only message it spits out is that the watchdog failed to respond, which turns out to be a red herring.

It turned out that rebooting a PC is a complicated process and there’s several ways to do it, most of which are commented as specific problems with various models. So reboot.c in the Linux source has grown very, very long.

The Linux documentation suggested that there’s, errrm, multiple ways to handle this manually if you have to.

“21.1.5. Rebooting
reboot=b[ios] | t[riple] | k[bd] | a[cpi] | e[fi] [, [w]arm | [c]old]
bios
Use the CPU reboot vector for warm reset
warm
Don’t set the cold reboot flag
cold
Set the cold reboot flag
triple
Force a triple fault (init)
kbd
Use the keyboard controller. cold reset (default)
acpi
Use the ACPI RESET_REG in the FADT. If ACPI is not configured or the ACPI reset does not work, the reboot path attempts the reset using the keyboard controller.
efi
Use efi reset_system runtime service. If EFI is not configured or the EFI reset does not work, the reboot path attempts the reset using the keyboard controller.”

-Kernel documentation

My guess is it defaulted to UEFI (system firmware) interfaces and that didn’t respond, so after half a minute it gave up and started banging on the keyboard controller, which is how you rebooted a PC in the 1980s.

Amusingly, although the UEFI interface appears to be quite, quite broken on the Lenovo ThinkBook 15 ITL Gen2, the ACPI interface DOES work.

The Linux documentation for reboot=acpi and reboot=bios or reboot=uefi says that the fallback is always give up and bang on the keyboard controller.

This resets the CPU and does a cold reboot, and apparently this compatibility interface holdover from Legacy BIOS is the most “guaranteed-to-work” thing that UEFI firmware has 14 years after it became common.

Adding reboot=acpi to the kernel start line consistently seems to resolve the problem and make the machine reboot right away.

According to Debian’s Wiki, the done way to make this persistent after you know it fixes the problem is to add it to the /etc/grub/default file with a text editor (like nano) and then running the update-grub command as the administrative user (with sudo or as root).

In my case, the line GRUB_CMDLINE_LINUX_DEFAULT=”quiet” in /etc/default/grub ends up looking like this:

GRUB_CMDLINE_LINUX_DEFAULT=”reboot=acpi quiet”

Apparently, it’s just yet another “broken UEFI issue”.

Thanks Lenovo. It’s always so nice when these happen.

Another reason to buy a System76 laptop with Coreboot next time.

UEFI can’t even reliably reboot a computer 14 years later.

Yet another reason why UEFI is trash.

It’s not like I never installed any UEFI updates from Lenovo.

The first 13 updates got rolled into the UEFI flash I did before ditching Windows 10 because Linux was “ready” for this hardware.

It’s just more of this “Insyde BIOS” horseshit. Always such a pleasure.

Windows always seems to know exactly how to handle it because, basically, Microsoft and the BIOS vendors get together and “decide what the bugs will be” so Windows always knows what to do.

Is this illegal? Certainly. But good luck ever “proving” the collusion is going on, when it obviously is. They can make sure to shake hands in seedy backroom deals so that anything else you boot on the PC runs into some trouble.

Like that time I found the ACPI “bug” in a Foxconn G33 motherboard, but Windows had the “fix” in XP SP2, which shipped over 3 years prior to the first affected board. ⬆