Focal Testing of Kubuntu 20.04 LTS

[NoWorries]

Thanks for the correction. I have removed the reference that ext4 did not journal.

[jlittle]

BTW, IMO using utilities like startup disk creator, mkusb, or the like are a huge, fraught, waste of time and effort, if you're doing multiple installs on the same machine. Just download and boot into the iso using the applicable grub incantation. It can be faster, too, if you download onto an SSD, their being faster than USB media. Writing to a USB is only necessary if the install is to a another machine that has no OS. and even then I usually prefer to just copy the iso to a trusty bootable USB (that has grub installed), using dolphin.

[jlittle]

All I can say is that for a non-journal file system, ext4

That's confusing; ext4 is a journaling file system.

[NoWorries]

For the installation USB I use the KDE startup disk creator. I find that this will allow the installation of Focal on a btrfs file system. My installed system had both the @ and @home areas. Just to check that the startup disk creator would allow an update of the system, I tried another test install and found that if I could select the previous installation.

I am not sure if GG's use of mkusb for the installation usb provides useful options. However his use of mkusb did lead to problems with his installed system. I did install it and was overwhelmed by all the options which made no sense to me, so I decided to stay with the KDE approach.

One feature that I have noticed with btrfs, is the need to copy all files in the @home onto a suitable external storage before installing a new system.

I have now done two separate installations of a Focal system. The first was with btrfs and this installation was then replaced by one with ext4 on my 64GB sandisk. The systemd-analyze command for the Focal btrfs system gave the following:

Startup finished in 3.829s (firmware) + 9.544s (loader) + 2.946s (kernel) + 13.913s (userspace) = 30.233s 
graphical.target reached after 10.340s in userspace

For the Focal system with ext4 I get:

Startup finished in 3.346s (firmware) + 11.210s (loader) + 3.981s (kernel) + 11.130s (userspace) = 29.669s 
graphical.target reached after 11.122s in userspace

From this test, the btrfs is overall faster. My impression is that the login-in is faster with the ext4 system.

I feel that it is up to the Focal installer to decide what file system to use. All I can say is that ext4 gives acceptable performance.

[NoWorries]

Booting up I discovered that unlike the release on the 22nd, the release today, the 24th, runs like molasses. Calling it slow is a compliment.

I may play with it a couple more days and then wait until January or February before I pick it up again.

Sometimes It takes 20 seconds or longer for the DE to respond to mouse clicks or typing ... For all practical purposes the app being used appears to be hung, so one has to be patient.
$ systemd-analyze
Startup finished in 1min 13.776s (kernel) + 2min 48.120s (userspace) = 4min 1.897s
graphical.target reached after 2min 48.110s in userspace
[/console]
When I highlighted that output to copy it into this post it took the left mouse popup 20 seconds to appear.

Because of the problems you have had, I decided to try installing Focal on a 64GB Sandisk that I have. I downloaded the 10-25 version and defined the btrfs file system for it. I also copied all my hidden files (over 100,000 files) from the Laptop SSD Focal system.

The final stage of the Focal install included the Nvidia driver and I also get the message on login about the touchpad being disabled.

I have updated the system and it still responds well for a usb disk. My systemd-analyze gives:

:~$ systemd-analyze
Startup finished in 2.882s (firmware) + 9.407s (loader) + 4.842s (kernel) + 4.272s (userspace) = 21.404s 
graphical.target reached after 4.263s in userspace

As you can see this is only slightly slower than my Laptop system.

I am not sure what I did differently to you in the installation for it to work so well for me.

[NoWorries]

I fully understand. One problem that I have is that I have a VERY HIGH REGARD for the developers ability. From past experience they do an excellent job and a 1 or 2 day glitch does not bother me.

I also understand that you prefer forum members to not use pre-release options. So because I do this as well I am taking a double risk. Since Focal is on my testing Laptop, it does not matter if Focal goes US for a short time.

[acheron]

At the moment, the focal archive is still in a pre-release freeze for 'general development'. Currently the release team and core developers are carrying out major transitions of perl and python versions, and doing other preliminary changes to get things into a workable state to proceed. So please do not expect any stability quite yet.

