Focal Testing of Kubuntu 20.04 LTS

[GreyGeek]

Since this is a Focal thread, I noticed a while ago that when I attempted to install "kde-config-systemd" muon wanted to remove the Kubuntu-desktop and systemsettings.


I rebooted into what was supposed to be a "persistent" focal installation and got:

Processing triggers for man-db (2.9.0-1) ...
Processing triggers for libc-bin (2.30-0ubuntu2) ...
Processing triggers for linux-image-5.3.0-24-generic (5.3.0-24.26) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs is disabled since running on read-only media
kubuntu@kubuntu:~$

So, probably my stanza for a persistent install is wrong.

[acheron]

Since this is a Focal thread, I noticed a while ago that when I attempted to install "kde-config-systemd" muon wanted to remove the Kubuntu-desktop and systemsettings.

Yes, because it is a dead project that needs removing in debian and Ubuntu, and also supplies files that directly conflict with new systemsettings.

Until it is removed in Debian and then in Ubuntu, the conflicts has to be there to prevent people installing it.

[GreyGeek]

Yes, because it is a dead project that needs removing in debian and Ubuntu, and also supplies files that directly conflict with new systemsettings.

Until it is removed in Debian and then in Ubuntu, the conflicts has to be there to prevent people installing it.

mmm... too bad. Back to the cli.
https://wiki.archlinux.org/index.php...md#Using_units

But, I have no clue as to how many of those CLI commands actually work, until I happen to need one and try it out.


The systemd ui was an app that I really appreciated and it is the only GUI which allowed GUI manipulation of services, unit and config files. I controlled my system from the systemd ui. For example, I used it to create an IPv6 tunnel through Hurricane. Easy as pie to set up with the systemd ui. in /systemd/system it put

he-ipv6.service

[Unit]
Description=he.net IPv6 tunnel
After=network.target


