During my first attempt to install Java 21 (Temurin), the dpkg process froze. I had to kill it manually:
sudo kill <your_pid>
Then I cleaned up the lock files:
sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
And repaired the configuration:
sudo dpkg --configure -a
On the second try, the Java upgrade worked fine. My system (openHABian on Bookworm) was previously on Java 17. When I initially ran sudo apt upgrade, it failed because the openHAB 5 pre-installation script correctly detected the wrong Java version, which caused the first dpkg error.
Preparing to unpack .../openhab_5.0.0-1_all.deb ...
[openHAB] WARNING: We were unable to detect Java 21 on your system. This is needed before openHAB is unpacked.
[openHAB] Java 21 may not be available on 32-bit platforms.
dpkg: error processing archive /var/cache/apt/archives/openhab_5.0.0-1_all.deb (--unpack):
the new 'openhab' package's pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/openhab_5.0.0-1_all.deb
Updating FireMotD available updates count ...
E: Sub-process /usr/bin/dpkg returned an error code (1)
After successfully upgrading to openHAB 5, my Enocean USB300 Dongle was “NOT YET READY”.
The final solution was to install a missing dependency via the openHAB console:
openhab-cli console
feature:install openhab-transport-serial
This brought all my EnOcean devices back online immediately.
Everything is running smoothly again! 
Does anyone know why feature:install openhab-transport-serial is often necessary again after updates?
Here’s a summary of the technical issue and the suggested feedback.
Technical Summary
The package upgrade process failed due to a two-stage problem. First, the openhab package pre-installation script correctly detected a missing dependency (Java 21) and aborted the unpacking phase. This, however, left the package in a “half-installed” state.
Subsequently, an automated attempt to fix this broken state by running dpkg --configure -a was initiated. This repair process encountered an unrelated file conflict (initramfs.conf) that required interactive user input. Since the script was running non-interactively, it could not answer the prompt and froze, locking the entire package management system and requiring manual intervention to kill the process and resolve the lock.
Suggested Feedback
This situation highlights a potential improvement for package management scripts, especially for unattended upgrades.
It would be beneficial if package managers or wrapper scripts (like openhabian-config) had a more robust mechanism to prevent such deadlocks. For instance, an upgrade process could run in a strict “non-interactive-only” mode. In this mode, if any step attempts to trigger a user prompt (like the dpkg configuration question), the process would immediately fail with a clear error message instead of freezing. This would prevent the system from entering a locked state and would inform the user that manual, interactive intervention is required before any processes need to be killed.