Focal Testing of Kubuntu 20.04 LTS

[Snowhog]

it does unattended-upgrades in a way that makes Windows look almost sensible...

If unattended upgrades are happening, it's because you have it set up to do so. You can change that. I have mine set to only notify about available updates. I do all my updates from a konsole.

[jglen490]

It's alpha. ALL the bugs are showing up. I wouldn't worry about it.

Let the devs know, but it's way too early to even think that this is what it looks like.

As for updates, my system is very polite. I get the notice, and it waits until I go into konsole and do my sudo apt thing. About the only thing that actually auto-updates on my system is FF

I wouldn't even dream of jumping into Neon

[Don B. Cilly]

But Kubuntu 18 is an absolute rock. I'm not disputing that.
It's how it deals with updates that makes it so annoying as to almost want to ditch it.
At first install, it's unusable for about twenty minutes.
Then at every boot, it's really sluggish for about five. See here.
It updates the xapian index at the most inopportune moments - and takes ages and way too many resources to do it, it does unattended-upgrades in a way that makes Windows look almost sensible...

So in fact I have ditched it. For Neon.
Neon does do the xapian updates, but not at boot, it waits opportune intervals, and uses very little resources for it.
It does not have unattended-upgrades anywhere. It's a K18 without the hassle.

So I was hoping 20.04 had taken this - absolutely glaring - fault into account, looked at how Neon does it, and improved it.
From what I'm seeing so far, it's making it even worse. I mean, I don't remember the K18 installer doing the xapian-freeze.
And how does that make any sense anyway? Render an installer unusable for minutes on end to check for updates? Before installing?

[jglen490]

If it wasn't for bad luck, you'd have no luck at all ...

Really? 18.04 has been an absolute rock for me. It's been almost boring, it's so good

But I am looking forward to a "permanent" 20.04 installation. I love me some LTS.

[Don B. Cilly]

You know... I almost installed 20.04. At 4 AM, bout of insomnia.
But then, first it did what pisses me off most that Kubuntu does. The dreaded xapian-discover-unattended-system-cripple.
Which means that I (double - honestly, I have to double - click ))·: Install Kubuntu, get to the disk setup, and bam, freeze-dry-vacuum. For over two minutes. No explanation. Ksysguard showed all 4 cores at 100%.

And sure enough, when it unfreezed, the Discover notification came up, Updates available. On an installer? Really?
Then the disk setup finally came up... with the cilly warning.

So I decided 4 AM with lack of sleep and inflated gonads wasn't the best time to do it.

But it doesn't bode well, does it.
18.04, I was glad I switched to Neon because it so annoyed me.
It always slows to a crawl less than a minute after boot, and lasts forever. Neon does not do that. It deals with updates sensibly, not crippingly.
And certainly not just after booting.

Boy, the other day, I fired up Kubuntu 18.04 to... check some things (hadn't used it for a while), went to reboot - into Neon - and... Unattended upgrade in progress. Do not switch off the computer.
Honestly, I said, have I booted into Windows? I don't have any Windows...

[GreyGeek]

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.

Exactly, just as Oshunluvr and I discussed. Here is my entry to 40_custom...

menuentry 'focal-desktop-amd64 ISO -Live' --class iso {
set isofile="/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 'neon-user-20191205-1116 ISO -Live' --class iso {
   set isofile="/neon-user-20191205-1116.iso"
   loopback loop (hd0,1)$isofile
   linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
   initrd (loop)/casper/initrd.lz4
}

I mount my BTRFS <FS_ROOT> to /mnt and then copy the iso's there.

474 mount -t btrfs /dev/disk/by-uuid/35014dcc-2b24-4bab-a13b-8c8aabf59ce9 /mnt
475 mv /home/jerry/Downloads/focal-desktop-amd64.iso /mnt/focal-desktop-amd64.iso
476 mv /home/jerry/Downloads/neon-user-20191205-1116.iso /mnt/neon-user-20191205-1116.iso
477 sync
478 umount /mnt
479 exit

[Don B. Cilly]

Bingo!. [SOLVED]
Thing is. Shouldn't update-grub say something like:
Found Ubuntu 20.04.2 LTS (20.04) on /home/not/Downloads/focal-desktop-amd64.iso ?
Well, it didn't say anyhing about finding any 20.04 anywhere... so I assumed... and what was that about assumption being the brother... mother... any other... ;·)

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

And sure enough, the grub entry was there, but it complained that vmlinuz.efi was not found.
So I checked the iso, no . efi, re updated-grub and... it works :·)

Thank you.

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

[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 :·)

[PerfMonk]

Nice!
Thanks!

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

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

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

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

[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