[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/ip tunnel add he-ipv6 mode sit remote w.x.y.z local 192.168.11.100 ttl 255
ExecStart=/bin/ip link set he-ipv6 up mtu 1480
ExecStart=/bin/ip addr add 2001:y:z::2 dev he-ipv6
ExecStart=/bin/ip -6 route add ::/0 dev he-ipv6
ExecStop=/bin/ip -6 route del ::/0 dev he-ipv6
ExecStop=/bin/ip link set he-ipv6 down
ExecStop=/bin/ip tunnel del he-ipv6


[Install]
WantedBy=multi-user.target

That created what appeared to FireFox and Chromium to be a "native" tunnel that made IPv6 the default with a fall-back to IPv4 in less than a second.
On https://ipv6-test.com/ I got a 20/20 rating.

Using the systemd ui was certainly easier than using netplan to set up the IPv6 tunnel, or using a script after the desktop displayed, or doing it by hand, all of which I used at one time or another until the systemd script.

So sad that Ragnar abandon both the KDE project and his systemdgenie project and disappeared in Japan.

[GreyGeek]

Since this is a Focal thread, I noticed a while ago that when I attempted to install "kde-config-systemd" muon wanted to remove the Kubuntu-desktop and systemsettings.


I rebooted into what was supposed to be a "persistent" focal installation and got:

So, probably my stanza for a persistent install is wrong.

Answering my own dilemma:
A persistent ISO boot from the Grub2 menu can only occur IF the ISO sees an EXT4 partition or file that contains casper-rw.
https://help.ubuntu.com/community/Gr...OBoot/Examples

When you have a partition with the label casper-rw (or a file with the name casper-rw) containing an ext file system, it will be found during boot and serve as container for persistence. In an internal drive (HDD or SSD) ext4 is recommended. Persistence with a partition will work, when booted via grub and an iso file.
So add the boot option persistent into the 'linux' line:

Ergo, even it casper-rw existed a persistent ISO boot wouldn't happen because I am using BTRFS, not EXT4.
Also, for releases 19.10 and later the initrd exists as initrd, not initrd.lz, like in previous releases.

[NoWorries]

On a slightly different topic, if you want KDE Frameworks Version 5.65.0, you can get it by adding the ppa

sudo add-apt-repository ppa:kubuntu-ppa/staging-frameworks

I haven't had any problems with it and I like the improved graphics. I have yet to checkout how Wayland is progressing as I noticed a few Wayland packages in the updates.

[Radcliff]

Fresh Install today's build

New Kernel From Proposed (88 packages)

Operating System: Kubuntu 20.04
KDE Plasma Version: 5.17.4
KDE Frameworks Version: 5.64.0
Qt Version: 5.12.5
Kernel Version: 5.4.0-8-generic

ls /lib/modules
5.4.0-8-generic  5.5.0-050500rc1-generic

With BTRFS partitions, System Settings crashes at Application Style>Gnome/GTK to Windows Decoration>DrKonqi. Not present with Ext4.

Gufw (19.04.0) generates an error with the taskbar shortcut.

Unable to run the command specified. The file or folder python3 does not exist

Must be re-open from the Kmenu. Pin to favorites and then to taskbar works.

[PerfMonk]

Where are we suppose to post for problems with focal. I just installed on a USB key and I had problem booting. Booted in rescue mode and "apt upgrade" and then could boot in a terminal and graphic could be started with "startx" on command line. I'm not complaining, it's a development version and we are soon in the process. Also I can't set my "online account" there is a message saying "error loading qml file, module org.kde.account not installed".

Sorry for the noise, but let me know where I should post for the focal fossa version.

Regards,
BT

[acheron]

Also I can't set my "online account" there is a message saying "error loading qml file, module org.kde.account not installed".

Fixed soon I hope: https://launchpad.net/ubuntu/+source....12.0-0ubuntu2

[GreyGeek]

Returning to the topic "booting an ISO from the grub menu" I have found that doing so makes it VERY easy to update an ISO to the latest release. After downloading it merely copy it to the location the 40_custom grub entry expects it to be. No need to burn USB sticks or CDROMS.

Also, since I am using BTRFS, I store the ISO's in the <FS_ROOT>, along side @ and @home. So, snapshots never contain the ISO's I am testing, as long as I move them and don't copy them. Win-Win!

[Snowhog]

After downloading it merely copy it to the location the 40_custom grub entry expects it to be.

By default, 40_custom doesn't contain anything except:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

So you have to specify, in this file, where you want the downloaded .iso file to reside at.

[jlittle]

With BTRFS partitions, System Settings crashes at Application Style>Gnome/GTK to Windows Decoration>DrKonqi. Not present with Ext4.
...

I tried to reproduce your problems, installed onto a btrfs from an iso zsynced today, but could not. The same versions except that the frameworks version is 5.65.0. I last synced a couple of days ago, but still had to download ~200 MB so things seem active.

Gufw (19.04.0) generates an error with the taskbar shortcut.

I'm not sure what you mean by that; I didn't get a taskbar shortcut till I put one there myself. I tried various ways to start gufw with no trouble.

[jlittle]

Returning to the topic "booting an ISO from the grub menu" I have found that doing so makes it VERY easy to update an ISO to the latest release. After downloading it merely copy it to the location the 40_custom grub entry expects it to be. No need to burn USB sticks or CDROMS.

I use some grub script that makes a submenu of all the isos in my download directory; not even a copy. (A complication is that all the *buntus use the same file name "focal-desktop-amd64.iso" so I set up links into subdirectories.) Though...

Also, since I am using BTRFS, I store the ISO's in the <FS_ROOT>, along side @ and @home. So, snapshots never contain the ISO's I am testing, as long as I move them and don't copy them. Win-Win!

That's a handy tip, I hadn't thought of that. A directory from the fs root would do. I've been moving them to an old hard drive for that reason, but booting an iso from an SSD is significantly faster. I imagine zsyncing on the SSD to get the latest will be faster too.

[PerfMonk]

Nice!
Thanks!

[Don B. Cilly]

Returning to the topic "booting an ISO from the grub menu" I have found that doing so makes it VERY easy to update an ISO to the latest release. After downloading it merely copy it to the location the 40_custom grub entry expects it to be. No need to burn USB sticks or CDROMS.

Trying to get this to work...
I make an entry in the 40_custom file in /etc/grub.d/
Like this:

#!/bin/sh
exec tail -n +3 $0
menuentry "Kubuntu 20.04 ISO" {
     set isofile="/home/not/Downloads/focal-desktop-amd64.iso"
     loopback loop (hd2,2)$isofile
     linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile noprompt noeject
     initrd (loop)/casper/initrd.lz
}

The ISO is (in Downloads) on sdc2. So hd2,2, right?
I update-grub. No mention of 40_custom or Kubuntu 20.04.
I check the initrd.lz entry. It's called plain initrd. I amend the entry. Update.grub. No mentions.

I groogle around to see if grub has to be specifically instructed to source 40_custom. Everybody and their grannies insist it does not.
I check if it's excusable executable. It is.
I copy it to /etc/default/grub.d/ because that is where 99_breeze-grub.cfg is and grub sources that.

I realise I'm doing something wrong but I can't guess what it is. I ask :·)

[jlittle]

Trying to get this to work...
I make an entry in the 40_custom file in /etc/grub.d/

The way to see if the 40_custom mechanism is working is to look in /boot/grub/grub.cfg. It says don't edit it, but no-one says don't read it. With my 40_custom saying

#!/bin/sh
exec tail -n +3 $0
menuentry "Kubuntu 20.04 ISO" {
set isofile="/iso/kubuntu/focal-desktop-amd64.iso"
loopback loop (hd1,6)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
initrd (loop)/casper/initrd
}

after sudo update-grub, near the end of /boot/grub/grub.cfg I see

### BEGIN /etc/grub.d/40_custom ###
menuentry "Kubuntu 20.04 ISO" {
set isofile="/iso/kubuntu/focal-desktop-amd64.iso"
loopback loop (hd1,6)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
initrd (loop)/casper/initrd
}
### END /etc/grub.d/40_custom ###

and it works. Note that it says "vmlinuz" not "vmlinuz.efi".

BTW, using fixed device numbering will likely bite back one day. I suggest setting simple, meaningful labels on your partitions (using, f.ex. "KDE Partition Manager"). The partition in my example is called "iso", and the loopback line becomes

search --no-floppy --set=root --label "iso"
loopback loop ($root)$isofile

<stuck record mode>Of course, IMO these /etc/grub.d scripts are a mess and far more trouble than they're worth. IMO it's much easier to just edit a simple grub.cfg yourself. The trickiest part is stopping all those over-clever scripts from messing with my simple set up.</stuck...>