I have a manual OpenHAB 2 installation on Linux with config files in /opt/openhab2.
I’m trying to upgrade to OpenHAB 3 using the repository.
I’ve tried following the OpenHAB 3 migration installation instructions at:
One of the notes in the instructions states that OpenHAB 3 will migrate the configuration from OpenHAB 2 if it detects a previous OpenHAB 2 installation. It’s also supposed to ask if you want OpenHAB 2 removed as part of the OpenHAB 3 installation.
I’m not getting a queue to remove OpenHAB 2, and it doesn’t look like it’s migrating configuration files.
Is it not migrating because the old OpenHAB 2 install was done manually? The old config files are in /opt/openhab2, whereas the new ones appear to be in /etc/openhab.
If it’s really /opt/openhab (as you wrote twice) and not /etc/openhab (as it is with anybody else) then yes migration cannot work for obvious reasons.
What “queue” do you expect to obtain?
Without a log showing what you did I don’t think anyone can help you.
I rolled back the OpenHAB 3 installation, moved my OpenHAB 2 installation to /etc/openhab2 and retried the OpenHAB 3 installation.
It still doesn’t seem to be migrating the configuration.
Here’s the output from ‘apt install openhab’:
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
zip
The following NEW packages will be installed:
openhab zip
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 83.4 MB of archives.
After this operation, 94.7 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 zip amd64 3.0-11build1 [167 kB]
Get:2 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable/main amd64 openhab all 3.0.2-1 [83.3 MB]
Fetched 83.4 MB in 12s (7,095 kB/s)
Selecting previously unselected package openhab.
(Reading database ... 33852 files and directories currently installed.)
Preparing to unpack .../openhab_3.0.2-1_all.deb ...
Warning: openHAB's home directory is incorrect (/home/openhab)
but can't be changed because another process (150
4804
4927) is using it.
Unpacking openhab (3.0.2-1) ...
Selecting previously unselected package zip.
Preparing to unpack .../zip_3.0-11build1_amd64.deb ...
Unpacking zip (3.0-11build1) ...
Setting up openhab (3.0.2-1) ...
[openHAB] Please use the following commands to launch openHAB on a system restart.
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable openhab.service
[openHAB] You can start openHAB manually by executing the command:
sudo /bin/systemctl start openhab.service
Setting up zip (3.0-11build1) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for systemd (237-3ubuntu10.47) ...
When all is finished and I start openhab, I end up with both OpenHAB 2 and OpenHAB 3 instances running.
What is the issue with /home/openhab being the wrong directory?
I have an openhab user (with home directory /home/openhab) and group that owns all the files in /etc/openhab2 and the working user:group for my OpenHAB 2 installation is openhab:openhab.
I figured out if I stop any service running under the openhab user (including OpenHAB 2), OpenHAB 3 will install without that /home/openhab error.
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
zip
The following NEW packages will be installed:
openhab zip
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 83.4 MB of archives.
After this operation, 94.7 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 zip amd64 3.0-11build1 [167 kB]
Get:2 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable/main amd64 openhab all 3.0.2-1 [83.3 MB]
Fetched 83.4 MB in 19s (4,393 kB/s)
Selecting previously unselected package openhab.
(Reading database ... 33852 files and directories currently installed.)
Preparing to unpack .../openhab_3.0.2-1_all.deb ...
Unpacking openhab (3.0.2-1) ...
Selecting previously unselected package zip.
Preparing to unpack .../zip_3.0-11build1_amd64.deb ...
Unpacking zip (3.0-11build1) ...
Setting up openhab (3.0.2-1) ...
[openHAB] Please use the following commands to launch openHAB on a system restart.
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable openhab.service
[openHAB] You can start openHAB manually by executing the command:
sudo /bin/systemctl start openhab.service
Setting up zip (3.0-11build1) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for systemd (237-3ubuntu10.47) ...
But it’s still not migrating my settings. The first time I access the OpenHAB 3 web page, it’s acting like a fresh install.
Any other suggestions? I assume the install should provide some indication that it’s migrating files?
have a look at the content of preinst and postinst scripts
during (pre)installation process the file /var/lib/openhab/etc/version.properties is beng used to identify version before the upgrade
because of two main differences between an apt installation and the properties your installation uses ( openhab home dir, etc installation directory ) I would like to kindly ask if you are sure that your installation is based on an apt package installation - sounds like it was a manual tar or zip file based installation
Or if you want to switch to a package installation then you will have to start fresh, and move your configuration files (.item .things etc) to the new configuration folder.
The OpenHAB 2 install was done manually. That was my original question, whether the repository installation wouldn’t be able to recognize the old installation if it was done manually.
Okay, I’ll try it again with the manual install method. I was mainly trying to switch to the repository for simplicity, but if the installations are significantly different I can stick with manual.
The problem with starting fresh is that my things/items/maps are configured in the database, not as files. So it would require a lot of manual work to build them again.
The problem is that you are not giving reasonably useable information. You did not tell the HW, OS or any of the other relevant information.
You do not tell us what install instructions you used (you didn’t give a reference and they can change over time), what you modified and where you deviated from the instruction (such as the install dir).
We cannot (and frankly don’t want to, actually) help people if they don’t provide all of the relevant information upfront.
Your installation is obviously messed up because of that. I suggest you start with a fresh OH3 installation and import your config.
I did state initially the original installation was done manually on Linux, I thought this would be enough information. But if it helps, it’s on a Dell C6100 running Proxmox 6 (Debian) and OpenHAB 2 is running in a Ubuntu 18.04 LXC container.
According to my old notes, I followed the instructions at https://www.openhab.org/docs/installation/linux.htm. Even now the instructions say to download and install in /opt, so now I’m wondering why you’re saying I deviated from the instructions and that my installation is “messed up”.
Well even I didn’t know that there exist install docs to use /opt, it’s the 1st time I heard about someone to install there.
The point though is: if there had been no deviation from the docs it would have worked out, and as it didn’t, whatever caused that it was your move. If you can run two instances at the same time you definitely have messed up.
It’s awkward to have people do - against the recommendation ! - stuff manually then expect us to help when it doesn’t work out.
As I advised, install from scratch, and choose a recommended installation method this time, your best choice will be openHABian on Debian. A lot less hassle to you and all of us.
You didn’t deviate, don’t worry. The manual install instructions are quite clear and they obviously worked. All you did was miss the manual upgrade instructions - no big deal.
Have you tried the manual upgrade instructions yet? Did they work?
I am using a manual install in /opt ever since, even in old openHAB1 times, works like a charm, never had problems. It is a lot easier to maintain than through apt
Of course the update and change to a repo install at the same time can’t work.
@Fug1, why do you want to change to a repo install anyway?
Thank you. I’m trying the instructions for migrating a manual install at Migration to openHAB 3 | openHAB, but I’m running into problems.
The instructions state that I should be able to run the update script at ./runtime/bin/update by specifying the latest version number. The instructions show the version as 3.0.0, but I guess the latest stable is now 3.0.2. In any event, the script comes back with a 404 error. I checked the script and it looks like the download location is at https://ci.openhab.org/job/openHAB-Distribution/lastSuccessfulBuild/artifact/distributions/openhab/target, but this target only seems to include the latest 2.5 version (2.5.12 currently).
Maybe I need to download a specific update script for 3.x, but if so the location of that script doesn’t seem to be included in the instructions.
It wasn’t obvious to me that the apt package installation wouldn’t recognize a previous manual install. I thought this would be a good time to switch from manual to apt, since the upgrade migrates settings, etc.
I was mainly looking to change so a simple ‘apt upgrade’ would upgrade openhab, but it’s not really a problem…I’ll just stick with the manual install approach since it sounds like it’s still supported.
It isn’t supported. The fact that someone wrote down how to manually install doesn’t mean it’s supported. Likely no developer is ever testing stuff like this so if you stay rather than to switch to the mainstream you’ll likely run into a similar problem on very next occasion.
Can you tell me what supported means here, then? This is the official support page for the community, is it not? One of the installation options in the instructions on this site is the manual installation method.
How is a user supposed to know this installation method is less supported than another method?
No it isn’t. The word “support” does not appear anywhere on this page, does it.
Common sense ?
Because the docs state the recommended install methods ?
I don’t know of any product, incl. commercial ones, that will truely support a “manual” install.
That always implicates an unknown environment, and noone has the time and guts to support that.
And it only becomes a problem when users decide to deviate from standards and recommendations.
I (we all, in fact) could have spent the time it took me(us) to write the posts in this thread way better.
