Nicely Nitpick Noble 24.04 LTS

[NoWorries]

I also did a new installation using an ISO date 8 April on my HP Laptop. I did this installation as I usually do where I define my partitions with the root being formatted Ext4, and my home kept in its btrfs format. To my surprise, a default home was installed and my home directory was given a new name and stored under @home at the location shown in the graphic below.


To get my system back in a way I wanted, I had to cut files out of @home/aurora and past them into aurora. I did not have sufficient disk space to do it in one step but had to do it piece by piece. I have my system back as I want it and the directory @home/aurora is now empty. I have now removed @home/aurora and @home.

I must say that I am puzzled why the system did this and I am wondering if the other odd behaviour cited above is related.

[Schwarzer Kater]

Something I noticed (again) when installing Kubuntu 24.04 LTS development branch/Beta on an ext4 file system today:

In /etc/fstab the options for ext4 file systems are set to "discard" instead of e.g. "defaults".
-> This makes no sense, because the systemd timer fstrim.timer is already running… ^**
So at the moment I would most certainly replace "discard" with "defaults" in those /etc/fstab lines for any Kubuntu 24.04 LTS installation that uses ext4.
I would also add "noatime" for ext4 - but this is another story and far less relevant…

-> As this will effect nearly every installation of Kubuntu 24.04 LTS (because the default is to install on an ext4 file system…) I would consider the "discard" setting in /etc/fstab for ext4 an important issue - what do you think?

PS:
"Normal Installation" still installs the Thunderbird Snap despite not being selected, by the way.

^** = Addition:
From an older post on StackExchange: "[…], you could achieve better performance and data health by Periodic trimming instead of a continuous trimming on your fstab. There is even a in-kernel device blacklist for continuous trimming since it can cause data corruption due to non-queued operations."

[jlittle]

I am using GRUB legacy to boot - no EFI at all...

I'm not sure this would be feasible for you, but let me float an idea...

