@@ -124,10 +124,13 @@ ALTERNATIVE:${PN} = "${@bb.utils.filter('BINCOMMANDS', 'scp ssh', d)}"
ALTERNATIVE_TARGET = "${sbindir}/dropbearmulti"
pkg_postrm:${PN} () {
- if [ -f "${sysconfdir}/dropbear/dropbear_rsa_host_key" ]; then
+ # The host keys are generated on the target, not shipped in the package,
+ # so keep them on upgrade: a new key changes the identity every client
+ # has recorded for this host.
+ if [ "$1" != "upgrade" ] && [ -f "${sysconfdir}/dropbear/dropbear_rsa_host_key" ]; then
rm ${sysconfdir}/dropbear/dropbear_rsa_host_key
fi
- if [ -f "${sysconfdir}/dropbear/dropbear_dss_host_key" ]; then
+ if [ "$1" != "upgrade" ] && [ -f "${sysconfdir}/dropbear/dropbear_dss_host_key" ]; then
rm ${sysconfdir}/dropbear/dropbear_dss_host_key
fi
}
Dropbear deletes its keys in its postrm(), which is fine for deb and rpm, but opkg still runs postrm() during upgrades... Skip the deletion when postrm() is called with "upgrade". It still works for actual removal, the respective package managers provide: * opkg: "remove" * dpkg: "remove" or "purge" * rpm: "0" The postrm() in the recipe gets a comment spelling this out. I had an LLM write that comment since this very unwelcome detour broke my development setup and sarcasm shouldn't end up in comments, so: AI-Generated: Uses Claude Code Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com> --- meta/recipes-core/dropbear/dropbear_2026.94.bb | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)