I've just updated the new packages from pve-no-subscription for PVE version 9. All my Debian 13.1 containers are working fine again after the reboot. I really appreciate the quick fix. It is by no means a matter of course to provide a fix for non-paying customers on a Sunday evening. Thanks again to the whole team behind Proxmox.
Debian 13.1 LXC template fails to create/start (FIX)
- Thread starter tsv0
- Start date
You do realize that paying customers always get the fix later? I don't want to detract from the effort of the Proxmox team to release this fix in the weekend but (they did have the same issue when Debian 12.1 was released and) it's normal procedure that it goes out to no-subscription first. Why was it
<= 13 used in the first place instead of < 14 when Debian does not make breaking changes within a major release?
Not that I can recall, there we bumped the version soon enough which was included with pve-container 4.4-5 for the previous PVE release, which got bumped on 16th of June and with pve-container version 5.0.2 for the PVE 8 release, which was not yet out and there the package got bumped on the 16 June. The first Debian Bookworm 12.1 point release OTOH happened over a month later on 2023-07-22.
It was simply a bug that went unnoticed, as mentioned in my initial reply here: the check was never ideal the way it was.
It probably went simply unnoticed due to the upper boundary getting set high enough before the point release, and it might have already happened before (I really only checked for Debian 12) and "quick fixed" without really thinking about the subtle implications for the way the check was.
I did not look into the details so I might have jumped to the wrong conclusion. I which case I'm sorry and would like to make it right (if you can help me on how).
The <=13 looks wrong, just as the <=12 looked wrong. It was mentioned that it was changed to <15 (which includes the current Sid, while I would have expected <14). It still feels like this is an accident waiting to happen in another few years. Did the team include upping the version in the next release check-list? Or maybe an upper bound is not necessary (until it actually is)? You did elaborate on some points (for which I'm thankful) but I still got the impression that it's a quick fix for now but not a real change in procedures. Not that I'm an expert on these things and I could easily be wrong (so please correct me). I don't mean no harm but I do like process/procedure improvements.
Either way, this is not a big issue and small mistakes happen every now and then (and I have make quite a few myself at work) and I do appreciate you making the effort to get this fixed during the weekend. The product is great, the way it is supported and how issues are handled is almost always great also. And I'm know to nitpick anyway...