Share with us your Focal installation/Upgrade Experience

[jdeca57]

After reading that relatively negative review on Distrowatch I decided to upgrade (by force) a 19,10 Laptop and see for myself. It works flawless (not that I tested a lot) but there is no problem with wireless and the system boots fast. Seems that the reviews on Distrowatch aren't that reliable.

[TheFu]

Lest we forget that every new OS has some pain points. Differences can seem painful when they are just different. Humans often need some time to get used to new/different things. People forget the pain when going from Win95 ---> 98 --> 2000 ---> XP ---> Vista. Win2000 was painful. Vista was even worse. There weren't any drivers and old 32-bit drivers didn't work anymore.

The last week, I've seen that some ssh X11 related default options changed that prevented X11 forwarding from working - you know - ssh -X.... commands. Had to modify the /etc/ssh/sshd_config to have this:

X11UseLocalhost no

Seems the default is "yes" now. That was a minor problem, now that it is solved.

Moved my HOME from a 16.04 Lubuntu install to a 20.04 Mate install. Mate doesn't like that at all. Any graphics related anything, even opening a terminal requires 90-120 seconds. Thinking it was conflicting settings, I mv ~/.config ~/.config-old, logged out and logged in again. That didn't help. Still painfully slow. Created a new userid, logged out, logged in and everything under Mate was faster, as expected. Mate is seeking settings outside the ~/.config/ area? Really? Fine. installed fvwm ... logged out, selected the other WM and logged in. All is blazingly fast now.

Time to make a backup and setup automatic, daily, versioned, backups. People in these forums know how I am about that. I have the stock Mate installed, minimal install for Ubuntu and only have a few non-OS installed stuff added. ssh, fail2ban, rsync, fvwm. Need to add rdiff-backup, gem, cpanm, and lshw, so all the information about the current install can be captured to be included in the backups. Modify the backup script for the old system (where HOME came from), so it points at the new 20.04 machine, regulus. Setup the ssh keys for the pulled backups verify the ssh works from the server to this new client - all seems good. Run the script. BAM!

Couldn't start up the remote connection by executing

    ssh -C backups@romulus rdiff-backup --server

On 20.04, rdiff-backup is v2.0.0
On 16.04, the version is v1.2.8.
These are incompatible for a number of reasons, mainly because they changed from python2 to python3, which includes a different serialization method. It is far beyond just a check that v2.0.0 != v1.2.8. So, I need to come up with a way to create backups. But there are about 13 other systems here dependent on v1.2.8, so changing all of those to a newer release really isn't an option.

None of these things are "bad". It is the price of progress. Even the ssh changes are there probably to improve default security levels for things that most people never use - because they don't know any better. Some times differences are just a hassle. Netplan is still a hassle, sometimes. Same for PulseAudio and Systemd-everything and snaps. Someday, I hope a snap package will work for my needs, but alas, I use /tmp/ for .... temporary files ALL-THE-TIME and constrained snaps block that access. I need to create a script that de-constrains snaps.

At this point, I've installed the Server 20.04 about 4 times. Gnome3 Ubuntu about 4 times, the Ubuntu-Mate 3 times - once with ZFS - ouch! I'm not ready for that.

[sudodus]

The last week, I've seen that some ssh X11 related default options changed that prevented X11 forwarding from working - you know - ssh -X.... commands. Had to modify the /etc/ssh/sshd_config to have this:

X11UseLocalhost no

Seems the default is "yes" now. That was a minor problem, now that it is solved.

Thanks for sharing your experiences with 20.04 LTS

I have a question about ssh -X

Both in my current main bionic system and in a new freshly installed focal system I have

X11UseLocalhost yes

by default. Both systems have openssh-server and X11 forwarding works in both directions via ssh -X.

Maybe I misunderstand what you wrote. Do you want X11 forwarding or do you want to prevent it?

Please explain what should work and in which case.