[NoWorries]

I must say that I am disappointed that you have decided not to proceed with Focal because of the problems you have encountered. I know that you would find it difficult to use Ext4 for your file system, but in your case, it might be best with the limited SSD disk size. After all, with preliminary testing, you do not need recovery options that btrfs provides.

I just tested the installation disk that I made with usb-creator-kde. I could select a SSD that I inserted into my USB 3.0 port. This selection was possible after I chose the manual option for the disk setup section. I did not proceed, but just wanted to check that an SSD from usb-creator-kde would be able to install onto another SSD.

[GreyGeek]

Interesting how similar our systems are.
Mine is a 17" Acer V3-771G with 16GB of RAM and two 500 SSD drives and a 750Gb spinner.
The CPU is identical to yours and my GPU is an NVidia GT 650M.

I installed mkusb, the only tool I know of that makes persistent Live USB installs and installed Focal onto a 64GB Sandisk Thumbdrive. It is a USB 3.0 thumb but my 3.0 USB port won't see it during boot so I can boot from it unless I put it into my USB 2.0 active hub.

With the 10-22 daily release my persistent USB stick would boot in about 90 seconds to a working screen and the DE was very snappy. However, I couldn't change Muon's software sources and changes made to the DE would not persist through a reboot. With the 10-24 daily it is slower than molasses but everything appears to work, eventually. I can change software sources, and changes to the DE do persist.

I'm glad things are working out for you with Focal. I'll probably set it aside for a couple months and pick it up in January.

[NoWorries]

So sorry you are having so many problems with 20.04. I am wondering if your problems relate to installing 20.04 on an SSD. Hopefully you have enough space for it, as my system uses 34GiB and I have a minimal number of files installed in my home directory. I also use ext4 for my file system which does not have space used for a persistence file.

With my Focal system, I have had a totally different experience to what you have reported. When I did my installation, it included the installation of the Nvidia 390 packages. Also, I get the message, Touchpad was disabled because a mouse is plugged in, each time I reboot.

I tried your systemd-analyze message and on my system I get:

Startup finished in 2.227s (kernel) + 6.928s (userspace) = 9.155s 
graphical.target reached after 6.919s in userspace

This is a significant difference to what you get.

I have 20.04 installed on my 7 year old Laptop:
ASUS R501VM Core i7 3610QM
NVIDIA GeForce GT 630M 2GB

I have just successfully added the repository:

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

and I now have KDE Plasma 5.17.1 with KDE Frameworks 5.62.0 and QT Version 5.12.4. As you can see, I am still very happy with the progress of Focal.

[GreyGeek]

I added the line you used and it made no difference.

I downloaded today's release of Focal, checked the sums and installed it on my 64GB Sandisk using 50% of the spare space for persistence, the other for storage.

Booting up I discovered that unlike the release on the 22nd, the release today, the 24th, runs like molasses. Calling it slow is a compliment.

It could be a problem with mkusb, which was updated this morning and during the final phases of creating today's LiveUSB seemed to take forever for the last step, the one that finishes with "Work Done". Too many variable to assign causes.

I may play with it a couple more days and then wait until January or February before I pick it up again.

EDIT:
Since rebooting restored the system to what it was before I attempted the update & upgrade commands, I redid those commands, but used "sudo apt upgrade" instead of "update". It produced dependency and overwrite errors but the two cleanup commands worked and I continued with the the upgrade for an additional 87 apps. Then I did the "sudo apt update & sudo apt full-upgrade", which worked without errors. Then I and rebooted. Persistence is back. From boot to a working desktop took 6 min 30 seconds, so speed is missing in action.

Sometimes It takes 20 seconds or longer for the DE to respond to mouse clicks or typing ... For all practical purposes the app being used appears to be hung, so one has to be patient.

I just opened Muon and was able to edit the software sources and remove the cdrom and add proprietary software and have it update correctly. It also appeared to hang and I just let it set in the background and checked occasionally until it gave me a normal display. During boot up the system kept trying to mount the cdrom, which my laptop does not have. That probably added significantly (at least 70 seconds) to the boot up time.

