Focal Testing of Kubuntu 20.04 LTS

[Don B. Cilly]

Well, if you've read the thread I referred to, you might agree that incantations like grub or debootstrap are absolutely unnecessary.
All it would take would be one developer who knows a little about how *buntus are actually installed, and an appimage/bin/exe would be there in a whiff.
Because if you uncompress a *buntu iso and unsquash the squashfs. you'll see that to modify the installer (calamares would be a good start) just enough, it would be a whiff to write. For Mac, Windows, and Linux.

[GreyGeek]

This absurd fixation of developers on using live media for everything will end... eventually.

That's pretty much what jlittle was talking about when he referred to grub incantations. Following his lead I found an Ubuntu web page discussing how to do that, which I linked above. I saved the focal iso to /mnt/iso and I then modified an example entry for 40_custom under /etc/grub.d as follows:

menuentry "focal-desktop-amd64 iso - live-only" {
   set isofile="/@/mnt/iso/focal-desktop-amd64.iso"
   loopback loop (hd0,1)$isofile
   linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
   initrd (loop)/casper/initrd
}


menuentry "focal-desktop-amd64 iso - persistent" {
   set isofile="/@/mnt/iso/focal-desktop-amd64.iso"
   loopback loop (hd0,1)$isofile
   linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile persistent noprompt noeject
   initrd (loop)/casper/initrd
}

Then I ran "sudo update-grub".

When I tried to fire the "live-only" menu entry it gave me:


When I added "/@/dev/" to the loop reference, "/@/dev/loop", it reported that it couldn't find the kernel.
I can't connect "/@" to initramfs in the menuentry.
I'm at a catch-22.

[Don B. Cilly]

This absurd fixation of developers on using live media for everything will end... eventually.

[GreyGeek]

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.

Would you elaborate: "boot into an iso using the applicable grub incantation." Using grub on a live system to boot into an ISO residing on that live system? Or, are you referring to using the mount command with the -loop parameter?
Never mind.
https://help.ubuntu.com/community/Gr...ER%20or%20F10.

In 20 years of using Linux that is something I never did or even knew of.

[NoWorries]

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.

The only reason I was taking the approach that I did was because GG was having trouble with Focal on his 64GB usb using mksub for a btrfs file system. His problem was reported #12 on this forum.

[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.