ICU Package Missing After Roon Upgrade on Debian Trixie (ref#56C038)

What’s happening?

· My Roon software won't start up

How can we help?

· None of the above

Other options

· My Roon software won't start up

Describe the issue

I upgraded Roon on Linux Debian (Trixie) and after that Roon did not start.

I did noticed that error is missing ICU package. I installed libicu (libicu76) package and that fixed the issue. Roon service started correctly and I could connect to it from other machine.

So this is fixed, but liked to report the upgrade issue since Linux Debian Trixie was just released. I had no issues on past on Bookworm with upgrade.

Describe your network setup

Wired 10G Cat6 copper connection

1 Like

Hello @Jesse_Lahtela

Thanks for reporting this and glad to hear you got Roon running again.

What likely happened here is that Debian upgrades often replace older versions of the libicu library with a newer one, and only install it if some system package explicitly requires it. For example, Debian 12 included libicu72, while Debian 13 provides libicu76. During the upgrade the old package is removed, but the new one may not be installed automatically if no default system component depends on it.

That’s why it looked like the package “disappeared” after the upgrade, and Roon couldn’t start until you manually installed the newer version.

1 Like

Small clarification to this.
Roon was working after I upgraded Bookworm to Trixie earlier.
It did stop working when I updated Roon today.

Then I noticed missing package from logs / start error message and when I installed it all started to work.

1 Like

Thanks @Jesse_Lahtela for sharing this information.

The DietPi upgrade script seems to handle this:

Torben

Please see also:

Yes, we (DietPi) handle that package migration already, but under the assumption the old libicu72 package remains installed, i.e. is not forcefully removed by apt-get dist-upgrade/apt full-upgrade. It always remained on my test upgrades.

You said that Roon logged it was missing. Did you check whether the old package was really removed?

dpkg -l | grep libicu

The package has no conflicts or file overlaps or other incompatibilities defined in its metadata. So as long as it was installed manually via apt install libicu72, it should never be removed automatically by any step. Only way would be if it was pulled by another DEB package automatically as dependency, and you did apt autoremove.

But another explanation for the Roon error would be that the old library version practically cannot be loaded on Debian Trixie. But if there was really a forceful/automatic removal of that old package in your case, then we’d need to adjust our upgrade script as well, hence checking back :wink:.

EDIT: On the other linked issue, a Proxmox user said

In proxmox I still had the old libicu72.

So it really seems like the old package remains on the system, like it did on my test upgrades, but is just not usable anymore. Cleanup step we do, after installing libicu76:

apt autopurge libicu72
2 Likes

I did do upgrade on Debian with apt full-upgrade

No I did not look was it missing, but I did run on roon folder “start script” if I recall how it was named. ./roon/start.sh or similar. I can’t currently to check what it was there. This did throw me error that libicu is missing. So I did went and just installed it with apt install libicu76

However it is worth to mention that after Bookwork to Trixie upgrade I did do cleanup actions mentioned on release notes: 4. Upgrades from Debian 12 (bookworm) — release-notes documentation.

But yet again… after Bookworm to Trixie Roon was working. After today Roon upgrade from Roon app it did stop to work.

Running processes usually have all their components in memory – so no surprise here. It became, in a way, just missing on restart of the process.

PS: You may reformat the system drive (or the drive may die) of a running Linux and don’t notice that anything is amiss until you want to start a new process not already loaded (in memory).

That guide suggests apt purge '~o' which is IMO a dangerous advice. It purges all packages which are not currently present in any APT repository installed on the system. This includes libicu72, which is fine when knowing that libicu76 might be needed instead. But some might have installed DEB packages downloaded manually, some installers do this as well, and there are even cases where Debian’s own packages keep their old variants installed intentionally. An example is PostgreSQL, which does not perform cluster upgrades automatically, and to run e.g. PostgreSQL 15 clusters on Trixie, the PostgreSQL 15 needs to be present, even that Trixie ships only PostgreSQL 17. Similarly, to upgrade old clusters (which needs to be done manually), PostgreSQL 15 and 17 are both required. So the package maintainer scripts of these packages place some apt.conf.d drop in to prevent the autoremoval of the old PostgreSQL 15 packages. But those are strictly seen “obsolete” (what ~o means), so apt purge '~o' would purge them. It requires a confirmation, but people follow suggested commands without knowing exactly the consequences, and that old PostgreSQL is not needed anymore when new one is available, seems logic on first view, but means crashing the running clusters.

So if they would have asked me:

  • apt list '~o' is good to have a look at, listing all packages which are not in any installed APT repository.
  • But I would not even mention the command apt purge '~o', but leave it to the admin to decide which of the above listed packages are save to remove. And if unsure, leave them in place.
1 Like

I have done reboots of system after upgrade.

Only what I can think of that I did remove NordVPN and Tailscale from system… and I am not sure did I reboot it after those changes.
With quick look of to internez NordVPN may use libicu72 as it mentioned… and I may have done autoremove after that to get it cleaned. :thinking:

I completely agree with you! For this being official Debian document for upgrade guide they should be more careful… or at leas add big warning text there.

For me this dedicated Roon box where I end up do some VPN play around… and I did wan to bring it to clean state… and was willing to face possible issues… and here I am. :joy:
But nothing what I could not fix in few minutes… so no biggie for me.

This topic was automatically closed 9 days after the last reply. New replies are no longer allowed.