An iPad Mini adventure (what can a 2012 iPad still do?) ►
◄ Project Zebra: It is good to be a cynic, it is better to be a contented cat
This entry is part of my Project Zebra series covering migration to Linux for personal computing use.
Title reference: We Are Motörhead. From their new and experimental period, i.e. way back in 2000.
Discover seemed to have hung at 79% installing a batch of updates that included a kernel. I've noticed previously that kernel updates are a bit slower, and very occasionally kernels include regressions, particularly with hibernation on this hardware, so I wait to install them until I have chance to breathe and monitor them. Maybe I waited a bit too long in this case and that's part of the issue. Anyway, after an hour plus I killed Discover. Not something I'd recommend, generally, as if you do things like that you really need to make sure everything's left in a happy state so that you don't possibly render a system unable to boot or significantly broken when it does.
If you do, the first thing to consider is that the system will still think it's in the middle of updates, because it is. In order to remove the lock you may need to restart the daemon that's created it. Then you can try to get things done cleanly.
https://www.linuxuprising.com/2018/07/how-to-fix-could-not-get-lock.html
https://askubuntu.com/questions/1286005/how-can-i-solve-be-aware-that-removing-the-lock-file-is-not-a-solution-and-may
sudo service packagekit restart sudo dpkg --configure -a sudo apt install -f sudo apt-get update && sudo apt-get upgrade -y
That also took a very long while, but at least at the terminal it's more obvious what's happening. I'm developing a preference for updating via the terminal and just using Discover as a notifier of when stuff's available and what; I haven't ever reinstalled the base OS in over five years, although I've dealt with other machines and VMs in that time, and have very likely done things to it over that time that a clean install and average use might not be be affected by, so I'm not particularly blaming either of the distributions I've effectively had so far (Xubuntu, Kubuntu) or the parent distro or underlying tech.
The reason it was taking ages was the generation of initramfs images. It's the bit that starts the OS. And this was exacerbated by the number of previous kernels images were being generated for. By default the OS is supposed to keep the last 2 kernels, I think, but if kernels are installed manually this gets overridden? I have an unconfirmed and uninvestigated suspicion that kernel modules connected with VirtualBox or VMWare might be responsible for kernels getting marked as manually installed… we'll see if the issue recurs in future after what I've done here.
If you're here via Google, this is a particularly appropriate time for me to emphasise that I'm no expert when it comes to Linux, and we're doing things in the same sort of area as manually deleting things in Program Files, Windows folder or the registry in Windows. Just with a bit more experience of knowing what it's safe to mess around with.
https://askubuntu.com/questions/1325387/why-is-apt-get-autoremove-failing-to-remove-my-old-kernels
Looking at what was installed with "dpkg --list | grep linux-image" showed lots of previous kernels and "sudo apt-get --purge autoremove" clearly wasn't working. Running "apt-mark showmanual | grep linux-" all kernels were shown as having been manually installed, so re-running that with "> kernels.txt" it was possible to bulk mark them with "sudo apt-mark auto $(cat kernels.txt)" (noting as I did so that the search captures linux-sound-base and linux-libc-dev which aren't kernels) and once I'd purged them clear up /lib/modules/ for the ones no longer installed as well.
According to https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Initramfs-Zstd-Too-High Ubuntu has also overdone the compression level used with zstd to generate boot images so I've changed /etc/initramfs-tools/initramfs.conf to specify COMPRESS=gzip (lz4 isn't installed by default).
Memo to self: per tips here if apt-get is keeping back packages, "sudo apt-get install (list of packages)" can be used to apply its determined upgrade decisions and get additional required packages.
Minor other things for this entry...
A while ago dragging tabs broke in Chrome. Whilst it was still possible to use Ctrl+Shift+PgUp/PgDn to move tabs, that's indicative of really poor testing: https://bugs.chromium.org/p/chromium/issues/detail?id=1279532
Some praise for Plasma as a DE: https://opensource.com/article/22/2/why-i-love-linux-kde and https://pointieststick.com/2022/02/21/its-normal-and-it-works/
And it looks like some devs have started on trying to undo some of the damage to Xfce by making CSD a configurable option, and possibly even one that might become opt-in rather than vice versa: https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/47
After the 22.04 Ubuntu upgrade toward the end of April, assuming any of us are still alive, I'll be assessing whether it's safe to use the ntfs3 driver (instead of the ntfs-3g FUSE one) that was first introduced in the 5.15 kernel for my NTFS data partition and backup drives. Thus far comments about issues seem like they may relate to old file system problems that the FUSE driver either ignored or handled better. I don't use the NTFS formatted devices for Windows interoperability, although it's nice to have the option, more for historical reasons (it takes a long time to shift gigabytes around, reformat, etc on a load of drives) and as a less critical thing because I prefer filenames to be handled as case-insensitive in most situations and this is the case from the user point of view. This is possible with Ext4 with kernel support since 2019 including on a per-folder basis, and NTFS is actually case sensitive behind the scenes, but as I say I'm not in a hurry to convert existing storage.
So apart from watching other people as they navigate the general availability of ntfs3 in mainstream distros I'll be checking all partitions over with native Windows tools before considering mounting them with a relatively newly implemented driver, and making plans to do so again at intervals thereafter.
