I'm a newbie and I installed Ubuntu 18.04LTS about 5 years ago
separating root, home and my storage files in 3 different partitions of
my hdd. Now I've to switch to 22.04 release and I'd like to prevent most
probable issues I can meet in this upgrading. Here are my questions:

1) What's the size you suggest for my new home partition?
Now my root is 50GB (only 20GB used) and home is 10GB (only 5GB used)
but afaik in new Ubuntu releases there's a different sw management with
snaps so home is much bigger than in the past with the same sw installed.

2) What's the least probably problematic way to get a new ubuntu
22.04lts root from 18.04lts keeping my home as it's now: 2 consecutive
automatic system lts upgrades or just one fresh installation by bootable
usb?

3) Could I keep on using 4.18 kernel with 22.04 Ubuntu?
In the past I've got graphical issues with older kernels (system freezed
sometimes!) and 4.18 kernel solved these issues. I tried a couple of
later kernels (5.*) as well but they were worse so now I'd prefer to
keep on using 4.18 for first then I'll try the latest one (6.*) but I'd
want to be sure I can boot 22.04 choosing 4.18 kernel from my grub as I
do now with 18.04.
I've already downloaded 22.04 and tried it in a live session and it
seems there're no issues, not outright, so I'm quite trustful.

Any other suggestion/correction for my upgrading or new installing will
be appreciated, thanks in advance.

On 2023-11-13, Andy wrote:
> I'm a newbie and I installed Ubuntu 18.04LTS about 5 years ago
> separating root, home and my storage files in 3 different partitions of
> my hdd. Now I've to switch to 22.04 release and I'd like to prevent most
> probable issues I can meet in this upgrading. Here are my questions:
>
> 1) What's the size you suggest for my new home partition?
> Now my root is 50GB (only 20GB used) and home is 10GB (only 5GB used)
> but afaik in new Ubuntu releases there's a different sw management with
> snaps so home is much bigger than in the past with the same sw installed.

How big is the drive overall? Is it really only 60G?

>
> 2) What's the least probably problematic way to get a new ubuntu
> 22.04lts root from 18.04lts keeping my home as it's now: 2 consecutive
> automatic system lts upgrades or just one fresh installation by bootable
> usb?

If you're lucky, you can pull that EOL version up to 20.04, then again
up to 22.04. If you're not lucky, then you'll need to pave over
everything and start over.

>
> 3) Could I keep on using 4.18 kernel with 22.04 Ubuntu?

If you in-place update it, the kernel has the best chance to survive,
else you're going to get 5.15(or thereabouts), with an option for the
6.2 HWE kernel.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 11/13/2023 6:39 AM, Andy wrote:
> I'm a newbie and I installed Ubuntu 18.04LTS about 5 years ago separating root, home and my storage files in 3 different partitions of my hdd. Now I've to switch to 22.04 release and I'd like to prevent most probable issues I can meet in this upgrading. Here are my questions:
>
> 1) What's the size you suggest for my new home partition?
> Now my root is 50GB (only 20GB used) and home is 10GB (only 5GB used) but afaik in new Ubuntu releases there's a different sw management with snaps so home is much bigger than in the past with the same sw installed.
>
> 2) What's the least probably problematic way to get a new ubuntu 22.04lts root from 18.04lts keeping my home as it's now: 2 consecutive automatic system lts upgrades or just one fresh installation by bootable usb?
>
> 3) Could I keep on using 4.18 kernel with 22.04 Ubuntu?
> In the past I've got graphical issues with older kernels (system freezed sometimes!) and 4.18 kernel solved these issues. I tried a couple of later kernels (5.*) as well but they were worse so now I'd prefer to keep on using 4.18 for first then I'll try the latest one (6.*) but I'd want to be sure I can boot 22.04 choosing 4.18 kernel from my grub as I do now with 18.04.
> I've already downloaded 22.04 and tried it in a live session and it seems there're no issues, not outright, so I'm quite trustful.
>
> Any other suggestion/correction for my upgrading or new installing will be appreciated, thanks in advance.

You should give the audience some idea what kind of hardware is involved.

"I've got graphical issues with older kernels"

This is my maintenance USB stick, booted on the Test Machine. Test machine
motherboard about ten years old. When you dump the table for your
machine, you can edit out the bits you don't want to post.

