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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)
