Having bought an Asus ROG Zephyrus G14 (1) for the sole purpose of playing Baldur's Gate 3 (2), there was no question that it would have a Linux distro installed, and that this would be a gaming-oriented distro. The Arch-based Garuda Dr460nized (3) ("dragonized") was a first choice, but there was enough room for a second partition, so why not try something new? Consulting DistroWatch.com (4) brought up two candidates: MakuluLinux (5) and Regata OS (6), version 23: Honeycomb. I downloaded the ISO files of all three and put them on a multi-boot YUMI boot stick (7), so I could run live sessions (the distro is loaded into RAM, and runs without being installed) for each before installing them.
Regata OS, a Brazilian distro based on my former favourite, openSUSE (replaced, after it was bought by an American company, by Linux Mint (8)) was said to rival Linux Mint for ease of use, and to support hybrid graphics, ie. it helps applications switch between the onboard and dedicated graphics card depending on their graphics requirements. MakuluLinux, based on Debian and Ubuntu, supports Snaps and Flathub, looks smooth, and has an interface like an old-fashioned telephone dial (or a PS5, apparently; I think it's supposed to mimic a game console) but was said to be unreliable as it combines software from unstable repository branches. I don't recall whether I had problems with running it, installing it or simply getting its ISO to download, but it didn't play well with my laptop, so I gave up on it. Not that Regata OS fared much better; booting its ISO off the YUMI boot stick worked, installing it did not. It booted, but, after letting me make a user account and reboot, flashed an error message followed by a black screen.
Meanwhile, Garuda Dr460nized ran like a charm, although, being Arch-based, it demanded frequent updates.
After one of Garuda’s updates, which went wacky because servers could not be found, files could not be downloaded and the (btrfs) partition ran out of space due to old forgotten system snapshots, which had to be deleted mid-update, Garuda wouldn’t boot. Its grub (ie. GRUB, GRand Unified Bootloader) menu still worked, but it had erased its own entry from said menu. I now had two non-functional Linux installations!
This seemed a good time to finally get Regata OS to work by reinstalling it off the YUMI stick, which would also reinstall grub and recreate the boot menu. There are two ways to boot from the stick: press F2 after turning on the laptop to open the UEFI screen, or wait for the grub menu to appear and pick the lowest menu item, "UEFI Firmware settings", which reboots to the UEFI screen; in either case, press F8 for the boot menu, and the stick will be listed as a boot option. Booting it displays a list of ISOs, including Regata's. After waiting for Quite Some Time until Regata OS Live is up and running, there's a handy-dandy Install shortcut on the Desktop.
After reinstallation, the two Garuda boot menu entries - normal boot, and advanced options - reappeared in this menu, but both started MemTest (memtest86, the standard RAM testing program), because Garuda’s boot directory no longer contained a Linux kernel, only memtest86. After a few booting attempts, I consoled myself that the RAM, at least, was in tip-top condition.
Regata OS still didn’t work, but this time I took note where it failed: a cursor and login screen appeared, then darkened and displayed the Regata OS logo; then, after ten or so seconds, the laptop shut down. A bit of websurfing (on a different laptop, it’s always good to have a spare) supported what I thought: graphics driver problems, specifically Nvidia drivers.
Since fixing the driver problem seemed simpler than providing Garuda with new system files, I opted to do that first.
The Reddit post Black screen shutdown problem (9) contained simple instructions to update the Nvidia grapics drivers:
sudo zypper ref; sudo zypper up
sudo zypper in nvidia-driver-extra
Of course, if it were that simple, this how-i would not have been written. I ran into three consecutive problems.
First: my user account had been wiped and not re-created during the second, unfinished (because shutdown after reboot) install. So, having managed to Ctrl-Alt-F2 fast enough to open a console that filled the whole screen, I was greeted by a “localhost login” that would not accept any name or password I could come up with. It took some surfing on the spare laptop to find that the username and password required are “root” and “regata”.
Second: after logging in, I didn’t have the internet connection needed to let
zypper do its job. The site LinuxForDevices.com had a helpful tutorial:
How to connect to WiFi through the terminal command
line? (10) Here's how that went for me:
Testing for a network card:
iwconfig
Result: "wlan0" followed by data about the network card, including that it
was off.
Testing the network card's wifi reception:
nmcli radio wifi
Result: "disabled"
If not running, turning on wifi reception:
nmcli radio wifi on
Result: "enabled"
This will test if the above worked, I skipped that step:
nmcli dev status
Detect available wireless networks and list their SSIDs (basically, names),
including my router's, which I'll call MyOwnNetwork. (It keeps polling, and may
have to be stopped with Ctrl-C.)
nmcli dev wifi list
Connect to MyOwnNetwork. I needed to scribble down the numerical password of
the router first, which will be represented by zeros. Note the "sudo":
sudo nmcli dev wifi connect "MyOwnNetwork" password
"00000000000000000000"
How to disconnect from MyOwnNetwork afterwards:
nmcli con down "MyOwnNetwork"
On refreshing the repositories with sudo zypper ref, I noticed
many were missing; they pointed at openSUSE Leap 54 ("15.4"), and openSUSE had
moved on to Leap 55 ("15.5") since Regata OS 23 came out. As a result, a few
unimportant RPMs (RPM is the installfile format used by openSUSE) could not be
found, although I noted, in the list of software to update: zypper, Nvidia "G06"
drivers, and a kernel update to 6.6.11.
Third: the update was so huge that it filled the Regata OS system partition before it had finished downloading, and aborted itself.
To deal with the junk-filled partition, I booted Regata OS from the YUMI
stick again, and installed it a third time. This time I made a connection to the
internet before installing, although I don't know if that affected the outcome.
Regata OS gives four options for deciding where it will be installed, and I
always choose the fourth: manual partitioning. This presents me with a display
of all available partitions and disk space, where I can create and delete
partitions, but, most importantly, assign to these partitions three important
mount points: /boot/efi, /home (optional, but lets me
keep my data when reinstalling), and / (root, where the Linux
distro is installed). For each mount point I can specify whether to keep the
data or reformat the partition, and for /, I chose "Format".
After the installation, prompting a reboot to add the finishing touches, I wondered whether to reboot, risking a black screen, or try and somehow update the graphics drivers from the live session I was currently in. The grub boot menu has three options to boot Regata OS:
It occurred to me that I'd never tried these advanced options, which might have been a workaround for precisely such driver problems; sure enough, they worked. To be safe, I first tried the second advanced option, "recovery mode", which simply let me round off the installation by entering account name, password, keyboard, time zone etc. followed by another reboot. Feeling braver now, I chose the first advanced option, and, since Regata OS retained my network settings and reconnected after the reboot to check for updates, was greeted by the notification icon of Regata OS Update, alerting me to six updates, five of applications, including Firefox, and one "System updates", a drop-down entry showing the names of all system files to be updated.
First, from the applications menu, I opened "Settings/System Settings" and made the following changes: battery charges only to 80% (Garuda has the same option and just as with Garuda, it doesn't stick, I have to reset it after every reboot), there will be no sleeping, suspending or hibernating (bad for the SSD), internet does NOT automatically connect after boot, and backlit keyboard is turned on, because if the keys aren't lit, they look blank. Lastly, since huge application update files were what helped to break the first attempt at updating, I updated the five applications separately, noting that after I'd done so, Regata OS Update still displayed them as needing an update, but the "System updates" entry had disappeared.
Due to this distro's attempt at keeping it simple and not confusing the user with many choices, the complete update required a combination of three - four if I count Regata OS Support separately - programs to succeed, after which I had a fully working (all boot options succeeding) system using kernel 6.6.11.
To get those system updates done, now that Regata OS Update no longer displayed them, I started the YaST Software Manager, accessible from "System/YaST software manager", and refreshed the repositories. Then I tried to update the kernel, hoping this would solve the repository problem, by searching for "*kernel*" and marking the found files and their dependencies as "To be updated". This included "nvidia-driver-Go6-kmp-default" which was "protected", so updating that item failed, and the whole update was undone. I even installed "yast2-online-update-configuration" to set "YAST Online Update Configuration" to automatic; no luck.
So, going back to basics, I opened "System/Konsole" and typed at the prompt:
sudo zypper ref
and was told in many error messages that all the repository subdirectories
ending in "15.4/" were not found, and "Some of the repositories have not been
refreshed because of an error.", because duh, Leap 55. Oh well, attempting an
update with what I had:
sudo zypper up
which told me that 178 package upgrades would NOT be installed, 743 packages
(including nvidia drivers) would be upgraded, a branding package was going to
change architecture to noarch, 13 packages (including nvidia-compute-G06) would
change vendor from "obs://build.opensuse.org/home:regataos" to various
subdirectories in "obs://build.opensuse.org/", and 25 NEW packages would be
installed, none of them important for the graphics drivers.
As the failed YaST update had decreased diskspace with its downloaded installation files, and Regata OS Update still insisted I update the five applications that I'd just updated, I cancelled the zypper update and rebooted (using the advanced boot option, of course), hoping this would refresh Regata OS Update and wipe the downloaded installation files. That didn't happen, except suddenly Regata OS Update was offering System updates again, so I let it install those.
To prevent further updates failing from an overfilled partition again, I looked in the installed programs and support files in vain for an option to simply clear out downloaded install files, grumbling to myself: "If Linux Mint is simple, Regata OS is Teletubbies level simple." but Regata OS Support did have an option to "Update repositories", which started a YaST process (that I somehow hadn't gotten to work in the YaST Software Manager? Did it work this time because of the System updates in the paragraph above?) that actually updated some repos to 15.5. Progress!
The YaST Software Manager now had a whole list of updates to collectively install, but when I let it, it said: "The 15.5 repo for xf86-video-mach64 can't be found!" which again undid the whole install.
Back to basics for a second time: starting Konsole again, I used sudo
zypper ref which suddenly found each and every repository, letting me
know that the following repositories were now up to date:
This time, running sudo zypper up told me that only 112 packages
would NOT be upgraded, a whopping 2280 packages would be upgraded, 132
installed, 3 removed, 29 changed vendor, 3 changed architecture, and that a
reboot was required due to a kernel update. The download size would be almost
3GiB, but the increase in OS size would be only 687,3 MiB. Yay, but also oops,
would I run out of disk space again? The partition survived the update, and now
I had a system with the latest kernel, that I could boot normally. I didn't even
need to use sudo zypper in nvidia-driver-extra.
warning: /var/cache/zypp/packages/videoregataos/x86_64/nvidia-driver-extra-2023.09-lp155. 4.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 8868187b: NOKEY Failed to enable unit, unit nvidia-persistenced.service does not exist. warning: %post(nvidia-driver-extra-2023.09-lp155.4.1.x86_64) scriptlet failed, exit status 1but none impacted the shiny new upgrade. The installfiles under
/var/cache/zypp/ could be purged, I found, by using sudo
zypper clean, which won back about 2GB of disk space. I changed the
screen's scaling factor from 175% to 200%, installed my favourite games - via
the YaST Software Manager, not from the Appstore, which doesn't offer
Pipewalker (11), Dungeon Crawl (12)
or Luanti (13) - found out that Steam and Lutris still had
to be installed despite being in the menu, saw that the YaST Software Manager
allowed me to finally properly update "xf86-video-mach64", did some updates the
regular way via the Regata OS Update Manager, and was overall so pleased that
several months passed, and Regata OS unobtrusively updated itself to 24: Arctic
Fox, before I tackled the Garuda partition.
Accessing the Garuda partition from Regata OS, I found that
/boot/vmlinuz-linux-zen, the kernel, was missing. I booted the
Garuda ISO from the YUMI stick and copied the kernel from there, but that did
not make the Garuda partition bootable again (hello for the umpteenth time,
MemTest). Clearly, more system files were missing.
This eventuality was already mentioned on the Garuda forum in the post System missing from GRUB after update (14). Yes, an update can bork your system. Because this is Linux, and Linux lives dangerously. (Windows users who have to do a complete reinstall after certain updates, please stop laughing.) The solution is to boot into a live session from the ISO and then not so much copy as reinstall the system files, using "chroot" ("change root", like assigning "C:" to a different partition to boot the Windows installation there) and bearing in mind that Garuda uses Btrfs which uses "@" rather than "/" for the root directory.
I'll break up the information from this post into steps, for clarity, and to remind myself what to do the next time an update fails through insufficient disk space. As with the instructions for Regata OS, it didn't work as expected.
First: find and note the device names of the Garuda Linux partition and, on
an UEFI system (as in this case), the partition where the EFI boot files are,
which will be needed for the sixth step. It is advised to use
lsblk -f for this, but, with a functioning parallel Linux
installation that includes a partition manager, I simply looked for the only
partition listed whose filesystem was "btrfs", which was
/dev/nvme0n1p10, and a partition mounted at boot/efi
and labelled "EFI system Partition", which was /dev/nvme0n1p1.
Second: reboot off the Garuda ISO into a live session, and then connect to the internet, to create a mount directory. Don't walk away and return when the live session has booted all the way to desktop, as I did, because then the keyboard won't work, and won't start working until the screen locks itself after too much inactivity, and needs the default password ("garuda", and now the keyboard magically works again) to unlock itself.
(I have since noticed that sometimes, on turning on the laptop and booting a Linux partition - usually the Garuda one - the keyboard doesn't work at login, and I can't type in the password. A restart fixes this.)
After booting, the root directory is now on the USB stick, and whatever files
are created, are temporary. Linux accesses partitions by making directories and
linking those directories to the partitions via the latter's device names. So, I
create a subdirectory (that will disappear when the live session ends) in
directory /mnt to connect to the Garuda partition; the subdirectory
name can be anything, but the post uses "broken". In case /mnt
doesn't exist, use the option "-p" which also creates the parent directory.
Use sudo for this and the next two steps, as they require root
privileges.
sudo mkdir -p /mnt/broken
Third: mount the Garuda partition, using the device name found in the first
step. Its root directory (/) is now the same as its mount point
(/mnt/broken). Don't mount the EFI partition yet.
sudo mount /dev/nvme0n1p10 /mnt/broken
At this point there must be a working internet connection, or the next steps
will fail.
Fourth: chroot (this is a verb now) the Garuda partition, so that its root
partition is the de facto root partition and the live session's root partition
becomes, uh, something else, I guess. Use Garuda's version of this command, and
don't forget the "@" at the end. This makes you the root user of the
installation you just chrooted to, so after this step, you won't need to use
sudo.
sudo garuda-chroot /mnt/broken/@
I forgot about the internet connection, of course, and ran into trouble with
the next step, which I couldn't resolve until I exited chroot, got online, and
re-chrooted.
Fifth, quoted from the post: "Install kernel and generate .preset files in
/etc/mkinitcpio.d" through Pacman, then check with ls whether the
right file was created, then "Create initial ramdisk and check that the kernel
and image files are in /boot" and again, check if files were created.
pacman -S linux-zen
Pacman started the install but could not find the files online. Oops, its
package database should have been refreshed.
pacman -Sy
pacman -S linux-zen
This time, something was downloaded and installed:
sh-5.2# pacman -S linux-zen
resolving dependencies...
looking for conflicting packages...
Package (1) Old Version New Version Net Change Download Size
extra/linux-zen 6.7.6.zen1-1 6.8.7.zen1-2 1.34 MiB 136.66 MiB
Total Download Size: 136.66 MiB
Total Installed Size: 136.90 MiB
Net Upgrade Size: 1.34 MiB
:: Proceed with installation? [Y/n] Y
:: Retrieving packages...
linux-zen-6.8.7.zen1-2-x86_64 136.7 MiB 1344 KiB/s 01:44
[------------------------------------] 100%
(1/1) checking keys in keyring
[------------------------------------] 100%
(1/1) checking package integrity
[------------------------------------] 100%
(1/1) loading package files
[------------------------------------] 100%
(1/1) checking for file conflicts
[------------------------------------] 100%
(1/1) checking available disk space
[------------------------------------] 100%
:: Running pre-transaction hooks...
(1/3) Performing snapper pre snapshots for the following configurations...
==> root: 3
(2/3) Saving Linux kernel modules...
(3/3) Removing initramfs...
:: Processing package changes...
(1/1) upgrading linux-zen
[------------------------------------] 100%
:: Running post-transaction hooks...
( 1/11) Restoring Linux kernel modules...
++ uname -r
+ KVER=6.5.9-zen2-1-zen
+ test -e /usr/lib/modules/backup/6.5.9-zen2-1-zen
+ rm -rf /usr/lib/modules/backup
( 2/11) Arming ConditionNeedsUpdate...
( 3/11) Updating module dependencies...
( 4/11) Updating initramfs...
:: Building initramfs for linux-zen (6.8.7-zen1-2-zen)
:: Building fallback initramfs for linux-zen (6.8.7-zen1-2-zen)
( 5/11) Updating linux initcpios...
( 6/11) Foreign/AUR package notification
[many package names]
( 7/11) Orphaned package notification...
[some package names]
( 8/11) Checking for .pacnew and .pacsave files...
( 9/11) GRUB update after transactions...
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/garuda-dr460nized/theme.txt
Found linux image: /boot/vmlinuz-linux-zen
Found initrd image: /boot/amd-ucode.img /boot/initramfs-linux-zen.img
Found fallback initrd image(s) in /boot: amd-ucode.img
initramfs-linux-zen-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot
entries.
grub-probe: error: cannot find a GRUB drive for /dev/sda2. Check your
device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sda2. Check your
device.map.
Found Regata OS 24 Arctic Fox on /dev/nvme0n1p9
Adding boot menu entry for UEFI Firmware Settings ...
Detecting snapshots ...
Found snapshot: 2024-04-27 16:25:08 | @/.snapshots/3/snapshot | pre | N/A
|
Found 1 snapshot(s)
Unmount /tmp/grub-btrfs.sEO6QVT6rp .. Success
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done
(10/11) Performing snapper post snapshots for the following configurations...
fatal library error, lookup self
==> root: 4
(11/11) Syncing all file systems...
According to the above, simply installing linux-zen also completed the follow-up
of making new kernel and ramdisk images, and the next step of updating grub.
However, there should have been a file linux-zen.preset in
directory /etc/mkinitcpio.d:
ls /etc/mkinitcpio.d
mkdir /etc/mkinitcpio.d
sh-5.2# pacman -S linux-zen warning: linux-zen-6.8.7.zen1-2 is up to date -- reinstalling resolving dependencies... looking for conflicting packages... Package (1) Old Version New Version Net Change extra/linux-zen 6.8.7.zen1-2 6.8.7.zen1-2 0.00 MiB Total Installed Size: 136.90 MiB Net Upgrade Size: 0.00 MiB :: Proceed with installation? [Y/n] Y (1/1) checking keys in keyring [------------------------------------] 100% (1/1) checking package integrity [------------------------------------] 100% (1/1) loading package files [------------------------------------] 100% (1/1) checking for file conflicts [------------------------------------] 100% (1/1) checking available disk space [------------------------------------] 100% :: Running pre-transaction hooks... (1/2) Performing snapper pre snapshots for the following configurations... fatal library error, lookup self ==> root: 5 (2/2) Saving Linux kernel modules... :: Processing package changes... (1/1) reinstalling linux-zen [------------------------------------] 100% :: Running post-transaction hooks... ( 1/10) Restoring Linux kernel modules... ++ uname -r + KVER=6.5.9-zen2-1-zen + test -e /usr/lib/modules/backup/6.5.9-zen2-1-zen + rm -rf /usr/lib/modules/backup ( 2/10) Arming ConditionNeedsUpdate... ( 3/10) Updating module dependencies... ( 4/10) Updating initramfs... :: Building initramfs for linux-zen (6.8.7-zen1-2-zen) :: Building fallback initramfs for linux-zen (6.8.7-zen1-2-zen) ( 5/10) Updating linux initcpios... ( 6/10) Foreign/AUR package notification [many package names] ( 7/10) Orphaned package notification... [some package names] ( 8/10) Checking for .pacnew and .pacsave files... ( 9/10) Performing snapper post snapshots for the following configurations... fatal library error, lookup self ==> root: 6 (10/10) Syncing all file systems...The directory was still empty, but maybe the preset file had been created, used during the "Updating linux initcpios..." step, then deleted. This second install differed from the first only in that it used files in the cache, didn't remove initramfs beforehand, and didn't update grub and create a new boot menu entry. What should have been the next command:
mkinitcpio -p linux-zen
ls /boot
initramfs-linux-zen.img (initial ramdisk)
initramfs-linux-zen-fallback.img (emergency initial ramdisk)
vmlinuz-linux-zen (kernel)
(The sixth step is included for completeness, but skipped, as the logs above show that grub was already brought completely up to snuff.)
Sixth: reinstall grub. On a legacy system, this would overwrite the existing
grub, typically in the Master Boot Record or MBR, which you might want to keep.
An UEFI system has a special partition containing separate EFI boot directories
(generally using grub, in case of Linux) for each bootable partition, so no MBR
is overwritten; you can choose which EFI bootloader is used to boot the
computer. As this laptop by default uses the Regata OS bootloader, which still
has entries to boot Garuda, reinstalling grub for the Garuda partition isn't
strictly necessary, but better safe than sorry. So, on an UEFI system, mount
this EFI partition, the device name of which was found in the first step, on a
directory that definitely already exists, unless the Garuda installation uses
Legacy boot, in which case, DON'T:
mount /dev/nvme0n1p1 /boot/efi
Then reinstall grub the standard way (for a 64-bit UEFI system):
grub-install --target=x86_64-efi --efi-directory=/boot/efi
--bootloader-id=garuda --recheck
update-grub
Seventh, very important: leave chroot by typing exit at the
prompt. This hands control back to the live session, so nothing horrible will
happen to the Linux installation on disk when the session is ended.
exit
Then end the live session (this will unmount any mounted partitions), remove the boot stick and (hopefully) reboot into the fixed partition.
Here, I did something dumb but amusing. Not quite trusting that the Garuda installation had been fully repaired, and forgetting that its system files had been updated, ie. changed, I booted Garuda from its entry in the Regata OS bootloader.
(Tommy Wiseau voice:) Oh hai, MemTest.
Reassured once again that the RAM is FINE, I used F8 in the UEFI screen to
boot from Garuda's own bootloader, which had been updated to the point of
correctly displaying the correct new version of Regata OS. Some errors flashed
past during boot, but the desktop was as it must have been during its last,
fatal upgrade: Dolphin opening to the contents of ~/.minetest,
browser FireDragon running, YouTube showing "Ritmos de Los Muertos". I opened
Konsole to check the boot errors by running dmesg, which, I was
surprised to discover, required "sudo"; there was something about an
unrecognized boot argument being passed to userspace:
Unknown kernel command line parameters "BOOT_IMAGE=/@/boot/vmlinuz-linux-zen", will be passed to user space.but Garuda, appending "Spizaetus" to its name in the Welcome screen after its upgrade, had booted and ran without problems, although a notification with an exclamation mark told me: "Partial upgrade detected - Garuda System Maintenance", and that I should do a full upgrade post-haste. It was then that I discovered Garuda does not like to share.
(I also discovered that after each boot or upgrade, an annoying dialog pops up asking you to make a NextCloud account, or else host your own server, neither of which I intend to do; this is solved under Garuda Dr460nized (Spizaetus): the upgrade and Nextcloud.)
Specifically, Garuda won't share an internet connection. If two laptops are connected to the WiFi at the same time, Regata OS doesn't mind, but FireDragon on Garuda suddenly can't find any sites. So I disconnected my other laptop, on which I'd been researching in Firefox "why my Linuxes no worky!!" before letting the notification open a console and start an upgrade to the tune of 992 packages. Which failed, because it ran out of disk space. Again. Just like last time.
Fear not, dear reader, the system files were still intact. I used Garuda
Assistant to Clean caches, Clean package cache and Remove orphans. I deleted all
snapshots through both Snapper and the Btrfs Assistant. I typed du >
bloat.txt in Konsole and scrolled down an eternity of lines trying to
find what data was hogging the partition. I consulted the internet, via
FireDragon this time, and found two helpful links, Disk cleanup
tools? (15) and How to clean Arch Linux (16). The first
explained how to clean the Pacman installfile cache
(/var/cache/pacman/pkg) and my, what a pileup of packages was
there. The command
sudo paccache -rk0
ruthlessly deletes all the versions of packages that Pacman retains in case
something needs a rollback or reinstall. This freed 14.03 GiB of space. That
was enough to retry the upgrade, which now boasted no less than 1012 packages
(997 to be downloaded).
(There is an easier way to purge the cache: in the Application Launcher menu, choose System, then Octopi CacheCleaner, which displays the stored packages and how much room they take up; click on the "Clean" button to delete them.)
Judging from the following bit of upgrade log, Garuda had changed significantly since the failed upgrade that wiped its system files:
:: Starting full system upgrade... :: Replace baloo5 with extra/baloo? [Y/n] y :: Replace bluez-plugins with extra/bluez-utils? [Y/n] y :: Replace breeze with extra/breeze5? [Y/n] y :: Replace chaotic-kf5-dummy with chaotic-aur/chaotic-mirrorlist? [Y/n] y :: Replace kde-servicemenus-rootactions with chaotic-aur/kf6-servicemenus-rootactions? [Y/n] y :: Replace ksysguard with extra/plasma-systemmonitor? [Y/n] y :: Replace kuserfeedback5 with extra/kuserfeedback? [Y/n] y :: Replace libblockdev-utils with extra/libblockdev? [Y/n] y :: Replace plasma-integration with extra/plasma5-integration? [Y/n] y :: Replace plasma-wayland-session with extra/plasma-workspace? [Y/n] y :: Replace plasma5-applets-window-buttons with extra/plasma-applet-window-buttons? [Y/n] y resolving dependencies... :: There are 2 providers available for phonon-qt6-backend: :: Repository extra 1) phonon-qt6-vlc :: Repository chaotic-aur 2) phonon-qt6-mpv Enter a number (default=1): :: There are 2 providers available for qt6-python-bindings: :: Repository extra 1) pyside6 2) python-pyqt6 Enter a number (default=1): looking for conflicting packages... :: garuda-dr460nized and plasma5-applets-window-appmenu are in conflict. Remove plasma5-applets-window-appmenu? [y/N] y :: garuda-dr460nized and plasma5-applets-window-title are in conflict. Remove plasma5-applets-window-title? [y/N] y :: garuda-dr460nized and plasma5-applets-betterinlineclock-git are in conflict. Remove plasma5-applets-betterinlineclock-git? [y/N] y :: garuda-dr460nized and plasma5-wallpapers-blurredwallpaper are in conflict. Remove plasma5-wallpapers-blurredwallpaper? [y/N] y warning: dependency cycle detected: warning: crawl-tiles will be installed before its crawl-data dependency warning: dependency cycle detected: warning: qt6-multimedia-ffmpeg will be installed before its qt6-multimedia dependency warning: dependency cycle detected: warning: phonon-qt6-vlc will be installed before its phonon-qt6 dependency warning: dependency cycle detected: warning: xdg-desktop-portal-kde will be installed before its plasma-workspace dependency warning: dependency cycle detected: warning: python-incremental will be installed before its python-twisted dependency
When the upgrade was finished, my woes were not over: every icon in the dock had changed to a question mark, and when I double-clicked a file with extension ".txt", I was asked what application I wanted to open it with. ("Kate, you fools.") The Nextcloud dialog opened again, and the options to reboot, shut down or log out were missing, so I switched the laptop off and on to force a reboot, which I hoped would solve everything. But oops, I booted off the Regata OS grub menu again and, ARGGH, sat through yet another round of MemTest.
"MemTest, may we never meet again." was my thought as I booted to Regata OS
to fix its grub (grub2, not legacy) entries, so that it might boot Garuda
properly. This is typically done with
sudo update-grub
where "update-grub" is supposed to run the general, distro-agnostic command
grub-mkconfig -o /boot/grub/grub.cfg
which generates the grub2 config file. But Regata OS didn't understand the
first command, and the second command, which supposedly works for all distros,
didn't work here. I had to specify the grub version:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
and yay, no more MemTest after choosing the Garuda entry.
Upgrade woes continued: after booting Garuda, now "Spizaetus" (a smallish bird of prey) from Regata OS's bootloader, and again being nagged to make a Nextcloud account, I received the notification that Plasma 6 (17) has replaced Plasma 5, and this changes the theme, would I like to reapply the dragonized theme? So that's what messed up the Dock, Plasma Panel (like Windows Taskbar but at the top of the screen, and running tasks are shown in the Dock), and Application Launcher (Linux version of Start Menu), not to mention file associations: a new Plasma version. Replying "Yes" didn't fix the mess, but made it worse: the Dock was still a row of question marks, but now the Application Launcher no longer contained Favorites or Applications. Basically, anything using a .desktop file was broken. I wanted to set the maximum battery charge to 80% and change the theme, but how was I to run System Settings or the Theme Switcher now?
I right-clicked on the Dock panel and chose "Enter Edit Mode", which made the panel editable and displayed the option "Choose Global Theme". After setting the theme to something else and changing it back, then finding my way to "Manage Desktops And Panels", the Dock icons reappeared, as did the Application Launcher's entries; did my tinkering do this, or was Plasma repairing itself in the background, and was the timing coincidental?
The file associations were also repaired: clicking on a text file opened it in Kate. When the Plasma Panel is at the top of the screen, and an application is maximized, the application's menu bar is part of the top panel, as in the old MacOS versions I'm familiar with. As Plasma hadn't fully fixed itself yet, this menu bar did not contain the buttons to close, resize or minimize the application, and the only way to stop Kate's window hogging the screen was to choose File and then Quit to close Kate. A number of reboots sorted out the last glitches, and inconspicuously replaced "Spizaetus" with "BirdOfPrey" in the Garuda Welcome screen.
The Dock needed two more shortcuts: Stacer, which I knew from an older Garuda version, and the file manager Dolphin, which apparently doesn't play nice with the current dock-panel. Dolphin was added by starting it, right-clicking on the Dolphin icon in the Dock and choosing "Pin to Task Manager". When trying to install Stacer, I found it was not in the repositories.
Having access to System Settings again, I set the Dock to Auto-hide, changed the new resolution (which was 175%, and it didn't look good) and set the maximum battery charge at 80% again, noticing that this setting was no longer on the main Energy Saving tabs, but hidden in "Advanced Settings". I'd also heard of a "Thumbnail Grid" that was to be the new "default Task Switcher style" in Plasma 6, but this feature appeared to be off by default. Good.
Now to deal with *%!*ing Nextcloud! In the System Settings, I removed
NextCloud from "Autostart". This was not enough. Its "Nextcloud: Please sign in"
dialog pops up not only after booting, but also after right-clicking while
online, and clicking "Exit Nextcloud" only makes it pop up again. Other users
were equally annoyed by this, going by the Garuda Linux forum post
How do I delete Nextcloud? (18). The solution is
straightforward, uninstall it from the commandline:
sudo pacman -R nextcloud-client
One would think that would be the last of it, but noooo... Many upgrades later, I ran out of space again due to not having cleaned out snapshots. The upgrade in question wasn't cancelled and rolled back, but simply failed, so I tried to upgrade again - using Garuda's own Upgrade Assistant, as always - but this time there were far fewer packages. Did this mean that the mess of the failed upgrade remained? I deleted all snapshots older than the one made before the failed upgrade, tried to upgrade again, had only one package this time, and deleted the newer snapshots. Probably due to this mess, a notification shot past about networks, and suddenly wifi networks were no longer detected. Normally, there is a toggle to turn wireless detection on - a list of detected networks will appear - or off, but this toggle was no longer displayed.
To make wireless detection work again, I used Btrfs Assistant to restore that one remaining snapshot from before the failed upgrade, and rebooted. You can guess what happened next:
file '@/vmlinuz-linux-zen' not foundand I was bounced back into the bootloader menu. At least it didn't run MemTest.
Before repeating the steps of Fixing Garuda Dr460nized to at least have a bootable Garuda, I tried, from the Regata OS bootloader, Garuda's advanced boot options, including "Garuda Linux, with Linux linux-zen (recovery mode) (on /dev/nvme01n1p10)". All complained of a missing vmlinuz-linux-zen.
Time to boot off the YUMI stick into a Garuda live session. This time I kept my eyes on the screen as the session loaded, didn't have to log in, and had no problems with the keyboard not working. Unlike the installed distro, the live session detected my network (I only had to enter the numerical password and click Cancel on the KDE Wallet Service dialog repeatedly), so nothing was wrong with the network card.
I chrooted the partition and reinstalled the system files, using the
following commands:
sudo mkdir -p /mnt/broken
sudo mount /dev/nvme0n1p10 /mnt/broken/
sudo garuda-chroot /mnt/broken/@
pacman -Sy
That last command produced an error:
:: Synchronizing package databases... error: failed to synchronize all databases (unable to lock database)Continuing to install system files:
pacman -S linux-zen
error: failed to init transaction (unable to lock database) error: could not lock database: File exists if you're sure a package manager is not already running, you can remove /var/lib/pacman/db.lckWUT. Did restoring the snapshot also restore the database lockfile created during an upgrade?
cd /var/lib/pacman/
ls -l db.lck
---------- 1 root root 0 Jun 14 20:38 db.lckThis was the date and time of the failed upgrade. Yeah, that one can go.
rm db.lck
pacman -Sy
pacman -S linux-zen
(Note: at some point, Regata OS lost the ability to read btrfs volumes, even though the necessary software was installed; due to this, or the stealthy partition renumbering that happened later, it removed Garuda from its boot menu.)
The next step was to make wireless detection work again. Here was a catch-22: I can't get online until I fix the failed upgrade, and I can't fix the failed upgrade until I get online. Since I can get online in a live session, could I chroot the Garuda partition and run "garuda-update" in the chrooted environment? I found nothing online to dissuade me from this mistake. Here's what happened:
warning: warning given when extracting /usr/share/man/man1/qemu-system-xtensaeb.1.gz (Can't set permissions to 0777)Maybe it was because I didn't use "sudo". I tried "sudo garuda-update" immediately after that, which did nothing, as there was no longer anything to update.
[chroot]/var/cache/pacman/pkgs were
only visible in the chrooted session. They were completely invisible in the live
session's file manager. If, in the chroot session, I copied a package file to
another directory, it would also be invisible to the live session in that other
directory. (Copying to /home did nothing, as the home partition
wasn't mounted in the chroot session.)chmod 777 /var/cache/pacman/pkg/*
btrfs-check --repair should only be run on
unmounted partitions by experienced users. Running the command without the
repair option has it performing a read-only disk check. But the live session
doesn't include the btrfs-check utility. And Btrfs Assistant wouldn't run. The
KDE Partition Manager, if I right-clicked on the Garuda partition, has a "Check"
option, but when chosen, the pending Action said "Check and repair", which I
chickened out of as I didn't want to mess up the partition's filesystem.And still no wireless detection. It wasn't a hardware problem, that was
clear. Maybe if I followed the steps that let me get online in Regata OS?
Testing for a network card:
iwconfig
Result: "lo" followed by "no wireless extensions"
Testing the wifi reception:
nmcli radio wifi
Result: "enabled"
Conclusion: the network card driver had gone poof.
According to the internet, there should be a section "Hardware" in "System Settings" that lets me update the network card driver. There was not. Also according to the internet, it might be firmware rather than drivers that I needed. No mention of precisely which file to download and install, of course. The network card brand is Mediatek, but searching for that, or "wireless", or "network" in Octopi, Garuda's package management GUI, got me nowhere.
Of all webpages about network problems in Garuda or Arch Linux, only one little Reddit post (20) touched on the disappearing toggle. The poster's solution was to downgrade the firmware. Acccording to the Network configuration/Wireless (21) section of the Arch Linux Wiki, most modern hardware firmwares are included in package "linux-firmware". This section links to a list of network drivers: the Mediatek driver is called "mt7601u". Looking in Octopi, I couldn't find "mt7601u", but the package "linux-firmware" was explicitly installed, and occupied 0B on disk. Would reinstalling this solve the problem?
The following attempts to reinstall linux-firmware happened concurrently with the "invisible files" issue, which I became fully aware of when trying to copy a downloaded package from the Pacman cache to my home directory. I switched between using Pacman in a chrooted session inside a live session, and rebooting to the Garuda partition to see if it worked, before trying to install directly from file.
Going by the Pacman manual (type "man pacman" on the command line), upgrading
("-U") is best, as it removes then installs the package, while syncing ("-S")
checks online repositories for a newer version. I booted into a live session,
connected to internet, mounted the Garuda partition, chrooted, and tried to
upgrade:
pacman -U linux-firmware
error: 'linux-firmware': could not find or read package.I suppose a badly installed package can't be upgraded. Can it be installed?
pacman -S linux-firmware
warning: linux-firmware-[version] is up to date -- reinstallingYes, it can. But the install is aborted with an error, because the package tries to write many files ending in ".zst" that already exist. I hoped to remove them by uninstalling and reinstalling:
pacman -R linux-firmware
pacman -S linux-firmware
pacman -S linux-firmware
Pacman can "upgrade" (ie. install) a package from a file, which is how I
hoped to beat this catch-22: just boot Garuda and use the newly downloaded
package "linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst" in
/var/cache/pacman/pkg which is, um, empty; that's how I found out
about garuda-chroot's invisible files problem. So, in the internet-capable live
session, with my home directory mounted at
/run/media/garuda/HOME/[username], I used the filename in a
websearch and found a linux-firmware package site (22) from
where I downloaded the package to my now accessible home directory. Then, I
booted to Garuda, started Konsole, and prepared to return linux-firmware to its
former glory.
pacman -U
/home/[username]/linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
error: you cannot perform this operation unless you are root.Oops. Using sudo:
sudo pacman -U
/home/[username]/linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
sudo pacman -U
file:///home/[username]/linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
:: Retrieving packages... linux-firmware-20240610.9c10a208... 229.8 MiB 534 MiB/s 00:00 [------------------------------------] 100% error: failed retrieving file 'linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst.sig' from disk : Couldn't open file /home/[username]/linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst.sig warning: failed to retrieve some filesThen it wants a sig file, which I don't have, to verify the package. There is a way to install sig-less packages by making your own repo and editing pacman.conf as mentioned in Pacman does not allow installing package without `.sig` but Pamac does (23), but that's a bit too advanced for the noob that I am. So, using the old option, but specifying that existing files should be overwritten:
sudo pacman -U -- overwrite *
/home/[username]linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
error: missing package metadata in [filename] error: '[filename]': invalid or corrupted packageMaybe sync instead of upgrade?
sudo pacman -S -- overwrite *
/home/[username]linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
error: target not found: [filename] warning: '[filename]' is a file, did you mean -U/--upgrade instead of -S/--sync?Apparently I should use two asterisks for overwriting files in subdirectories:
sudo pacman -U --overwrite **
/home/[username]/linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
fish: No matches for wildcard '**'. See `help wildcards-globbing`.Maybe I should be in the root directory?
cd /; sudo pacman -U --overwrite **
/home/[username]/linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
exec: Failed to execute process '/usr/bin/sudo': the total size of the argument list and exported variables (1MB) exceeds the OS limit of 2MB.Running the command without "sudo" had the same result. Maybe if I narrowed down the potential list of files to overwrite? This started off promisingly:
sudo pacman -U --overwrite **zst
/home/[username]/linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
loading packages... resolving dependencies... looking for conflicting packages... Package (1) New Version Net Change linux-firmware 20240610.9c10a208-1 234.58 MiB Total Installed Size: 234.58 MiB :: Proceed with installation? [Y/n] ... linux-firmware: /usr/lib/firmware/yamaha/yss225_registers.bin.zst exists in filesystem Errors occurred, no packages were upgraded.So, no, I would not be able to reinstall firmware-linux from a file. WHYYY!!
Then I had a brilliant idea. The files hindering reinstallation by their very
existence were all in /usr/share/licenses/linux-firmware and
/usr/lib/firmware. What if I
renamed those directories so pacman wouldn't see them?
sudo mv /usr/share/licenses/linux-firmware
/usr/share/licenses/linux-firmbak
sudo mv /usr/lib/firmware /usr/lib/firmbak
sudo pacman -U
/home/[username]/linux-firmware-20240610.9c10a208-1-any.pkg.tar.zst
loading packages... resolving dependencies... looking for conflicting packages... Package (1) New Version Net Change linux-firmware 20240610.9c10a208-1 234.58 MiB Total Installed Size: 234.58 MiB :: Proceed with installation? [Y/n] YAnd lo and behold, I had wireless again! I did a little happy dance.
Now I should have done a total reinstall of all software in case the previous
updates had broken something, but given the risk of overfilling the partition
yet again, I decided to leave it and hope that future updates would sort
everything out. I did however compare
/usr/share/licenses/linux-firmware to
/usr/share/licenses/linux-firmbak (no difference) and
/usr/lib/firmware to /usr/lib/firmbak (many more files
in "firmbak") and, painstakingly, located the extra entries in "firmbak" and
copied them to "firmware"; they were probably obsolete, but better safe than
sorry:
cd /usr/lib/firmbak sudo cp -r amd-ucode /usr/lib/firmware/ sudo cp -r asihpi /usr/lib/firmware/ sudo cp -r cs46xx /usr/lib/firmware/ sudo cp -r emu /usr/lib/firmware/ sudo cp -r mixart /usr/lib/firmware/ sudo cp -r pcxhr /usr/lib/firmware/ sudo cp -r vx /usr/lib/firmware/ sudo cp aica_firmware.bin /usr/lib/firmware/ sudo cp ctefx-desktop.bin /usr/lib/firmware/ sudo cp ctefx-r3di.bin /usr/lib/firmware/ sudo cp digiface_firmware_rev11.bin /usr/lib/firmware/ sudo cp digiface_firmware.bin /usr/lib/firmware/ sudo cp multiface_firmware_rev11.bin /usr/lib/firmware/ sudo cp multiface_firmware.bin /usr/lib/firmware/ sudo cp regulatory.db /usr/lib/firmware/ sudo cp regulatory.db.p7s /usr/lib/firmware/ sudo cp rpm_firmware.bin /usr/lib/firmware/One extra entry remained to be found, for which I had to compare the two firmware directories down to the last subdirectory, an experience so gruelling that I forgot what this entry was. But, at last, it was done.
What happened to Regata OS? Failure to boot after an update. Twice. At least it didn't run MemTest instead.
The first update was the infamous Windows 11 one that tried to patch a grub security issue and, in doing so, unintentionally borked Linux/Windows dualboot systems. I'd heard of it around halfway through 2024, and since Windows Update on the ROGBook didn't kick in until October, thought that issue had been fixed. It had not. Neither Linux partition was bootable; even with Secure Boot disabled in the UEFI, both presented a grub rescue shell that couldn't detect any filesystems, so "ls (hd0,gpt7)" and "insmod [module]" did nothing. The solution: boot a Garuda live session from stick, and use "Garuda Boot Repair" (called "Garuda Boot Options" in the installed version) from the Welcome screen. This repaired Garuda's EFI bootloader, which includes Regata OS in its boot menu. Booting Regata OS from Garuda's boot menu, then letting Regata OS update itself, also repaired Regata OS's EFI bootloader, although the latter had stopped including Garuda in its boot menu, so I set the UEFI to boot from Garuda's EFI bootloader instead of Regata's.
And here I must lodge a complaint about these two distros, the only ones I've found that can handle all of this laptop's features. Garuda, as a proper Arch Linux offshoot, can be messy, but gives feedback and lets me interfere via the command line when necessary; however, its default Nvidia graphics driver, the wholly open-source Nouveau driver, produces screen artefacts. Regata OS, in the spirit of OpenSUSE (and Windows, and Apple), provides a perfect picture and polished experience, that relies on not letting the user look under the hood; which is why I've had to reinstall it several times. Regata OS's update function separates application updates (usually Firefox, Okular and Regata OS Game Update) and "system" updates, the latter being much more critical than the interface suggests, and doesn't report any hiccups. Seeing Regata OS's update notification pop up in november 2024, and checking what the system updates were, I saw they included kernel and firmware entries - the sort of update over which users are told to restart their system ASAP - so once the update was "finished", I rebooted... to an error message that no kernel could be found. Ah yes, I was using Garuda's boot menu, which hadn't been updated, and would be expecting the old, replaced kernel. So I rebooted again and used the F2, F8 trick to boot from Regata OS's own EFI boatloader. And was greeted again by a grub rescue shell.
When grub doesn't work as expected, it has an emergency fallback: the grub shell, supporting a small set of commands with which to manually boot an OS. If the grub shell wouldn't work, it has a second emergency fallback: the grub rescue shell, with an even smaller set of commands. To the Linux-illiterate, the "grub rescue>" command prompt means "you are f*cked".
The Windows update broke grub, but left the Linux partitions untouched; the
Regata OS update seemingly did something comparable to the failed Garuda
updates, though not through lack of disk space. And the internet was no help in
this instance, either. For what it was worth, the three files that needed to be
reinstalled to make Garuda work:
/boot/initramfs-linux-zen.img
/boot/initramfs-linux-zen-fallback.img
/boot/vmlinuz-linux-zen
were now absent in Regata OS, although, since I've seen little of Regata's
inner workings, they might never have been there.
My panic was for nothing. Deciding to tackle this problem weeks later, I booted Regata OS from Garuda's boot menu, fully expecting the grub rescue shell, but pleasantly surprised by a login screen followed by the familiar and fully functional desktop. Running "garuda-update" for any kernel-related update also renews Garuda's grub menu, so Regata's necessary system files were in place after all, and grub (as run by Garuda's EFI bootloader) only needed to find them.
That said, Regata OS's own grub menu seemed to be kaputt, and to prevent the
shock of being dumped in its rescue shell again, I took the opportunity to
fix its grub yet again:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
which did not work, as booting via the Regata OS EFI bootloader led to
aforementioned rescue shell. Yes, Regata's bootloader seemed borked proper.
While pondering on this, I managed again to delete Garuda's system files by upgrading it with insufficient disk space - naughty me, I'd forgotten to wipe the cache again - and fixed this for a third time, noticing that what used to be partition number 10 was now partition number 7. That is to say, the partitions had originally been numbered in order of creation - Garuda's system partition had been the latest addition - and were now numbered by where they resided on the harddisk, which contained: the partitions to do with Windows; the Linux partitions, added later; and the restore partitions, hidden at the end of the disk. Some update - either the Windows or the Regata OS one - had renumbered all partitions. Garuda's and Windows' bootloaders had adapted; Regata OS was trying to boot off one of the restore partitions.
A simple grub update was not enough to set Regata's bootloader right. I opened the YaST Control Center, tried to fix things using "Boot Loader", and got the following dialog:
Probing disk /dev/nvme0n1 failed Unexpected situation found in the system. Click below to see more details (English only). Continue despite the issue?Next dialog after clicking "Details":
Command not found: "/usr/sbin/nvme list --verbose --output json"
This took me back to a note I'd made when first installing Regata OS: that I
couldn't install nmve-cli due to a tangled mess of dependencies.
This program is what probes NVME disks - like this laptop's harddisk - for boot
partitions. I used the YaST Software Manager to install libnvme1,
only to find that I still couldn't install nmve-cli because the
version of libnmve1 was too old, and could not be updated due to
dependencies. So I waited for an update to sort this out, resigning myself to
using Garuda's bootloader in the meanwhile. Sure enough, a system update in
December included:
libnmve1
libnmve-mi1
which not only fixed Regata's bootloader but made it the default, despite
leaving out Garuda, whose partition it was mysteriously no longer able to read,
in its boot menu, so once again I changed the UEFI's default bootloader to
Garuda's. Which bootloader observantly changed Regata's boot entry to "Regata
Arctic Fox 24.1".
But Regata OS keeps pace with openSUSE, already at Leap 15.6, and another kernel update waited in the wings, constantly frustrated by aforementioned mess of dependencies. Each time I connected to the internet, Regata OS Update Manager alerted me to system updates. Each time, I let it go ahead and update, and was told the update had finished successfully, only to be alerted to even more system updates the next time, because the update had, in fact, failed and been rolled back. When the system update was at 417 programs, I decided to take matters into my own hands.
I waited for the next update notification, opened the window and its list of system updates, and also opened the YaST Software Manager, in which many installed programs were displayed in blue, signifying there was a newer version available, and quite a number in red, meaning they had the "wrong" version relative to the installation. Garuda has a monolitic update style, and won't let me update one part of the whole, letting that part get out of step with the rest. Regata OS actually doesn't and will; in fact, due to its cutting edge hardware support achieved by mixing bits of different branches, various programs are necessarily out of step with each other, which is what causes failed system updates. So I left the red entries alone, but for each of the blue ones, set them to "update", reversing this if a dialog appeared about conflicting dependencies, and then committed those changes, so that every bit of installed software that could safely be updated, was; this included the kernel and firmware. It took a long time, because after each reboot, it turned out I'd missed a few, but at last, the only blue entries left were the problematic ones.
(For instance, programs could not be updated because they needed gcc14, to which I could not update because of the programs that relied on gcc13.)
Apart from the reboot obviously needed after a kernel update, I rebooted after each update to refresh the Regata OS Update Manager's list, which is apparently created once per boot and not updated along with software, so, for instance, it will brazenly tell me that Okular needs to be updated again, and again, and again. Once I'd done all I could in the YaST Software Manager, rebooted one more time, and saw that the system update had been reduced to 14 items, it was time to call on Regata OS's main package updater: zypper.
This handy package manager, hailed by some as the nec plus ultra in its
field, can tell me, after a repository refresh (always a must before letting
zypper do anything), exactly which programs need to be, and can be, updated:
sudo zypper ref
sudo zypper lu
where "lu" is short for "list-updates", see the zypper
Cheat Sheet (24). This did warn me about a repository gone obsolete before I
attempted to update the system, which may explain why the update kept failing:
> sudo zypper lu
Loading repository data...
Warning: Repository 'leap_15.5_updates' metadata expired since 2024-12-20 15:11:15 CET.
Warning: Repository metadata expired: Check if 'autorefresh' is turned on (zypper lr), otherwise
manually refresh the repository (zypper ref). If this does not solve the issue, it could be that
you are using a broken mirror or the server has actually discontinued to support the repository.
Having said that, zypper produced the following beautiful table of updates,
corresponding perfectly to the list of system upgrades by Regata OS Update
Manager:
sudo zypper up
sudo zypper clean
(Okay, so maybe I should have used zypper for the whole upgrade, and saved myself some time. But in this way, I knew the upgrade was complete.)
Usually, one of Garuda's frequent updates will also point grub to Regata's
newest kernel, but this time, updates were lacking, so I had to boot into Garuda
and do it myself:
sudo update-grub
aaaand done.
Modern laptops may support the feature to set a charging limit for their batteries. This limit can be set from the command line or via a GUI, in the case of KDE Plasma, via the Application Menu: System, System Settings, section Power Management, under the "Advanced Power Settings" button.
Both Garuda and Regata OS have the same System Settings/Power Management screen where the battery can be set to a maximum charging threshold, say, 80%. In both cases, the setting requires an administrator password, and has to be set again after every reboot. Also, if the threshold is set while the battery charge exceeds it - say, the threshold is 80% and the battery is already at 83% - the battery, if the laptop is plugged in to the mains, ignores the threshold and charges itself to its maximum, which shortens its lifespan and is therefore a Bad Thing. In this case, the laptop should be unplugged until the battery charge dips below the threshold.
Unplugging the laptop is generally a good idea, as, even if the battery charging threshold is set, the power block heats up as long as the laptop is plugged in, which probably shortens its lifespan, too (and, in my experience, stops it working until it's cooled down, so the laptop battery charge is stealthily dropping to zero while the laptop is plugged in). Still, having to reset the battery threshold in System Settings after every boot is annoying, to the point that a bug report (25) has been filed for it. Also, I keep forgetting to set the charge limit again, especially when solving computer problems that require many reboots, like those described in the chapters above.
So, what are my options? Solutions within Desktop Environment, like
Powerdevil, which handles power management in KDE Plasma: relevant settings not
persistent on an Asus laptop. Creating a systemd service to reset the charge
limit after each boot: toooo haaarrrd and according to the
ArchWiki page on Asus laptops (26), an obsolete solution.
Two commandline programs: the general utility TLP and the Arch-specific
"bat-asus-battery-bin". Under Regata OS, only tlp showed up in the
YaST Software Manager, so I installed that, with its dependencies
hdparm and tlp-rdw.
TLP is a program with much functionality, most of which I don't need; just
the charge-limiting stuff, please! The LinuxConfig page How to
optimize laptop battery life with TLP on Linux (27) set out the necessary
steps. Install tlp: done. Enable it: not before I've edited the settings. Edit
/etc/tlp.conf. Okay, will do. Test using tlp-stat.
Let's do that first. Open Konsole, type
sudo tlp-stat
and a whole load of text is blarped out in the console, unpaged, of which
only the last section interests me:
+++ Battery Care Plugin: asus Supported features: charge threshold Driver usage: * natacpi (asus_wmi) = active (charge threshold) Parameter value range: * STOP_CHARGE_THRESH_BAT0/1: 1..100(default) +++ Battery Status: BAT0 /sys/class/power_supply/BAT0/manufacturer = AS3GXPe3KC /sys/class/power_supply/BAT0/model_name = GA40249 /sys/class/power_supply/BAT0/cycle_count = 0 (or not supported) /sys/class/power_supply/BAT0/energy_full_design = 76000 [mWh] /sys/class/power_supply/BAT0/energy_full = 65293 [mWh] /sys/class/power_supply/BAT0/energy_now = 44400 [mWh] /sys/class/power_supply/BAT0/power_now = 17542 [mW] /sys/class/power_supply/BAT0/status = Discharging /sys/class/power_supply/BAT0/charge_control_end_threshold = 80 [%] Charge = 68.0 [%] Capacity = 85.9 [%]Higher up in the infovomit, a relevant line:
Error: TLP's power saving will not apply on boot because tlp.service is not enabled --> Invoke 'systemctl enable tlp.service' to ensure the full functionality of TLP.
Well. I can see the 80% charge limit that I already set, and also that my
frequent forgetting to set a charge limit has already worn the battery down to
85% of its original capacity. Using Kwrite to look at /etc/tlp.conf
in read-only mode, I decide to close my eyes to all the settings and hope none
of them bork my installation, except for this tiny snippet:
# Battery charge level below which charging will begin. #START_CHARGE_THRESH_BAT0=75 # Battery charge level above which charging will stop. #STOP_CHARGE_THRESH_BAT0=80The second parameter, I will simply uncomment. The first, I think I'll set to 60, so the battery will have a 20% rather than 5% window in which to simply unload itself without triggering the charging process. Will that save on wear and tear? I have no idea.
Since Regata OS doesn't have the well-known Linux editor vi
installed, I foolishly type:
sudo kwrite /etc/tlp.conf
and am rebuked:
THIS IS POTENTIALLY INSECURE! To edit files as root please use: SUDO_EDITOR=kwrite sudoedit <file>so I obediently type:
SUDO_EDITOR=kwrite sudoedit /etc/tlp.conf
sudo systemctl enable --now tlp.service
sudo systemctl enable tlp.service
Created symlink /etc/systemd/system/multi-user.target.wants/tlp.service → /usr/lib/systemd/system/tlp.service.and that should do it for Regata OS. Reboot to Garuda!
In Octopi, though I see no "bat-asus-battery-bin", I am allowed to select "tlp-1.7.0-1" for install without dependencies, and even see a TLP front-end on offer called "tlpui", but my hopes are dashed on seeing that TLP conflicts with the "upower daemon", and would I like to uninstall the latter? I would not. Abort install.
So, as of now, no solution for Garuda. Which will be getting less use than Regata OS anyway, as the increased screen flickering due to friction between the graphics card and Garuda's drivers is getting on my last nerve. Possibly to be continued.
