An idea around packages & package management

[Astraea]

I wanted to make a thread to discuss an Idea I had before submitting any type of feature request. I know there have been a few people with issues on the 7.2 update with regards to PCI pass-through and GPUs. This got me thinking about how updates are done in Proxmox and how it might be better to have a system that would allow an administrator to control updates and similar to kernel pinning and being able to pin to a specific Version, Subversion or revision of Proxmox.

For example, if you did a fresh install of Proxmox 7.0 on a system the WebUI would have an option under Updates to select update to any version (no pinning) but would also allow you to say stop at the latest version of 7.0 or you could say I want the latest of 7.1 or I want specifically to goto 7.1.3.

This would not only help with any updates that cause issues as you would be able to reinstall and pin to the last working version but would also allow you to bring on a node and get to a specific version if you are trying to test updating your production system from say version 7.0 to 7.2. You could also use this to bring up a node and configure it for a backup or VM that was built on another version that is currently available so that you could either update it and then remake the backup or retrieve any data before moving it to a node that is running a later version.

Of course, you would not be able to use the 7.2 ISO and ask it to move to 7.1 or any other previous version but you could control how far forward in update you move, I especially see this as a good addition as the Proxmox Backup Server does not yet support backing up and or restoring a host using the WebUI and has to be done on the terminal using the backup client.

I am not sure how you would actually implement this or any other effect it could cause and wanted to get some feedback on the idea and also any thoughts on how it should be implemented or constructed so that should the idea move forward I can add to the feature request.

 

[Dunuin]

Backups of the host are already on the wished features list. Upgrading between minor versions would would be way less problematic if there would be some automatic snapshotting before upgrades so you could always roll back to be previous PVE version.

 

[LnxBil]

There is also no global version number like 7.1.3. Every package itself can be updated, or not. Just ordinary Debian versioning stuff. So, if you want to pin e.g. the kernel on version, just do it. (You can also just boot the older kernel without any problem). As an experienced Debian administration, you will not have any problems with this. For the layman, pinning stuff is not a good idea and will result in forgetting stuff and introducing new bugs or restrict the update as a whole if there are explicit package dependencies with versions.

Normally, bugs that are in packages, that Proxmox have to authority over are fixed fast. With the recent kernel problem, there is an upstream problem that affects all machines running Linux and the specific kernel version.

 

[fabian]

like @LnxBil said - this is not how upgrades work on Debian-based systems, and will likely cause issues more often than not. we try hard to allow some level of flexibility (e.g., to make booting/running older kernels feasible, to allow downgrades of the qemu package to work around possible regressions there), but it's not always easy or even possible and there are no guarantees that downgrading or partial upgrades work in practice.