I opened a Konsole to run systemd-analyze and it took 15 seconds for the Konsole to appear. I entered

$ systemd-analyze
Startup finished in 1min 13.776s (kernel) + 2min 48.120s (userspace) = 4min 1.897s
graphical.target reached after 2min 48.110s in userspace

When I highlighted that output to copy it into this post it took the left mouse popup 20 seconds to appear.

I'm using 20.04 right now, posting this msg. I'm not complaining about 20.04. It is about 6 months away from its April release and there is a LOT of work to do on it. Any, and most likely all, problems I run into at this extremely early stage of its development will be history before April comes around. I installed 9.04 at the end of January, two months before its release, and it ran like a rock star during its entire life. That's just the way Kubuntu is.

But, for now, my curiosity has been satisfied.

[GreyGeek]

Super!
On a Live Persistent USB the option to configure software sources just kicks you back to the main display.

I did the install of the nvidia-driver-390 from the CLI and it returned without errors. When I rebooted none of it persisted.
I saw a notification that 44 apps were in the update queue. Here is the result of "sudo apt update; sudo apt full-upgrade" in a Konsole:

Get:46 http://archive.ubuntu.com/ubuntu focal/main amd64 python3-simplejson amd64 3.16.0-1ubuntu2 [57.2 kB]
Fetched 119 MB in 33s (3,605 kB/s)
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 175173 files and directories currently installed.)
Preparing to unpack .../libtext-charwidth-perl_0.04-9build1_amd64.deb ...
Unpacking libtext-charwidth-perl (0.04-9build1) over (0.04-9) ...
(Reading database ... 175176 files and directories currently installed.)
Removing libnet-dbus-perl (1.1.0-6) ...
Removing libxml-twig-perl (1:3.50-1.1) ...
Removing libxml-parser-perl (2.44-4) ...
Removing ubuntu-minimal (1.440) ...
Removing debconf-i18n (1.5.73) ...
Removing libmailtools-perl (2.21-1) ...
Removing libnet-smtp-ssl-perl (1.04-1) ...
Removing libfile-fcntllock-perl (0.22-3build3) ...
Removing ubiquity (19.10.21) ...
Removing liblwp-protocol-https-perl (6.07-2ubuntu2) ...
Removing libwww-perl (6.39-1) ...
Removing libio-socket-ssl-perl (2.066-0ubuntu4) ...
Removing libnet-ssleay-perl (1.88-0ubuntu1) ...
Removing ubiquity-frontend-kde (19.10.21) ...
dpkg: libhtml-parser-perl: dependency problems, but removing anyway as you requested:
libhtml-tree-perl depends on libhtml-parser-perl.
libhtml-form-perl depends on libhtml-parser-perl.

Removing libhtml-parser-perl (3.72-3build2) ...
dpkg: libtext-iconv-perl: dependency problems, but removing anyway as you requested:
dictionaries-common depends on libtext-iconv-perl.

Removing libtext-iconv-perl (1.7-6) ...
dpkg: console-setup: dependency problems, but removing anyway as you requested:
kbd depends on console-setup | console-setup-mini; however:
Package console-setup is to be removed.
Package console-setup-mini is not installed.

Removing console-setup (1.191ubuntu3) ...
dpkg: keyboard-configuration: dependency problems, but removing anyway as you requested:
xserver-xorg-core depends on keyboard-configuration.
console-setup-linux depends on keyboard-configuration (= 1.191ubuntu3).

