What I Learned Trying to Install Kubuntu (alongside Pop!_OS)

First and foremost, once again, this is clearly not a supported configuration that I tried to make.  I'm sure that if I wiped the drive and started afresh, things would have gone much better.  I just… wanted to push the envelope a bit.

Pop!_OS installs (with encryption) with the physical partition as a LUKS container, holding an LVM volume group, and the root filesystem is on a logical volume within.  The plan was hatched:

• Create a logical volume for /home and move those files over to it
• Create a logical volume for Kubuntu’s root filesystem
• Install Kubuntu into the new volume, and share /home for easy switching (either direction)

Things immediately got weird.  The Kubuntu installer (calamares) knows how to install into a logical volume, but it doesn’t know how to open the LUKS container.  I quit the installer, unlocked the thing, and restarted the installer.  This let the installation proceed, up to the point where it failed to install grub.

Although that problem can be fixed, the whole installation ended up being irretrievably broken, all because booting Linux is clearly not important enough to get standardized. Oh well!

Anyway, I figured the grub failure shouldn’t matter too much.  The boot loader should be one of the last things the installer does… right?  All I have to do is get that partition into the real boot menu, and it should work, right? …Right??

I rebooted, and Pop!_OS came back up.  I did the mount-and-chroot sequence to get into Kubuntu, and proceeded to replace grub stuff with systemd-boot, efibootmgr, and even kernelstub.  With everything apparently set up correctly, and brazenly ignoring the “24 MB of free space on /boot/efi” warning, I rebooted.  Finally, I had a Kubuntu menu entry available!

The thing is, when Kubuntu booted, it gave me a choice between trying Kubuntu or installing it.  What?  The install media had been unplugged during the initial reboot after failing to install grub.  The only thing I can really figure is that the installer installs the live environment, then sets the boot loader, and only then configures the installed system to “not be the installer.” Somehow.  Maybe because splitting live- and non-live data would make the install media too big.  I guess?

Regardless, I obviously didn’t have a usable Kubuntu install, and little idea about how to make it one from the state we had arrived at.  I was pretty sure it would refuse to reinstall into its own partition, or make any progress.  I gave up on Kubuntu, and shut down the laptop.

Monday, my desktop environment was all messed up.  Most obviously, there were Breeze icons, and some of them were showing a missing-image placeholder.  My work user (non-admin), for complicated reasons, shares the same UID as the default user on Kubuntu, and I was sharing my home directory.  Therefore, my Pop!_OS settings were altered when Kubuntu reconfigured .gtkrc files and dconf entries to make GTK apps “integrate better” with the KDE theme, Breeze.  And by default, Pop!_OS doesn’t have a way to change themes, so I couldn’t put it back without Gnome Tweak Tool.  Or dconf-editor, which I already had installed. 🤷🏻

Deleting newly-added files wasn’t enough; those configure GTK when running outside of a desktop environment.  Most environments have a system to overrule that, which also provides for instant updates of running applications when changing settings.  I think KDE runs just such a daemon?  Couldn’t it override the style for GTK apps only while KDE is running?  Anyway, the point is, the yaks got shaved.  If the install had worked out, I may have never noticed that part.

On the other hand, it is rather annoying that we have arrived at a point where we can’t really “choose a desktop from multiple installed options” anymore, because each one thinks it has to rule over all of them.