mint@mint:~$ inxi -F
System: Host: mint Kernel: 4.15.0-20-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.8
Distro: Linux Mint 19.1 Tessa
Machine: Type: Desktop Mobo: ASUSTeK model: P9X79 v: Rev 1.xx serial: <root required> BIOS: American Megatrends
v: 4608 date: 12/24/2013
CPU: Topology: 6-Core model: Intel Core i7-4930K bits: 64 type: MT MCP L2 cache: 12.0 MiB
Speed: 3401 MHz min/max: 1200/3900 MHz Core speeds (MHz): 1: 2312 2: 2429 3: 2727 4: 2712 5: 2936 6: 3306
7: 3389 8: 3112 9: 2605 10: 3066 11: 2681 12: 3042
Graphics: Device-1: NVIDIA GP104 [GeForce GTX 1080] driver: nouveau v: kernel
Display: x11 server: X.Org 1.19.6 driver: nouveau unloaded: fbdev,modesetting,vesa
resolution: 1280x1024~60Hz
OpenGL: renderer: NV134 v: 4.3 Mesa 18.0.5
Audio: Device-1: Intel C600/X79 series High Definition Audio driver: snd_hda_intel
Device-2: NVIDIA GP104 High Definition Audio driver: snd_hda_intel
Device-3: Philips s SAA7164 driver: saa7164
Sound Server: ALSA v: k4.15.0-20-generic
Network: Device-1: Intel 82579V Gigabit Network driver: e1000e
IF: eno1 state: up speed: 1000 Mbps duplex: full mac: 11:22:33:44:55:66
Drives: ID-1: /dev/sda type: USB vendor: SanDisk model: Ultra size: 14.53 GiB
Partition: ID-1: / size: 31.42 GiB used: 43.6 MiB (0.1%) fs: overlay source: ERR-102
Sensors: System Temperatures: cpu: 29.0 C mobo: N/A gpu: nouveau temp: 32 C
Fan Speeds (RPM): cpu: 0 gpu: nouveau fan: 977
Info: Processes: 268 Uptime: N/A Memory: 62.85 GiB used: 740.8 MiB (1.2%) Shell: bash inxi: 3.0.27
mint@mint:~$

It could be, that your graphics are sliding out of support.

I did a simulation of a 1804--2004--2204 upgrade, and it went fine
in two stages. It requires returning graphics driver to defaults,
removing PPA from Synaptic, to make the OS more "pure" before upgrade.
Sometimes, it's DKMS stuff which is going to fail on an upgrade
(used for VirtualBox perhaps).

Having backups and being able to roll back the setup, is a valuable
thing to have. That's effectively what a simulation is, is an attempt
to isolate the daily driver working configuration while you figure this
stuff out.

I have done two hops of LTS before. It didn't work the first time.
That's how I figured out I needed to return some things closer to default
conditions, and remove certain kinds of customization, so it would finish.

But my main concern, is with your statements about freezing. And that kernel
number rings a bell. From a long time ago. It sounds like the hardware is
not in the best position for this upgrade. You just know, that newer software
is going to break something. By delaying the upgrade process (because you could
see or sense there would be trouble years back), it is not going to get magically
easier today. The Xorg people are not particularly sympathetic towards
older GPUs for example. They are "no mercy" individuals. We are approaching the
era of Wayland, and you just know your Matrox Millenium is not supported.

I do not want to spoil your fun. I like old hardware. The room is filled with
it. But nobody else likes old hardware, and that is the problem today.
That's why they do stuff, like put SSE instruction set dependencies in
software. Just to be mean.

Doing what you want, is a piece of cake... for some value of cake.
The automation is pretty impressive.

Not all cakes are pleasant to eat (you may have relatives who make
bad cakes for example).

Paul

Sorry for delay.

This is my desktop PC cfg, built back in 2018:
- amd ryzen 3 2200g with Vega 8 integrated graphics;
- msi b450-a pro;
- 2x4gb hyperx predator @2400
- wd black 1tb hdd;
And this is how my hdd is partitioned:
/dev/sda1 1024000 1228799 204800 100M EFI System
/dev/sda2 1228800 1261567 32768 16M Microsoft reserved
/dev/sda3 1261568 103560396 102298829 48,8G Linux filesystem
/dev/sda4 103561216 266242047 162680832 77,6G Microsoft basic data
/dev/sda5 266242048 286722047 20480000 9,8G Linux filesystem
/dev/sda6 286722048 1953523711 1666801664 794,8G Microsoft basic data

As you can see it's a dual boot (Win10/Ubuntu) and sda3 is my root
(50GB, only 20GB used), sda5 is my home (10GB, only 5GB used) and sda6
is a ntfs shared storage partition win/ubuntu (800GB, only 250GB used).
Consider that I've got no other machines nor HDDs so I can only work on
this one after my usual back-up.
I tried to search informations on the web but honestly I didn't
understand how to calculate/establish new sizes for root and home due to
this different snap management in newer ubuntu releases; well in other
words I mean I'd like to establish good "balanced" sizes not to make
them loo large though I've got about 540GB free disk space in sda6 I
could work on. Finally consider I don't think I'll install new sw.