Can your hardware do a UEFI boot to a USB device? (USB 3 wouldn't be too slow, especially from an SSD.) If so, you could boot in UEFI mode and just not set a device for /boot/efi, and so get no boot loader at all. After booting to the new install you'd want to install the correct grub package if you wanted to use it.

[Schwarzer Kater]

Some news regarding the current Kubuntu 24.04 LTS development branch/Beta :

• Qt has been updated from version 5.15.12 to 5.15.13.
• In case the "Minimal Installation" option still does not install snapd or any Snaps after the final release of 24.04, the get rid of Snap script now takes this into account and offers the possibility to block the future installation of snapd and Snaps by APT pinning even if no snapd or Snaps are installed.
  This may also come in handy for other Kubuntu installations/versions…

[oshunluvr]

Well, according to this documentation last update June 2023, BOOT-BIOS partitions need only be 30KB or larger. So that's probably not the cause of the failure of GRUB installation.

[oshunluvr]

When I've done a manual install I just don't set a location for /boot/efi. It complains but proceeds and doesn't attempt a grub install.

I am using GRUB legacy to boot - no EFI at all.. It simply had a pull-down list of all my fixed drives and had the first drive (nvme0) pre-selected. I actually didn't look extensively at the other options because I don't boot to that drive anyway so no harm in installing GRUB to it. After the first attempt failed, I switch to SDA instead of the NVME drive to see if that was the cause of the failure. The results were the same - both choices resulted in failure - but that when I noticed the unguided change of target devices.

Since I'm booting in legacy mode. The installer did not warn or complain about the EFI partition in my case. It did warn me that using GPT with GRUB meant I needed an 8MB GRUB-BIOS partition for GRUB, which is actually a gross exaggeration. I have a been using GPT with GRUB in legacy mode for many years. My habit is to create the GRUB-BIOS partition in the free sectors not used anymore due to partition alignment, namely sectors 34 to 2047. This results in a 1007KB partition which has been sufficient for GRUB-BIOS.

Now I'm wondering if some artificial limit re. the size of the BOOT-BIOS partition is why it failed or if they've actually modified grub and the amount of space required has changed. My dedicated GRUB install is from 2020 and has been updated in quite awhile.

[Schwarzer Kater]

Thank you for the info!

[jlittle]

The installer failed during grub-install which for me isn't a big deal since I boot to a dedicated grub install. I'm not sure what the problem was with that.

When I've done a manual install I just don't set a location for /boot/efi. It complains but proceeds and doesn't attempt a grub install.

[oshunluvr]

Thunderbird, Firefox, and Firmware-updater are all installed as snaps as well as gtk-common-themes and gnome-42-2204.

As I stated, I did not select any of the options in Calamares. Still Beta-mode so maybe not fully defined as such in Calamares. I mean the slides still show Lubuntu, lol.

[oshunluvr]

let me check...

[Schwarzer Kater]

Did you also get the Thunderbird Snap despite not selecting it in the additional options (but not the Krita Snap, the Element Snap and virt-manager)?
This is what I got with the "Normal Installation" option and the Beta 2024-04-11.

I have not tried today's Daily Build 2024-04-13 to see if something has changed there…

[oshunluvr]

I downloaded this morning's beta ISO and installed it to bare metal to test it out.

I edited Calamares to modify the BTRFS subvolume names as I detailed here and booted to the ISO directly from GRUB - no sense in wasting time making a LiveUSB

The installer failed during grub-install which for me isn't a big deal since I boot to a dedicated grub install. I'm not sure what the problem was with that. I even installed it twice just to see if was the drive in question. It failed both on a hard drive and an NVME drive.

One thing I noticed that I felt was somewhat dangerous about the Calamares installer: On the install partition selection page (manual partitioning), if you select the boot device for GRUB first and then select the partition for the install, it changes the drive for grub install also WITHOUT NOTIFICATION - so be careful here!

Because the grub-install failed, there was no grub.cfg. So I booted to the install from the GRUB console (something ALL OF YOU should learn how to do, LOL) and run "sudo update-grub" to create a config file.

I suspect because the grub install failed and therefore, technically the install failed - when I booted up I was presented with the installer screen - "Try Kubuntu...Install Kubuntu" - rather than the desktop. I found this slightly humorous. I selected "Try..." and found the normal desktop - I was required to log in as expected and my user credentials were present. I spent a few minutes trying to figure out how to remove the installer screen then in a brief flash of clarity I went to System Settings and I changed "Session Restore" to "Start with an empty session" and that seems to have solved the issue.

I did a "Normal" install and did not choose any of the additional options for installation. I ran update after getting the boot situation working and 156 packages were updated. That's where I left it.

[Schwarzer Kater]

UPDATE:

1. "Full installation" - additionally installs:
   - Element (Matrix-based messenger) as a Snap
   - Thunderbird as a Snap
   - Virtual Machine Manager as a "real" .deb
   - Krita as a Snap (!)
   
   - (and by default Firefox and Firmware Updater as Snaps)

I wrote "real" .deb, because in the past Canonical has had the tendency to smuggle in "fake" .debs which then installed the Snap instead (see Firefox or Chromium…).
This could very probably also become the case with Thunderbird, Krita and Element in 24.04 - although I was still able to install Krita directly from the Ubuntu repositories as a "real" .deb.
In contrary Thunderbird and Element are not available (anymore) as "real" .debs directly from the Ubuntu repositories for 24.04.

I will try my best to make it possible to remove and block Snap as easily as it was possible in the Kubuntu versions before and to give the users easily applied alternatives for the removed Snaps with my scripts…

For the Element Snap at the moment I only see the alternative to give the tip to install e.g the Signal messenger instead - any better ideas?

[Montmorency]

what do you think?

I think you're very thorough, thanks.

[TWPonKubuntu]

Schwarzer Kater , thanks for the very good instructions on how to avoid the snap problem.

TWP