I assume you mistyped, because I haven’t started the upgrade process yet. But I’m afraid I’m still possibly confused. I don’t see where you get ‘see’ from…
Are you talking of two different problems? The upgradeTool sounds like it’s not add-on related? And a smooth update seems desirable 
I’m replying to @HenMus above who was referencing your post mentioning potential Docker problems.
Don’t know if this will help, but I also updated smoothly (except the usual docker restart openhab-openhab-1 after the initial messy log). However, from my log the upgrade tool had already run last month. I can’t tell from github timing of the PRs (and reverting PRs), but maybe I caught a window, or got lucky. Maybe there is a workaround to upgrade to M4, get the upgrade done then upgrade to 5.0?
Starting JSON database update...
[main] INFO org.openhab.core.tools.UpgradeTool - Already executed 'itemCopyUnitToMetadata' on 2025-06-27T10:17:16.141980859-04:00[America/New_York]. Use '--force' to execute it again.
[main] INFO org.openhab.core.tools.UpgradeTool - Already executed 'linkUpgradeJSProfile' on 2025-06-27T10:17:16.161841465-04:00[America/New_York]. Use '--force' to execute it again.
[main] INFO org.openhab.core.tools.UpgradeTool - Already executed 'linkUpgradeScriptProfile' on 2025-06-27T10:17:16.180277683-04:00[America/New_York]. Use '--force' to execute it again.
[main] INFO org.openhab.core.tools.UpgradeTool - Already executed 'yamlTagsListToMap' on 2025-06-27T10:17:16.191054503-04:00[America/New_York]. Use '--force' to execute it again.
JSON database updated successfully.
SUCCESS: openHAB updated from 5.0.0.RC1 to 5.0.0
A problem with the upgradetool sounds inconvenient. But a lot of people have reported smooth upgrades.
How can both things be true?
The problem with upgradeTool doesn’t impact everyone. If it did the problem probably would have been discovered prior to the code being merged, well before the OH 5 release.
I really love the Update, although it was lot to reassign for the MQTT Homeassistant Things.
I noticed, that my Sitemaps can’t be saved anymore. Looks like there are two issues.
Unexpected unsignedint token: "10". Instead, I was expecting to see one of the following:
A identifier token based on:
WidgetIconAttrPart → ● %identifier
WidgetIconAttrPart → %identifier %hyphen ● WidgetIconAttrPart
WidgetIconAttrValue → ● WidgetIconAttrPart
WidgetAttr → %icon _ ● WidgetIconAttrValue
WidgetAttrs → ● WidgetAttr
Widget$ebnf$2 → Widget$ebnf$2 ● WidgetAttrs
Widget → %lwidget _ ● Widget$ebnf$2
Widgets → ● Widget
Sitemap → %sitemap _ SitemapName __ SitemapLabel __ %lbrace _ ● Widgets _ %rbrace
Main → _ ● Sitemap _
A identifier token based on:
WidgetIconAttrPart → ● %identifier %hyphen WidgetIconAttrPart
WidgetIconAttrPart → %identifier %hyphen ● WidgetIconAttrPart
WidgetIconAttrValue → ● WidgetIconAttrPart
WidgetAttr → %icon _ ● WidgetIconAttrValue
WidgetAttrs → ● WidgetAttr
Widget$ebnf$2 → Widget$ebnf$2 ● WidgetAttrs
Widget → %lwidget _ ● Widget$ebnf$2
Widgets → ● Widget
Sitemap → %sitemap _ SitemapName __ SitemapLabel __ %lbrace _ ● Widgets _ %rbrace
Main → _ ● Sitemap _
TypeError: t[4].join is not a function
Not sure what exactly the issue is, but I’ll look for it tomorrow.
Edit: 2. is coming from the icon definition in:
Selection icon=[Keymatic_Kellertuer_Lock_State==LOCKED="door-closed", Keymatic_Kellertuer_Lock_State!=LOCKED="door-open"] item=Keymatic_Kellertuer_Lock_Target_Level label="Kellertür (Keymatic)" labelcolor=[Kellertuer_StateContact!=CLOSED="red", Keymatic_Kellertuer_Lock_State==LOCKED="green", Keymatic_Kellertuer_Lock_State!=LOCKED="orange"] mappings=[UNLOCKED=Entsperren, LOCKED=Abschliessen] valuecolor=["yellow"]
You have to replace gosu by su-exec in the docker container’s config. I had this as well when using portainer and updating 4.3.5 to .6.
Hi @boris03, see also:
Great work on the update!
My update.log did have the errors listed below when I upgraded from 4.3.3 to 5.0.0, but everything seems to be fine.
Exception in thread "main" java.lang.NoClassDefFoundError: tech/units/indriya/AbstractSystemOfUnits
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at org.openhab.core.types.util.UnitUtils.<clinit>(UnitUtils.java:63)
at org.openhab.core.tools.internal.ItemUnitToMetadataUpgrader.lambda$0(ItemUnitToMetadataUpgrader.java:161)
at java.base/java.util.concurrent.ConcurrentHashMap$KeySetView.forEach(Unknown Source)
at org.openhab.core.tools.internal.ItemUnitToMetadataUpgrader.execute(ItemUnitToMetadataUpgrader.java:104)
at org.openhab.core.tools.UpgradeTool.lambda$2(UpgradeTool.java:134)
at java.base/java.lang.Iterable.forEach(Unknown Source)
at org.openhab.core.tools.UpgradeTool.main(UpgradeTool.java:122)
Caused by: java.lang.ClassNotFoundException: tech.units.indriya.AbstractSystemOfUnits
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 25 more
Update tool failed, please check the openHAB website (www.openhab.org) for manual update instructions.
@jimtng Just a follow-up question: can I perform the upgrade and ignore the error messages, or would something be missing from the migration? When I restart the container after the first crash, Openhab 5 runs. I could then perform the upgrade and apply the patch later.
I’m using a custom Jollyday file with Ephemeris to calculate remaining days until the next event. The unit is clearly set to days, but the output is still shown in seconds (e.g. 12960000 s instead of 150 days).
This seems incorrect, since Ephemeris is designed to work with day-based logic. Can this be fixed so the output respects the unit setting?
@milo : is it something that was different in OH 4.3 ?
Honestly I don’t know I just implemented the binding
So, this thread is not a a thread that should contain any question or problem about openHAB usage. It is better to open a dedicated thread for your question about ephemeris.
The upgrade tool as of openHAB 5.0, performs 4 modular tasks/steps
Link to Documentation about the Upgrade Tool
Steps 1-3 have existed since openHAB 4.2, in other words, they do nothing for you if you’re upgrading from >= 4.2 to 5.0.
Steps 1-3 only apply to you if you’re using UI-based Items. If you’re using DSL based .items file, they do not apply to you, although you may need to make manual adjustments to your .items file, and do the same thing that the tool does. I can provide detailed instructions if needed. I don’t know if there are already written instructions somewhere. EDIT: added link to doc 2 paragraphs above.
Step 4 is new in openHAB 5.0 and it only applies to you if you ever created custom semantic tags and defined them in a yaml file. I suspect only very few people use this feature. It only existed since around 4.2.
If none of these apply to you, then you can completely ignore the issues in the upgradetool.
If step 4 applies to you, you can still manually adjust your yaml file to match the new format, as described in YAML Configuration | openHAB and if you’ve already done this, step 4 will not make any difference.
If you’re upgrading from < 4.2, you could try upgrading to 4.3.6 first. The upgrade tool should work there. Then upgrade to 5.0.
Lastly, there are currently two reported / known issues with the UpgradeTool in 5.0:
java.lang.InternalError: should not come down here as reported here. So far I cannot reproduce this, so I’d appreciate others, especially not using Docker, to test it too. The command to try is shown here. Please report your output in that github thread if possible, or in a PM to me if you don’t have / want to create a github account.That would be very interesting to know as I hear this the first time ever …
Edit: if this is only for older version, it does not apply to me as I am upgrading from 5M4.
I’ve updated my post above with additional details and links.
Thx a lot, so it is only for upgrading from older versions.
It was a misunderstanding from my side, I thought there were new changes from 5.MilestoneX to the 5.0 Release version.
Dear @jimtng. Thank you so far for your actions. When I read your explanation of the 4 steps, I am confused. If I understand everything correctly, none of the steps apply to me. I do have UI-based items, but I have done every update and I have never used YAML files.
UPDATE
Unfortunately, your advice that I should ignore the issue does not work, as openhab has not been running since the update.
Today, after another reboot, openhab is starting without error again.