I badly need to upgrade my Kubuntu version from the present 18.04
and I know there is a release upgrade command. What keeps me from
doing it is that I worry about choices I have to make during the
upgrade process and not knowing what are best. Any idea what these
might be, and the best choices to make?

Also, I believe I am now two versions behind. Can I actually
do a release upgrade, or do I have to install the latest version
from scratch?
--
Dieter Britz

On 9.2.2023 17.46, db wrote:
> I badly need to upgrade my Kubuntu version from the present 18.04
> and I know there is a release upgrade command. What keeps me from
> doing it is that I worry about choices I have to make during the
> upgrade process and not knowing what are best. Any idea what these
> might be, and the best choices to make?
>
> Also, I believe I am now two versions behind. Can I actually
> do a release upgrade, or do I have to install the latest version
> from scratch?

First, check that you have a 64 bit version:

uname -m

should return

x86_64

The support for 32 bit versions is limited, if any.

Before upgrading, you should check that the old installation
is as far as possible up-to-date:

sudo apt update
sudo apt full-upgrade -y

There is a script called do-release-upgrade:

sudo do-release-upgrade

which does the trick, if your system is eligible.

The long time support version should upgrade to 22.04LTS
without a hitch. I'm not sure about non-LTS versions.

--

-TV

On 2/9/23 12:44 PM, Tauno Voipio wrote:
> On 9.2.2023 17.46, db wrote:
>> I badly need to upgrade my Kubuntu version from the present 18.04
>> and I know there is a release upgrade command. What keeps me from
>> doing it is that I worry about choices I have to make during the
>> upgrade process and not knowing what are best. Any idea what these
>> might be, and the best choices to make?
>>
>> Also, I believe I am now two versions behind. Can I actually
>> do a release upgrade, or do I have to install the latest version
>> from scratch?
>
> First, check that you have a 64 bit version:
>
>  uname -m
>
> should return
>
>  x86_64
>
> The support for 32 bit versions is limited, if any.
>
> Before upgrading, you should check that the old installation
> is as far as possible up-to-date:
>
> sudo apt update
> sudo apt full-upgrade -y
>
> There is a script called do-release-upgrade:
>
> sudo do-release-upgrade
>
> which does the trick, if your system is eligible.
>
> The long time support version should upgrade to 22.04LTS
> without a hitch. I'm not sure about non-LTS versions.

From 18 to 22 ... MAY want to do successive upgrades ...
20, then 22.

Note I had FAILS using the -tu updater for 18->20 ...
it always crashed in the middle of things and it was
necessary to do several manual upgrade steps with
"--fix-missing" to straighten it out. Had three
terminals open and needed them ALL to complete the
steps. Had this experience in plain Ubuntu-svr AND Mint.

Anyway, I don't use the -tu's anymore ... Canonical
is getting way too weird, almost proprietary, and
breaks Deb conventions too often for no obvious gain
or reason. All my servers are moving back to vanilla
Deb now. Deb is GOOD for servers and can be very small
and quick if you don't load in all those "recommends".

Am 09.02.2023 schrieb Tauno Voipio <tauno.voipio@notused.fi.invalid>:

> The support for 32 bit versions is limited, if any.

i386 (technically i686) has been completely discontinued by Ubuntu with
version 19.10.

Use lscpu |grep 64 to find out if it can support 64 bit (x86_64).

Relevant is

CPU op-mode(s): 32-bit, 64-bit

NOT

Architecture: x86_64

This is the arch of the currently running os.

If your CPU doesn't support 64 bit, switch to Debian.

Am 09.02.2023 schrieb db <dieterhansbritz@gmail.com>:

> I badly need to upgrade my Kubuntu version from the present 18.04
> and I know there is a release upgrade command.

sudo do-release-upgrade

> What keeps me from doing it is that I worry about choices I have to
> make during the upgrade process and not knowing what are best. Any
> idea what these might be, and the best choices to make?

Do the upgrade, if some questions about configuration file changes
occur, answer them with Yes until you know that you manually changed
them.

Make sure you enable and change the 3rd party apt repositories for your
packages if you have some enabled.

> Also, I believe I am now two versions behind. Can I actually
> do a release upgrade, or do I have to install the latest version
> from scratch?

Yes, you can upgrade to 20.04 and then to 22.04.

In <ts4ud0$pghd$8@dont-email.me> Marco Moock:

[Snip...]

> i386 (technically i686) has been completely discontinued by Ubuntu with
> version 19.10.

Yes. As a kludge, I was able to use do-release-upgrade to drag
my i686 14.04 and 16.04 LTS installs to 18.04 LTS.

Since I stick to standard repos on my installs that was mostly
just time-consuming, but worked well.