If it could be interesting/necessary I can post my inxi -F, let me know,
but for first I think I need to resize my root and home.

On 11/16/2023 2:57 PM, Andy wrote:
> Sorry for delay.
>
> This is my desktop PC cfg, built back in 2018:
> - amd ryzen 3 2200g with Vega 8 integrated graphics;
> - msi b450-a pro;
> - 2x4gb hyperx predator @2400
> - wd black 1tb hdd;
> And this is how my hdd is partitioned:
> /dev/sda1     1024000    1228799     204800   100M EFI System
> /dev/sda2     1228800    1261567      32768    16M Microsoft reserved
> /dev/sda3     1261568  103560396  102298829  48,8G Linux filesystem
> /dev/sda4   103561216  266242047  162680832  77,6G Microsoft basic data
> /dev/sda5   266242048  286722047   20480000   9,8G Linux filesystem
> /dev/sda6   286722048 1953523711 1666801664 794,8G Microsoft basic data
>
> As you can see it's a dual boot (Win10/Ubuntu) and sda3 is my root (50GB, only 20GB used), sda5 is my home (10GB, only 5GB used) and sda6 is a ntfs shared storage partition win/ubuntu (800GB, only 250GB used). Consider that I've got no other machines nor HDDs so I can only work on this one after my usual back-up.
> I tried to search informations on the web but honestly I didn't understand how to calculate/establish new sizes for root and home due to this different snap management in newer ubuntu releases; well in other words I mean I'd like to establish good "balanced" sizes not to make them loo large though I've got about 540GB free disk space in sda6 I could work on. Finally consider I don't think I'll install new sw.
>
> If it could be interesting/necessary I can post my inxi -F, let me know, but for first I think I need to resize my root and home.

Now, that kit should not be freezing, for a start.
That is not an old system.

You should not be "trapped" with a 4.18 kernel.

If you thought it was memory, you could run memtest, which is
sometimes listed in a GRUB menu as an option.

This is one of my Linux disks, one used for test installs.

[Picture]

https://i.postimg.cc/PrmFBNTX/U2310-size-gnome-disks.gif

Ubuntu 23.10

/var/lib/snapd/snaps <=== qdirstat not listing the right value
gnome-42-2204_141.snap 497.0MB
firefox_3289.snap 240.3MB
firefox_3216.snap 240.5MB
core_16202.snap 105.8MB
/var/snap 11.7MB
firefox
snapd-desktop-integration
firmware-updater
snap-store
core
snapd
gtk-common-themes
core22
gnome-42-2204
gtk2-common-themes
vare
/home/bullwinkle/snap 424KB

So far, I'm not spotting a lot of bloat.

U23.10 total size 21GB (includes my home which is in the partition).

U20.04 total size 16GB

These numbers are meaningless of course.

Make a backup before you start, and away you go.

Paul

The only sure result about the new sizes of root and home in Ubu22.04 is
that the more I search and ask the less I get precise answers :) I think
I'll keep them as they're now (root 50GB, home 10GB) and upgrade only
root to 20.04 and then to 22.04. After that if I see free disk spaces
got too small then I'll resize the HDD. I think that's the most rational
way in my scenario imho.
By the way can you suggest me a safe/reliable sw for partitioning such
HDD (ntfs/ext4)? Could I indifferently use gparted (linux) or easeus
(windows) for this job?

So before starting my upgrades I must do the following things:
- "removing PPA from Synaptic, to make the OS more "pure" before upgrade."
Afaik: synaptic -> repository -> other sw -> untick all the boxes in
there (eg. "http://ppa.launchpad.net/gezakovacs/ppa/ubuntu"); all right?
- "returning graphics driver to defaults"
I've checked in synaptic and there are no "proprietary drivers" in use.
Did you mean this?
- doing something about... "DKMS stuff which is going to fail on an
upgrade"?
Mmhhhh... honestly I don't know "DKMS stuff". What/where must I check?
- Moreover I think it's a good idea to switch off "Tweaks -> Extensions"
(eg. "Ubuntu dock", "Ubuntu appindicators"); do you agree?