[TheFu]

Thanks for sharing your experiences with 20.04 LTS

I have a question about ssh -X

Both in my current main bionic system and in a new freshly installed focal system I have

X11UseLocalhost yes

by default. Both systems have openssh-server and X11 forwarding works in both directions via ssh -X.

Maybe I misunderstand what you wrote. Do you want X11 forwarding or do you want to prevent it?

Please explain what should work and in which case.

Perhaps it is a 16.04 <---> 20.04 compatibility thing? Skipped 18.04 desktops. The only change was that 1 line on the 20.04 box, restart sshd and started working. I’m still in the mode of using 16.04 desktops (X11 server) to connect into 20.04 X11 clients.

[Dennis N]

15 days after the release date, my Ubuntu 19.10 Virtual Machine's Software Updater informed me that a new release was available. Before accepting the invitation, I made sure the system was up to date. My upgrade procedure is to use Virt Manager to create a clone of 19.10, then update the clone with it's Software Updater. Why: Should the upgrade have a problem, I then have my original 19.10 installation to fall back on while I investigate. But it went without a hitch, there were no post-upgrade fixes needed, except re-selecting the correct display resolution and upgrading some gnome-shell extensions that were not up to date.

Highlights:

Cloning: This was my first time cloning a VM with separate shared data disk used by other VMs. I found that the clone process wanted to clone the data disk along with the OS disk. The solution was to remove the data disk from 19.10's hardware configuration before cloning. After finishing, add the data disk back to both.

Flatpaks and Snaps: Previously installed Flatpaks and Snaps were carried over intact to 20.04 by the upgrade. This was my first OS upgrade involving any Flatpaks, and it was uncertain how they would be treated.

That's all.

[TheFu]

Dennis, be careful accessing the same VM storage concurrently from 2 running VMs.

Attaching a shared disk to multiple guests that are not cluster-aware is likely to cause data corruption because their reads and writes to the disk are not coordinated.

[Dennis N]

Dennis, be careful accessing the same VM storage concurrently from 2 running VMs.

Right. I'm aware of this concurrent sharing problem, but I only run one VM at a time.

[Erik1984]

Upgrade Kubuntu 19.10 --> 20.04 worked quite well. Only thing I had to fix was reinstalling Cantata and mpd. The default music player is (again) replaced. And that is fine but less fine that Cantata was removed during the upgrade. But as I said, easy thing to restore as it's still in the repository.

[mortalkorona]

Here are 2 of my Ubuntu 20.04 LTS (Focal Fossa) experiences/journal/tutorials.

.................................................. .................................................. .............................

2) Laptop Maker: Lenovo

3) Laptop Model: IdeaPad s400u

It works!


* Installing on machine with UEFI.
My Laptop Lenovo IdeaPad journey in wrestling against BIOS/UEFI issues.

.................................................. .................................................. .............................

2) Laptop Maker: Asus

3) Laptop Model: x55sr

It works!


* Installing on machine without UEFI.
Laptop COMPATIBILITY List. - page 179

When booting LiveCD/USB stick this Error will occurr.

Missing parameter in configuration file. Keyword: path

gfxboot.c32: not a COM32R image

To go around that Error do this:

• Press TAB key.
• Type live then press ENTER key.

[sudodus]

...

* Installing on machine without UEFI.
Laptop COMPATIBILITY List. - page 179

When booting LiveCD/USB stick this Error will occurr.

Missing parameter in configuration file. Keyword: path

gfxboot.c32: not a COM32R image

To go around that Error do this:

• Press TAB key.
• Type live then press ENTER key.

Please tell us which tool you used to make the live drive, when you had the problem 'gfxboot.c32: not a COM32R image'. It looks like an old problem, that affected some extracting tools (it was squashed in the Ubuntu Startup Disk Creator version bundled with Ubuntu 16.04 LTS). Has it popped up again in Unetbootin? or some other tool?