Specifying location to be used during Fedora version upgrade

Hi Guys,
wondering if doing version upgrade, e.g. f29 → f30, is it possible to group all the required disk space for this activity under 1 directory?
my use case is like this:
i make a 10g disk space vm guest with f29. then f30 released, then i try to upgrade from f29->f30, but as u guys know, 10g is never enough, so i have to add ‘temp’ disks to cover the changes needed.

so if it is possible to control ‘version upgrade’ activity to 1 directory, then i just add 1 ‘temp’ disk, and after upgrade complete, i just remove the ‘temp’ disk.

what do u think? or any better practice?

Disks are managed by LVM?

yes…but i only have 1 root LV…so after i enlarged it…i can’t shrink it…

And which filesystem?

ext4…(need 20 char len >.^ to reply)

1 Like

Well, as far as I can remember, you can shrink an ext4 filesystem on an LVM volume.
However I need to check.

hm…but my picture is like this…i don’t know if i can lvreduce or not…let’s try to think about it for a moment…
/dev/sda1 - /boot - simple partition
/dev/sda2 - pv1 - vg fedora - lv fedora-root
/dev/sdb1 - ‘temp’ add-on pv - for the ‘version upgrade’ activity

vgextend fedora
lvextend fedora-root /dev/sdb1 or lvresize - i don’t remember
resize2fs /dev/mapper/fedora-root

then do the ‘version upgrade’

then what should i do after ‘version upgrade’? my goal is to remove /dev/sdb1 completely, say ‘detach’ the disk from this vm

Yes, I understand.
Another way could be to identify where DNF put his stuff, and mount /dev/sdb1 in such place.
Sorry, but even if I imagine that such place could be under /var, I don’t know it exactly.

It seems there is a more elegant way, suitable to your specific needs.
man dnf

   --downloaddir=<path>, --destdir=<path>
          Redirect downloaded packages to provided directory. The option has to be  used  together  with  the  --downloadonly  command  line
          option, with the download command (dnf-plugins-core) or with the system-upgrade command (dnf-plugins-extras).

I will try.

1 Like

How much free space do you have in the main disk?
df -h /

i used this approach on my test system…i just monitor by du at the same time downloading by gnome software…
the --downloaddir stuff seems just part of the ‘version upgrade’ process…some download/cache operation is out of ‘dnf’…i guess the reason for that is the stuff has to be retained even reboot

Well, this should be the process:

Supposing that vdb is the additional disk added to the VM:

sudo parted /dev/vdb mktable msdos
sudo parted /dev/vdb mkpart primary 0% 100%
sudo mkfs /dev/vdb1

Get the UUID of the new partition

sudo blkid /dev/vdb1

Edit /etc/fstab

echo "UUID=2e203de8-3825-48de-b0ca-a413d14ace9f /mnt       ext4    defaults        1 2" | sudo tee -a 
systemctl daemon-reload

Mount the new partition

sudo mount /mnt

Do the system upgrade.

sudo dnf system-upgrade download --downloaddir=/mnt --releasever=30
dnf system-upgrade reboot

Specifying --downloaddir=/mnt all the downloaded packages will go there. The entry in fstab will mount the partition after the reboot, in order to retain downloaded packages.

Test it on a spare VM!

Supposing that the upgrade goes well. Then you can umount the additional disk, remove the entry from fstab, run systemctl daemon-reload, halt the VM and detach the additional disk.

1 Like

Aha, Gnome Software, that was the missing component of your original question.

As @alciregi discovered, DNF has suitable options to do what you wanted.

Digression regarding my own stupidity (expand for schadenfreude)

And I wish I’d read that section of the man page, when I needed to get from 4.5G free to 11G free on my F29 system’s root partition so it could complete dnf system-upgrade --releasever=30 download. It would’ve been way better than the method I actually used, which was to:

  • Uninstall a bunch of unnecessary, disk-hogging, multi-megabyte packages (python2-Cython is like 14MB!)
  • Completely blow away /var/lib/mock/ and /var/lib/docker/
  • Run journalctl --vacuum-size=1.5G
  • Finally give up on freeing root partition space, and instead called an audible. I had the partitions on the machine’s full SSD perform a little fancy footwork, all so I could enlarge the root partition by 2GB. I call it the Swap Partition Shuffle, and let me once again say: thank goodness for LVM.

BTW: It’s surprising how irate you can get at the message “DNF needs an additional 117MiB to complete the install” (or whatever the exact text is), when you started at “DNF needs an additional 5.3G…” and it’s now your fourth or fifth attempt to get through the system-upgrade run.

Aaaaanyway, back to your thing…

Gnome Software doesn’t have the same options, and probably never will because doing an upgrade with a custom destination is the sort of “power-user” task that’s intended to be done via dnf system-upgrade, rather than Gnome Software. That’s just not its role.

I can imagine a situation where Gnome Software is changed to always download packages into $HOME/.cache/, instead of allowing them to be downloaded into /var/lib/, and then the install is run from there. That actually makes quite a bit of sense to me, since home partitions generally have a lot more space to play with. That’s the purpose of home partitions in general and $HOME/.cache in particular, whereas a root partition with a ton of empty disk space that’s only used twice a year for upgrades is kind of wasteful.

However, doing it that way could present some pretty significant hurdles for users with network-mounted homedirs, and there are all sorts of other possible issues that would have to be accounted for.

Regardless, even if such a feature were to be implemented, I imagine it would then become the standard/only mode of operation in all cases. (Or all cases where it’s possible, again see the network-mounted-homedirs caveat.) Gnome Software is never going to have a configurable download location, as that’s just not the Gnome Way™.

If you need to perform any sort of customized install/upgrade, such as one that uses a different storage location for the downloaded packages, then Gnome Software isn’t, and is not meant to be, the tool for the job.

that’s why i thought it would be an option only for “version upgrade” activity…not general handling…
i don’t know…is it a good fit? hm…