I don't want to go OT but... I peeked "linuxmint" partition within your
HDD and I'm too curious to ask you a suggestion for me. I'm a newbie and
I liked to work with Ubuntu 18.04 in this 5 years especially for its
huge community support (very kind and helpful people) but now I dislike
the snap management of newer releases so I'm evaluating to migrate to
Mint. My main concern is that Mint will be more difficult to use for me
and not to find a so wide and helpful community as for Ubuntu, moreover
I don't know if I'll get more hw issues with Mint and if there's a such
big amount of sw as for Ubuntu.

On 2023-11-18, Andy wrote:
> The only sure result about the new sizes of root and home in Ubu22.04 is
> that the more I search and ask the less I get precise answers :) I think
> I'll keep them as they're now (root 50GB, home 10GB) and upgrade only
> root to 20.04 and then to 22.04. After that if I see free disk spaces
> got too small then I'll resize the HDD. I think that's the most rational
> way in my scenario imho.
> By the way can you suggest me a safe/reliable sw for partitioning such
> HDD (ntfs/ext4)? Could I indifferently use gparted (linux) or easeus
> (windows) for this job?

Either "should" work (probably). I'd lean more towards gparted being
safer (but then I haven't touched windows tools in over a decade).

As always, ensure you have a recent backup before messing about with
partition resizing.

>
> So before starting my upgrades I must do the following things:
> - "removing PPA from Synaptic, to make the OS more "pure" before upgrade."
> Afaik: synaptic -> repository -> other sw -> untick all the boxes in
> there (eg. "http://ppa.launchpad.net/gezakovacs/ppa/ubuntu"); all right?

yes.

> - doing something about... "DKMS stuff which is going to fail on an
> upgrade"?
> Mmhhhh... honestly I don't know "DKMS stuff". What/where must I check?

Drivers -- usually wifi or graphics will trip you up on major upgrades.

> - Moreover I think it's a good idea to switch off "Tweaks -> Extensions"
> (eg. "Ubuntu dock", "Ubuntu appindicators"); do you agree?
>
> I don't want to go OT but... I peeked "linuxmint" partition within your
> HDD and I'm too curious to ask you a suggestion for me. I'm a newbie and
> I liked to work with Ubuntu 18.04 in this 5 years especially for its
> huge community support (very kind and helpful people) but now I dislike
> the snap management of newer releases so I'm evaluating to migrate to
> Mint. My main concern is that Mint will be more difficult to use for me
> and not to find a so wide and helpful community as for Ubuntu, moreover
> I don't know if I'll get more hw issues with Mint and if there's a such
> big amount of sw as for Ubuntu.

LinuxMint is essentially "ubuntu, except a little different" (e.g. no
snaps by default; default DE is Cinnamon, etc.). It'll need a complete
reinstall (as opposed to an in-place upgrade), but otherwise it's pretty
much Ubuntu Jammy with some extras on top.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 11/18/2023 10:43 AM, Andy wrote:
> The only sure result about the new sizes of root and home in Ubu22.04 is that the more I search and ask the less I get precise answers :) I think I'll keep them as they're now (root 50GB, home 10GB) and upgrade only root to 20.04 and then to 22.04. After that if I see free disk spaces got too small then I'll resize the HDD. I think that's the most rational way in my scenario imho.
> By the way can you suggest me a safe/reliable sw for partitioning such HDD (ntfs/ext4)? Could I indifferently use gparted (linux) or easeus (windows) for this job?
>
> So before starting my upgrades I must do the following things:
> - "removing PPA from Synaptic, to make the OS more "pure" before upgrade."
> Afaik: synaptic -> repository -> other sw -> untick all the boxes in there (eg. "http://ppa.launchpad.net/gezakovacs/ppa/ubuntu"); all right?
> - "returning graphics driver to defaults"
> I've checked in synaptic and there are no "proprietary drivers" in use. Did you mean this?
> - doing something about... "DKMS stuff which is going to fail on an upgrade"?
> Mmhhhh... honestly I don't know "DKMS stuff". What/where must I check?
> - Moreover I think it's a good idea to switch off "Tweaks -> Extensions" (eg. "Ubuntu dock", "Ubuntu appindicators"); do you agree?
>
> I don't want to go OT but... I peeked "linuxmint" partition within your HDD and I'm too curious to ask you a suggestion for me. I'm a newbie and I liked to work with Ubuntu 18.04 in this 5 years especially for its huge community support (very kind and helpful people) but now I dislike the snap management of newer releases so I'm evaluating to migrate to Mint. My main concern is that Mint will be more difficult to use for me and not to find a so wide and helpful community as for Ubuntu, moreover I don't know if I'll get more hw issues with Mint and if there's a such big amount of sw as for Ubuntu.

Ubuntu and Mint rely on the Debian Tree.

Canonical fixes up Debian packages and makes them more palatable.

