Open kennethrrosen opened 5 months ago
Hi @kennethrrosen, thank you for filing this. I think the direction we are planning to go with VM updates is to rely more and more on Qubes native update mechanisms (see eg #899), rather than implementing more of our our own update logic. For example, there have been some new additions to Qubes lately that warn when VMs are running out of space, and show a GUI prompt to the user to increase their storage allotment (although I'm not sure if you'd see this warning for a template unless you have it running, which isn't something you're likely to do do much of except when installing packages, and iirc it's a warning about private storage not system storage).
So our planned path would probably be more along the lines of documenting for users how to follow upstream documentation to adjust the size of their templates if they run into issues, and/or filing upstream tickets to make that process clearer and easier for users (or bumping existing issues such as https://github.com/QubesOS/qubes-issues/issues/7249). Please let me know what you think of this plan, or if you think there's a compelling reason to treat this as other than an upstream/underlying OS issue.
(As an aside: I'm slightly curious about your running out of space in the fedora system template - for SDW we don't install additional packages in that template, and we don't upgrade in place across fedora versions. Anecdotally I've never run out of space in the fedora system template, so I'm wondering if other customizations are at play for you there - but you don't need to answer that here if you don't want to, we can discuss elsewhere. Just trying to get a sense of whether your system template usage would be representative of typical SDW usage patterns or not.)
When updating to the latest release (2.8.0), the updated failed because a Fedora template lacked sufficient storage space. I suggest creating a
qvm-block attach
for the template-to-be-upgraded/updated, similar to the in-place-upgrade for Qubes OS templates (>4.1):