Removing keyboard-configuration (1.191ubuntu3) ...
Removing liblocale-gettext-perl (1.07-3build3) ...
(Reading database ... 173838 files and directories currently installed.)
Preparing to unpack .../perl_5.30.0-7_amd64.deb ...
Unpacking perl (5.30.0-7) over (5.28.1-6build1) ...
Replacing files in old package perl-base (5.28.1-6build1) ...
Selecting previously unselected package perl-modules-5.30.
Preparing to unpack .../perl-modules-5.30_5.30.0-7_all.deb ...
Unpacking perl-modules-5.30 (5.30.0-7) ...
Selecting previously unselected package libperl5.30:amd64.
Preparing to unpack .../libperl5.30_5.30.0-7_amd64.deb ...
Unpacking libperl5.30:amd64 (5.30.0-7) ...
Preparing to unpack .../perl-base_5.30.0-7_amd64.deb ...
Unpacking perl-base (5.30.0-7) over (5.28.1-6build1) ...
Setting up perl-base (5.30.0-7) ...
(Reading database ... 175740 files and directories currently installed.)
Removing aspell-en (2018.04.16-0-1) ...
Can't locate Text/Iconv.pm in @INC (you may need to install the Text::Iconv module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debian/DictionariesCommon.pm line 7.
BEGIN failed--compilation aborted at /usr/share/perl5/Debian/DictionariesCommon.pm line 7.
Compilation failed in require at /usr/sbin/update-dictcommon-aspell line 4.
BEGIN failed--compilation aborted at /usr/sbin/update-dictcommon-aspell line 4.
dpkg: error processing package aspell-en (--remove):
installed aspell-en package post-removal script subprocess returned error exit status 2
dpkg: too many errors, stopping
Errors were encountered while processing:
aspell-en
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)


Package management was broken and none of the usual repairs made a difference. So, I rebooted and it was like nothing had happened.
I also notice that none of my previous settings held: konsole configuration, network login, settings in Settings, etc.
So, perhaps:
1) Many features are blocked in LiveUSB installations a/o
2) the mksub persistent installation is not persistent, a/o
3) I do not understand the meaning of "persistent".

I am going to add the line you used to my sources.list and see if it "persists".

[NoWorries]

I have just added the line to my /etc/apt/sources.list file that downloads the proposed files, ie

deb http://au.archive.ubuntu.com/ubuntu/ focal-proposed universe restricted main multiverse

The result was that Muon now works after over 70 updates. I can also add repositories using the command line. So I am now very pleased to overcome the current limitations.

[NoWorries]

I miss wrote my post above. I am on the alpha release.

I am running a persistent Live USB. While I can add or remove apps in the repository it does not allow me to add or remove sources in either Muon of Discover. I haven't tried adding them manually to sources.list yet, and considering what may be missing that I am not aware of I don't think I will try that until the development process is farther along.

I understand that you accidentally mention Beta. I don't even think that Kubuntu now mention the Alpha release.

I should have asked a simpler question regarding Muon. I find that when I go to Settings > Configure Software Sources it asks for a password and then goes into an update. On my Eoan system it gives the following option window.



I don't get this window on my Focal system and I am wondering if you get this window on your Focal System?

[GreyGeek]

I miss wrote my post above. I am on the alpha release.

I am running a persistent Live USB. While I can add or remove apps in the repository it does not allow me to add or remove sources in either Muon of Discover. I haven't tried adding them manually to sources.list yet, and considering what may be missing that I am not aware of I don't think I will try that until the development process is farther along.

The Grub menu has the option to run the Persistent Live USB in RAM. I am going to try that and see how it goes.

When considered that with the fact that the option to disable the touch pad is not present I am wondering if these lacks are by design or just not in the queue at the present.

EDIT: I booted the Persistent Live USB using the boot to RAM option. It took at least 3X as long to get to the desktop. I am currently using 3.08G of 15.5G of RAM. Most of my eight cores are running less than 1% and a 3 or 4 go to 2 or 3% as I am typing I am currently using 73 threads on FireFox and it is snappy, but the thread count is always changing. FireFox is currently using 149.8Mb and Plasma is using 113,8Mb of memory.
So is Ksysguard and Kate, which are also running.

I think I will install the NVIDIA driver tomorrow and see how it goes.

All in all, I am very pleased with Focal. My plan is to switch to it when 20.04.1 comes out, unless 20.04 turns out to be rock solid stable. My first Kubuntu install was 9.04 and that release was rock sold stable for me. Focal, using BTRFS, should carry me through until this laptop dies (it is 7 yrs old) or I stop using a computer. Probably somewhere around 2025.