Focal Testing of Kubuntu 20.04 LTS

[GreyGeek]

I *NEVER* activate an Internet connection when I do an install. I wait till after I've completed the install and have done my preliminary setup. THEN, I do the usual update-upgrade on a Konsole, install the GPU driver, install my printer, install my special apps, etc. But, I haven't done that since Jan of 2018. I will be doing it in April of 2020 when I install 20.04 on top of BTRFS.

[Don B. Cilly]

I tried again... and failed.
Like last time, as soon as I got to disk setup (very likely coincidental, it's just what it does anyway), I got a rotating cursor for about five minutes after getting to the next screen.
Honestly, I'm not exaggerating. Five full minutes.



After which, the updates notification came up, the system came back to life, and I proceeded.
I told it not to unmount anything - I had a nice partition all ready for it - and went on.

So it said OK, installing.
Detecting file systems... 100%.
Nothing else. I went and did other things, after half an hour, Detecting file systems... 100%.
CPUs close to 0%, everything else working. Installer stuck.

I'll try and put the ISO on another disk, or do the "toram" thing...

[Don B. Cilly]

OK, next time I fire up K18 I will. Thanks.
At the moment, I'm kind of busy redefining steampunk ;·)

Still, unattended-upgrades are a minor annoyance compared to the xapian-cripple at each boot. That is a major one, and should really be addressed, IMHO.

[Snowhog]

In 18.04, launch Muon Package Manager. Click on Settings > Configure Software Sources > Updates and under Automatic updates click on Only notify about available updates and click on Close.

If you use Discover instead, click on Settings, then click on the 'hamburger' icon below Help... and then click on Software Sources then on Updates and do as above.

[Don B. Cilly]

If unattended upgrades are happening, it's because you have it set up to do so.

Actually, I did not. It does it by default. I have K18.04 on the laptop too, it does it there as well.

You can change that.

I looked at how to do it. It said to edit /etc/apt/apt.conf.d/10periodic. I had no such file. Postponed it, moved to Neon, didn't need to anymore.

I have mine set to only notify about available updates. I do all my updates from a konsole.

Neon has it by default. I only had to hide the notification. It's in the "hidden" icons. I use Neon Testing, updates are always there...
And I also do all my updates from a konsole. I have two aliases for it :·)
alias upd='sudo apt update && sudo apt full-upgrade' and
alias kupd='sudo pkcon refresh && sudo pkcon update'

I normally use "upd", I don't quite like pkcon, but I use it sometimes just it case apt misses something. Neon say it can.

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