I chatted with Canonical support about that and they confirmed
it won't work after 18.04.

> If your CPU doesn't support 64 bit, switch to Debian.

+1.

I'm doing that eventaually with all my *buntu installs.

FWIW, Canonical dropping i686 wasn't the only reason I decided
to "sunset" my *buntu installs.

I started to notice during the past month or so that *buntu apt
update cycles are dropping some legacy support.

Instead, they're suggesting Ubuntu Pro ("free" for personal use
on 5 boxen, AIUI).

Example, just this morning on an amd64 18.04 LTS install:

Calculating upgrade... Done
The following security updates require Ubuntu Pro with 'esm-apps' enabled:
libopenjp2-7 libgroupsock8 libzip4 okular-extra-backends lynx-common libzmq5
libopenmpt0 nodejs lynx libxerces-c3.2 okular libeditorconfig0
libopenmpt-modplug1 libbasicusageenvironment1 libsoundtouch1 libsdl2-2.0-0
libmysofa0 libokular5core8 nodejs-doc liblivemedia62 libtomcrypt1
libusageenvironment3
Learn more about Ubuntu Pro at https://ubuntu.com/pro
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Anyway, Canonical of course will run their business pretty much
as they see fit but it was the last straw for me. Jez sayin'...

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

Am 10.02.2023 schrieb Harold Stevens <wookie@limbo.localdomain>:

> In <ts4ud0$pghd$8@dont-email.me> Marco Moock:

> > i386 (technically i686) has been completely discontinued by Ubuntu
> > with version 19.10.
>
> Yes. As a kludge, I was able to use do-release-upgrade to drag
> my i686 14.04 and 16.04 LTS installs to 18.04 LTS.

Which CPU do you have?

> Since I stick to standard repos on my installs that was mostly
> just time-consuming, but worked well.
>
> I chatted with Canonical support about that and they confirmed
> it won't work after 18.04.

They announced it years ago. Ubuntu 17.10 ISOs (not Lubuntu and others)
weren't available for i386, but it was possible to sue netinstall
instead.

> > If your CPU doesn't support 64 bit, switch to Debian.
>
> +1.
>
> I'm doing that eventaually with all my *buntu installs.

You need to go away from Ubuntu due to security reasons, so Debian is
one possibility. Slackware is another.
Many Linux distributions discontinued i386/i686 due to the low amount
of users.

In <ts589j$pghd$12@dont-email.me> Marco Moock:

[Snip...]

> Which CPU do you have?

First few lines of lscpu ...

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 17
Model name: AMD Ryzen 3 2200G with Radeon Vega Graphics
Stepping: 0
CPU MHz: 1419.918
CPU max MHz: 3500.0000
CPU min MHz: 1600.0000

> They announced it years ago.

Yes. I wasn't totally unprepared (via do-release-upgrade).

> You need to go away from Ubuntu due to security reasons

Exactly. As I noted: last straw for me and Canonical.

> Debian is one possibility. Slackware is another.

Yes. I have Slackware 14.1 running on two ancient Pentiums.

AFAIK, Slackware 14.x still gets critical security updates.

> Many Linux distributions discontinued i386/i686
> due to the low amount > of users.

Yes, I fully understand that as a business decision.

It's the security aspect that drives my personal choices.

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

Am 10.02.2023 schrieb Harold Stevens <wookie@limbo.localdomain>:

> In <ts589j$pghd$12@dont-email.me> Marco Moock:
>
> [Snip...]
>
> > Which CPU do you have?
>
> First few lines of lscpu ...
>
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit

Do you still have any machine with 32 bit only?

> Yes. I have Slackware 14.1 running on two ancient Pentiums.

Wich ones?

> AFAIK, Slackware 14.x still gets critical security updates.
>
> > Many Linux distributions discontinued i386/i686
> > due to the low amount > of users.
>
> Yes, I fully understand that as a business decision.

It is mostly maintenance and testing.
It is possible to test i686 builds on recent hardware, but errors
related to older ones (like missing SSE* instructions) need old
hardware to test. Many developers don't want that.

In <ts5apc$pghd$13@dont-email.me> Marco Moock:

[Snip...]

> Do you still have any machine with 32 bit only?

Yes, about 10 or so legacy Intel, and an ancient Cyrix.

> Wich ones?

Slackware 14.1 on an ancient Pentium <mumble>, and the Cyrix.

> It is mostly maintenance and testing.
> It is possible to test i686 builds on recent hardware, but errors
> related to older ones (like missing SSE* instructions) need old
> hardware to test. Many developers don't want that.

Exactly. I'm retired, so it's a personal choice for me.

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).