Upgrading from QubesOS 4.x doesn't result in the same end user configuration (discards and tpool)

[tlaurion]

Qubes OS version
Qubes 4.+. Behavior is different for users across RC and actual 4.0.3 release.

Affected component(s) or functionality

• lvm discards are setuped differently from anaconda changes between RC and 4.0.3 release

• tpool metadata size is different, latest release fixes probable tpool fillup

Brief summary
This can happen.

To Reproduce
Compare tpool size between earlier 4.x and actual 4.0.3 version from anaconda/blivet deployed defaults. Safe values are only deployed at new installation

Expected behavior
Have the same behavior as stated in upgrade guide or have a warning in there on the upgrade guide saying that the result from upgrading has risks and document anaconda changes and needed actions.

Have disk space widget prevent the tool metadata filled up situation.

False:
If you installed Qubes 4.0, 4.0.1, 4.0.2, or 4.0.3-rc1 and have fully updated, then your system is already equivalent to a Qubes 4.0.3 installation. No further action is required. SRC

The point being: further actions are required

Actual behavior

• tpool might fill up

• discards configurations are different across RC revisions (ex: root fs (dom0) discards) resulting in different user faced problems depending of the 4.x version they installed from, prior to upgrading to latest versions from packages, those configurations not being patched (LVM discard, dom0 pools discard, tpool metadata size doubled).

Solutions you've tried
Workaround is to reduce 8gb swap and expend tpool

Relevant documentation you've consulted

• widget should link to documentation /prevent tpool metadata saturation
• wyng discussion exposing the need to triple tpool size to have much stable pool if coming from early 4.x RC releases but upgraded to latest.
• Anaconda changes [1, 2]
• can't find tpool metadata size change commits . Change is in blivet

[tlaurion]

Note: upcoming changes in installer will seperate dom0 thin pool from main pool.

[tlaurion]

@marmarek @andrewdavidwong
Note: no progress in GUI user awareness of upcoming problems with paths of mitigations available.

[marmarek]

@fepitre created a tool for R4.0 -> R4.1 upgrade, which also take care of those differences: https://github.com/fepitre/qubes-migration

[tlaurion]

@marmarek @fepitre The thin pool metadata gets doubled where?

[brendanhoar]

I don't see that in @fepitre 's code (yet?), @marmarek.

[marmarek]

Not yet, but it will be there: #5685

[tlaurion]

@marmarek : last time I checked, discards were not pushed under lvm.conf file still under 4.1 even if QubesOS/openqa-tests-qubesos@2f49b75 was pushed as default?

(Linked to #3686)

[marmarek]

Discards in lvm.conf don't matter for thin volumes (they affect only non-thin volumes, which we don't use). I'm not sure if that is an LVM bug, or intended behavior (likely the latter). We do blkdiscard ourselves on a volume just before removing it.
EDIT: the above is about issue_discards option. thin_pool_discards does apply to thin volumes and is enabled by default.

[DemiMarie]

Discards in lvm.conf don't matter for thin volumes (they affect only non-thin volumes, which we don't use). I'm not sure if that is an LVM bug, or intended behavior (likely the latter). We do blkdiscard ourselves on a volume just before removing it.
EDIT: the above is about issue_discards option. thin_pool_discards does apply to thin volumes and is enabled by default.

issue_discards being false is indeed intended, as it allows various operations on non-thin volumes to be undone if caught promptly.

[brendanhoar]

issue_discards being false is indeed intended, as it allows various operations on non-thin volumes to be undone if caught promptly.

Personally I'd like the global state of whether issues are flowed down to the hardware/storage device to be exposured in Qubes Global Settings.

This will allow the end user to make the determination of which is more important to them: a) recovery of data OR b) device performance and opportunistic anti-forensics.

Flowing discards to lowest layers require both lvm.conf to be correct as well as the luks config.

B

[marmarek]

Let me repeat: issue_discards has nothing to do with LVM thin volumes we use. There is no point in discussing (here) what value should it have, and no point in adding any kind of interface for changing it.

[brendanhoar]

I will follow your guidance, @marmarek.

[github-actions]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment.
(For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)