Focal Testing of Kubuntu 20.04 LTS

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

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

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.

[jlittle]

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

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

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

[NoWorries]

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

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

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

[Don B. Cilly]

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

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

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]

I've been testing various prefixes to the iso file so that the system can find them from the menuetry setup. All have failed.

So, I read about the grml-rescueboot option:

To use the grml-rescueboot option:

1. [*=left]Install grml-rescueboot
   
   sudo apt-get install grml-rescueboot
   [*=left]Place bootable ISO files in the /boot/grml folder.
   • [*=left]Since this is a system folder, the operation must be conducted as "root". For example, if the ISO is located in the user's Downloads folder, the command would be:
     [*=left]sudo mv ~/Downloads/<filename.iso> /boot/grml/
   
   
   [*=left]Update GRUB
   [*=left]sudo update-grub

It, too, failed, with the same type of error as the previous attempts. Even the system generated boot process can't find what it needs to successfully boot the iso and bring up the desktop.


The problem is in the requirement to use "/@" as the path prefix. You can do that inside 40_custom, as shown above, but the path prefix doesn't stick when the boot process tries to find the loop devices, which should be /@/dev/loop0", since the only way the grub menu can find the iso is with
"set isofile="/@/mnt/iso/focal-desktop-amd64.iso"

Changing any or all of the "loop" references, regardless of which ones or which order, to "/@/dev/loop0", or similar prefixes, and I tried every prefix I could thing of, does not work.

BTW, the iso check sum was verified and I have a live USB stick made from it that boots successfully.

[jlittle]

I'm sorry, I should have checked out what I was suggesting, before I suggested it. Problems with iso booting in the testing phase seem common; in that the eoan daily isos could not iso boot, due to a casper script mismatch, for a long time.

For the focal iso, I stumbled onto a workaround:

1. When one gets the "can't get info on device" busybox error, press control-d.
2. One then gets a different busybox error.
3. Run the command "mount -o loop /cdrom/casper/filesystem.squashfs /filesystem.squashfs"
4. Press control-d.

I don't understand what goes wrong at all. Possibly there's an improved grub incantation for focal to sort the loop device error, but it's a mystery to me.

[jlittle]

From a wider focal fossa testing perspective, I'd like to report the iso boot problem, and the workaround, somewhere, somehow, and I've wasted far too much time searching launchpad to find the right way to create a bug. Launchpad seems very oriented around packages, and I don't know what package is involved.

Can anyone tell me the best way to report a problem with the 20.04 iso?