mintupgrade doesn't ask for enough space in low disk conditions

[zahlman]

Mintupgrade version: 2024.01.12 Attempted upgrade: 20.3 -> 21 Steps to reproduce: on a system where /home is separated out to a large partition and a smaller one is used for /, load up the latter such that around 4GB or so of free space remains, then run mintupgrade. If the "update simulation" complains that there is not enough disk space, free up only enough space to satisfy the tool.

Expected result: the tool should be able to work with the amount of space that it requested.

Actual result: on typical setups, the process will fail with no meaningful guidance in the gui and tons of scary output in the terminal window, and take quite a long time before waiting for user intervention.

The apparent cause is that mintupgrade only computes (really, it trusts apt) the space needed to download and install the packages. It doesn't account for the fact that, after this process, it will need to build the kernel and set up initramfs, and these steps will put several hundred MB of data into /tmp. Presumably, users could avoid the problem by e.g. having /tmp mounted on tmpfs, but:

• this isn't the default for Mint
• there's no suggestion to do so
• it would be hard to guide users through at this point (even the ones advanced enough to set up the / and /home partitions this way in the first place)

The installer also doesn't account for the system logs that will be generated in /var/log/journal as part of the process, which could also add up to a significant amount.

Possible mitigations:

• Just add a suitable amount to the expected/requested disk space for the upgrade. Better yet, check whether /tmp is mounted on the same partition as /, and only add extra space in this situation. Explain in the GUI why this extra space is needed. (But maybe it should request some space anyway, just because of /var/log/journal.)
• Disable logging somehow during the apt installation phase.
• Since the installer will clean the APT cache anyway, do it before attempting to build the kernel/initramfs. Or at least apt autoremove at this. Better yet, if the upgrade logic doesn't prevent it, just download/install/cleanup the packages one at a time - this would also greatly reduce the required space.

At the very least, if the first attempt fails due to a disk space error, the installer should not blindly try 4 more times. It should also ideally be able to translate some common failure modes like this into the GUI, with canned advice.

[Jeremy7701]

The duf command, run from the terminal, gives an instant "visual" picture of free space on your mounts. Example (in part)

[zahlman]

Thanks, but that doesn't address my concerns at all. I understand perfectly well how to check for free space on my mounts. In order to assemble the bug report, I had to do so multiple times; and to work around the problem I had to do quite a bit more advanced things.

The problem is that the amount of free space that mintupgrade claims it will need, is less than the amount that it actually will need. Simply checking the amount of free space doesn't solve the problem, because the user doesn't know how much space is actually needed. Because mintupgrade reports an incorrect value. This is a bug.

[Jeremy7701]

Is there a good reason for running with a minimal / ? I realise disk/SSD storage can be limited - but if you need to rely on accurate disk usage calculations, then failures caused by a lack of a GB or two means its time to buy some storage.

[zahlman]

I'm using a separate small partition for / so that I can more easily distro-hop, isolate data partitions to streamline backup and maintenance tasks, etc. But more importantly, because it's my machine, I'm therefore accepting responsibility as my own sysadmin, and it's supposed to work. This sort of thing (or even more complex partitioning schemes) used to be standard for Linux in general, and to my understanding that was even a significant influence behind the details of the FHS.

At any rate, I don't see why anyone would accept hardware purchase decisions being driven by individual programs, especially ones that are only intended to update the system and then not be used again.

[Jeremy7701]

Fair enough. One "solution" would be for the upgrade to just add a few hundred MB (or so) onto its calculation of space needed. It seems unlikely that you would notice. I wasn't even aware that upgrade tried to estimate disk space required, so something like this wouldn't be noticed by me.