In some cases, Canonical "aligns" packages, where normally ordinary
users would not know which library versions belong together. When I
needed to rebuild FFMPEG so NVDEC and NVENC would work, all of the
packages I switched on to do the rebuild, lined up. Canonical refused
to compile NVDEC and NVENC into their version of FFMPEG (NVidia problem),
but they made sure that the package I switched on, was the right version to
add those two functions. That's called "curation". And it has value. It might have
taken a number of hours for me to work through the ./configure output,
but once done, the build worked. I had tried this on a previous occasion,
and some of the packages weren't the right versions and so on. When a thing
is curated properly, it's so much nicer.

Mint uses Ubuntu packages, when they are available and follow Mint policy.
For example, if Ubuntu had Firefox.deb and Firefox.snap, that would be ideal,
as Canonical could offer only Firefox.snap in Ubuntu, and Mint could reuse
Firefox.deb.

But in some cases, Ubuntu only has package.snap and does not have package.deb
and then Mint has to do something about that.

Mint gets one of its package, straight from Mozilla as far as I know.
That solves the Snap problem for that one.

In every case, there are accommodations to be made. For example,
Google Earth Pro cannot be put in the tree. The source is not available
as far as I know, so it is in effect, a binary blob. I think that
was handled, by Synaptic installing a PPA pointing to a Google repository.

The software that allows a Hollywood DVD to be ripped, it can't stay in the
Repository either (legal implications). There is some script in the Repository,
which connects to some server somewhere, to "acquire" a copy of the necessary package.
The same might have been done for MP3 LAME, while that had patent issues.

The tree then, is mostly Debian (25000 packages), but the odd thing is not
Universe or Multiverse material, breaks some rule, has unclear licensing. All the
software in the tree, fits into neat little categories. The OS installer considers
some of these things too, when it decides whether an item is installed by
default or not.

*******

I wasn't trying to "bake you a cake" when I mentioned things like DKMS.
I wanted to pass to you, the "general principle". That is, upgrading
from 18.04--20.04--22.04 works fine, as long as the materials being manipulated,
are standard Repository items. For example, Driver Manager is a separate package,
and the question would be, does the package that does Upgrades, have the Driver
Manager logic in it ? If you think that is not the case, that's why you would
remove the custom driver and return to the FOSS Nouveau (what a lot of OSes use,
without special instructions).

I don't think anyone, gets an Upgrade to go right the first time. But,
if you put on your thinking cap, spot the non-standard things that the
tree logic can't handle, or use your knowledge of "stuff that has gone out of support",
you would not leave an orphan item in the tree, just so it can cause problems
during migration. Maybe VirtualBox X is supported on kernels 5.18 thru 5.22,
and if the upgrade was to kernel 5.23, then it could be that the VirtualBox
package causes a problem. I do not know whether anything has taken the place
of DKMS, to make that aspect easier or not.

The migration process should do Dependency analysis and by doing so,
it spots packages that are no longer used or needed, and those
can be removed. And that's what helps bring down the install size
so the size is not "exactly double" or anything.

Whether you're on Windows or Linux, you should always have backups, then
if a procedure does not work out, you can roll back and try again.
I'm actually pretty lazy when it comes to backups (if I back up the
entire computer room, that takes all day, so it's not a trivial matter).
But certainly, right before any item in here is upgraded, I make a backup,
and as long as the OS partition is small, it does not take long to do a
backup. I select file system types that are "broadly compatible", so
I'm never left in a situation where I can't retrieve something I need.

GParted is fine for move/resize. It may assert the Dirty Bit on NTFS,
so the next time Windows boots, Windows will use CHKDSK to verify
the file system is OK. On Windows, Paragon Partition Manager 14 Free,
can be used for Move/Resize. But that has a few rough edges. The Windows OS itself
has Shrink/Extend but the OS does not have anything to move the origin
of a partition. Consequently, nothing constitutes complete partition management
there. I carry out some operations (moving things), by using commercial backup/restore
software.

The Windows "diskpart.exe" utility, is like diskmgmt.msc (Disk Management GUI), but
it has a few extra functions inside it. Getting Windows to make four Primary
partitions, and not screw around with Extended/Logical, that can be an annoying
challenge at times. Diskpart can make partitions and format them. You can watch
in Diskmgmt.msc , and if an Extended/Logical was made when you didn't want that
to happen (you can tell from the colors in the GUI), you can instantly erase
what you just made and try again.

A lot of the Windows users, simply rely on the automation to do the right thing,
but... that's a mistake :-) If you're multi-booting, you need more capability
than the basic OS comes with.

Paul