I have a couple servers that back some years I switched to the zabbly kernel + zabbly incus from stable/main bookworm + backports (incus).
Thinking about updating them to Debian 13 but I’m a bit unsure how to approach given that I’ve 2 modifications stitching this together that hinge on bookworm.
Any guidance/corrections on how to proceed appreciated.
If you disable the zabbly repos, the upgrade process should be pretty smooth. (There shouldn’t be any need to attempt to downgrade the kernel you’re running.) After fully upgrading the base system to trixie, then re-enable the zabbly repos, edit them to point to trixie, do another apt update && apt upgrade and you should be good to go.
PS – For anyone not aware, bookworm security has already transitioned to the LTS team on June 10, and the final point release (12.15) will be on July 11, after which time any further updates for bookworm through the end of its life (June 2028) will be handled by the LTS team. It’s a great time to plan migration of any remaining systems to trixie!
That’s correct; during the upgrade to trixie a Debian kernel might be installed, but re-enabling the zabbly repos afterwards will get you back to the zabbly releases.
In concept it’s not really any different than upgrading a bookworm system that’s got a newer kernel installed via backports.
The two incus hosts I’m going to deal with are KVM which have been solid for me for ~5 years. Sometimes I get a bit flustered with KVM that are provisioned with some control/management panels & cloud-init – luckily these have behaved well with my customary manual configuration tasks.
Hoping along the way debian doesn’t help [re]configure or ‘fix’ my hacks.
So far I’ve had 100% success with debian full release upgrades, am glad to know the kernel change shouldn’t complicate things… I’ve never deviated from os repo kernels before these two KVM.
Personally, I haven’t encountered issues upgrading Debian systems that began as a hoster-provided cloud image. A potential concern could be if the provider had some custom packaging installed to better provide insights into the VM’s state, etc. If so, that might require some manual touch-up after the system upgrade.
As always, go slow, actually read any proposed package removals/configuration changes, and don’t blindly hit y when prompted.
I did postpone a couple pre-upgrade ‘apt purge’ cleanup steps because of the heavy mixture of incus or zabbly kernel related files.
The only side effect of my delayed cleaning compared to the debian 12 → 13 upgrades w/o zabbly repos was an extra reboot at the end after doing the postponed remove/purge ops and zabbly repo enabling.
FWIW: one of the (excluded from bookworm → trixie upgrade docs) steps from bullseye I like to continue using.
script -t 2>~/upgrade-babysteps.time -a ~/upgrade-babysteps.script
Also take a glance at 
