openHABian Failing - Never Have Had Problems Before

The log that you posted shows entries like “user audio” and “/home/user/.bash_profile”.
According to the openhabian scripts user is the content of the variable username.
This is set based on your input to the question: “Please provide the name of your Linux user i.e. the account you normally log in with”
In case your answer to this question is not “user” then something went wrong.

Or with your OS. You read the README, didn’t you ? On x86, we only support plain Debian or Ubuntu.
I don’t know MX Linux but “essentially Debian” might not be enough.
BTW you fail to mention what HW you use.

What instruction exactly, what “script” ? openhabian-config ?
With the unattended option ? Or interactively ?

That’s not part of openHABian. Must be a homebrew so you would need to show it if you want us to help.

What files ? The debug guide is written for unattended install from the image.
If you don’t use the image but run it after manual install then there’s no logfile but you can start recording the terminal output and redo your installation steps.

Edit /etc/openhabian.conf and set debugmode=maximum to see every command to get an idea where it’s failing (BTW the debug guide also tells you to).

Coincidentally I had the same issue just now on a fresh Ubuntu 20.04.1. Same error messages.

It seems the issue was that I forgot to set the correct user/pass in openhabian.conf before I installed it.

Now I fixed that and reinstalled openhabian but some things like frontail are still messed up and I cannot fix it myself…

4 posts were split to a new topic: Frontail issues on new openHABian install

Sorry, I have been in the hospital for weeks and am only now able to sit down and look at my openHAB system again and review the responses here, which I will do now. I am still having problems. I think my issue might be with configuring the “etc/openhabian.conf” file part of the openhabian setup process - there is simply not enough instruction about this part of the setup process, especially for standalone Linux PC openhabian users. I will make a new topic for this request though. Thank you again for your help.

It’s used but you don’t need to edit openhabian.conf when you do a manual installation.
It’s for unattended installations.

Because it’s not needed here.

Now you’re mixing even more topics. Are you an ARM user or a PC user ? Did you use the unattended option ?

Please make a proper, comprehensive statement about the HW and installation procedure you used.

Thank you for this clarification! It would be very helpful if a simple sentence or two were added to the installation instructions to make this clear for the user at installation. I have created a separate topic (which I see you are currently replying to) for this separate concern, and have provided detailed system information. I have also edited my original post here and have appended my system details.

I think my main issue with openhabian-config failing me this time (when it normally has worked so well without any issues) is because I had to reinstall my entire OS onto my device, but attempted to transfer my existing applications and data to my newly refreshed machine, using the Aptik application. It seems the “fresh” install of openhabian is running into errors when trying to install Frontail, as various remnants of my prior, migrated Frontail installation remain on my system.

It would be very helpful if openhabian-config could be installed via a standard apt package process, or the installation script updated to include an uninstall/removal option. Not just for openhabian, but for supporting applications installed by openhabian-config, including openHAB, Frontail, etc.

I tried to find information online about how to completely remove openhabian from my system but there is not any real guidance. I subsequently then just just used a common complete-system file searching utility (Catfish) to find any files/installed systemd processes named “openhab” and “openhabian” and deleted those files and config files. I now see there are still remaining old Frontail files and so I will manually remove those now.

I tested installing openhabian-config and also openHAB while running a fresh “live” ISO version of my operating system in a VMWare virtual machine and had no issues whatsoever, so I believe my problem is due to openhabian-config trying to setup and install itself on top of remaining old files and configurations from my previous installation. This is why it would be very helpful to have an option to undo any changes made by openhabian.

Thank you again!

Thank you for this tip!

This is exactly the problem I experienced… but I am now learning we are not supposed to touch the openhabian.conf file if installing the “manual” way on a complete desktop Linux PC…

You’re having a slightly wrong understanding of what openHABian is.
openHABian is just scripts. Remove /opt/openhabian and you’re done.
But what you seem to expect is a comprehensive routine to uninstall everything it installs.
That won’t happen as it’s a lot of work and pointless IMHO.

Thank you for this. I do understand that openhabian-config is just a script/series of scripts. But I guess I am suggesting that perhaps at this point, given all it is capable of accomplishing and configuring on one’s machine, that it might be best suited to be packaged as a complete application entity. Especially given that it seems in general that new openHAB users/new installs are overwhelmingly encouraged to use the openhabian-config script. Half the time if you ask a question in the openHAB Community Forum and have not installed openHAB via openhabian-config, people will not answer your question and will first tell you to go back and setup your system via openhabian-config. This is what I did, almost two years ago, after running into difficulty installing openHAB on my Windows system given the Windows openHAB installation documentation that was provided at that time (I believe this documentation has since been improved and streamlined a good bit).

So, then I try to install it onto Linux and I get a nice HTML-5 fancy material splash page/website telling me that this will be a breeze and:

A home automation enthusiast doesn’t have to be a Linux enthusiast!

But then I’m finding in-practice that isn’t quite the case. I would just like to see a few very small, helpful installation tips provided, especially for those of use not using a PI/ARM micro-computer. And for users such as myself who subsequently have to start from scratch after having worked with openhabian for two years without issue but who can’t easily “start from scratch” because the setup script stumbles on its previous installation/configuration and the script errors out and breaks, it would be wonderful if there were an option within openhabian-config to undo/remove all changes the script has made on one’s system. Additionally, as part of this clarification I would so very much recommend and love to see for non-PI users, it would be great if openhabian didn’t hijack my entire Linux shell with the big fancy “openHAB” ASCII text-art title in my terminal window. I understand how this is useful for a PI-provisioned installation, where there is no Xorg / display interface and the entire machine is used for openHAB and accessed via SSH or something, but for a full-desktop Linux installation user, there are just some small details that I feel if they were presented with a little more context and clarification would be very helpful. openHAB is such a wonderful, wonderful tool/system/resource and I cannot even begin to sing praise enough for how much I love it and how useful it is. I would just like to make this easier for all current and potential new users.

Edited for another area where I’ve had issues: as a full Linux desktop user, Samba does not only belong to openHAB. I have many other custom Samba config file entries that I need and use on my own. Yet every time I run openhabian-config again, it removes all of my smb.conf entries and this is a major pain. All I’m saying is that there needs to be better consideration given to regular Linux PC users. Deleting /etc/openhabian alone does not simply uninstall/undo all the changes that openhabian has made to my machine, not even in the slightest…

For me, just tying to start from scratch with openhabian-config, this is where the script begins to stall and run into trouble:

richard@HomeServer:~
$ openhabian-config
2020-09-21_12:58:20_CDT [openHABian] Checking for root privileges... OK
2020-09-21_12:58:20_CDT [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
2020-09-21_12:58:20_CDT [openHABian] openHABian configuration tool version: [stable]patchday-20200912-805(12917d6)
2020-09-21_12:58:20_CDT [openHABian] Checking for changes in origin branch stable... OK
2020-09-21_12:58:22_CDT [openHABian] Switching to branch stable... OK
2020-09-21_12:58:44_CDT [openHABian] Updating Linux package information... OK
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2020-09-21_12:58:45_CDT [openHABian] Installing basic can't-be-wrong packages (screen, vim, ...)... OK
2020-09-21_12:58:47_CDT [openHABian] Installing additional needed packages... OK
2020-09-21_12:58:48_CDT [openHABian] Beginning install of latest openHAB release (stable)... OK
2020-09-21_13:02:00_CDT [openHABian] Adding required keys to apt... OK
2020-09-21_13:02:03_CDT [openHABian] Installing selected openHAB version... OK
2020-09-21_13:02:18_CDT [openHABian] Setting up openHAB service... OK
2020-09-21_13:02:18_CDT [openHABian] Creating dependencies to jointly start services that depend on each other... OK
2020-09-21_13:02:18_CDT [openHABian] Adding delay on loading openHAB rules... OK
2020-09-21_13:04:19_CDT [openHABian] Adding an openHAB dashboard tile for 'openhabiandocs'... OK
2020-09-21_13:05:08_CDT [openHABian] Preparing openHAB folder mounts under '/srv/openhab2-*'... OK
Job for smbd.service failed because the control process exited with error code.
See "systemctl status smbd.service" and "journalctl -xe" for details.
2020-09-21_13:05:10_CDT [openHABian] Setting up Samba network shares... OK
2020-09-21_13:05:10_CDT [openHABian] Setting up Samba service... FAILED (restart service)
2020-09-21_13:05:13_CDT [openHABian] Installing openHAB Log Viewer (frontail)...

That “just” just doesn’t work. Have you ever worked in support or project management ?
Remember Pareto principle. You’re the 20% of people that generate 80% of the work (to me and others to develop openHABian). Worse even you want to run it next to a lot of other applications and customized stuff on an OS instance you’ve been modifying for years instead of setting up from scratch. The recommendation to run OH on a dedicated box is there for good reasons.
That makes it rather something like 95/5 or even worse. That is, supporting setups like yours (that make up no more than 5% of all users) is generating 95% of our work. Countless ever-new pitfalls waiting that make life for us developers hard.
So as unfortunate as that may be, but you’re the 5% our scarce ressources are worst spent on and we’re trying to streamline that to focus on getting stuff done that the 95% of users benefit from.
I’m sorry but I’m also certain you understand this is not meant to be personal.

Fair enough, I am a PMP lol, so yes. Though not in IT.

I understand none of this is personal and it is not for me either. I really appreciate your being straightforward and helpful and I am sorry to continue to bother you.

If questions like mine though continue to be causing you to bother with giving so much of your time then perhaps something is not properly setup/instructed in the best way that it should be for users.

I have completely resolved my problem. Updating the /etc/openhabian.conf was indeed what the issue was. I would like to once again state that if one simple sentence were added to the setup instructions, I never would have had any issues.

Updating the file with my proper username, under the section called “user” that says “do not touch/change” was essential. As was setting the Java at the very bottom from Zulu8-64 to Zulu11-64. I had previously been running Zulu8 and recently changed to Zulu11 and had no clue that I had to change some flag on a configuration file somewhere…

Changing those two values allowed everything else to work seamlessly. I had no clue that I was supposed to even change the openhabian.conf file, and then I was told not to change “user” (in the comment provided in the document) and then there is zero information given at the bottom for the Java version flag.

Thank you for your time and continued wonderful contributions to the openHAB community!

richard@HomeServer:~
$ sudo openhabian-config
2020-09-21_14:19:32_CDT [openHABian] Checking for root privileges... OK
2020-09-21_14:19:32_CDT [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
2020-09-21_14:19:32_CDT [openHABian] openHABian configuration tool version: [stable]patchday-20200912-805(12917d6)
2020-09-21_14:19:32_CDT [openHABian] Checking for changes in origin branch stable... OK
2020-09-21_14:19:36_CDT [openHABian] Switching to branch stable... OK
2020-09-21_14:19:59_CDT [openHABian] Updating Linux package information... OK
2020-09-21_14:19:59_CDT [openHABian] Adding required keys to apt... OK
2020-09-21_14:20:05_CDT [openHABian] Adding Zulu repository to apt... OK

2020-09-21_14:22:33_CDT [openHABian] Installing Java Zulu CEK to enable unlimited cipher strength... OK
2020-09-21_14:22:33_CDT [openHABian] Beginning install of latest openHAB release (stable)... OK
2020-09-21_14:26:53_CDT [openHABian] Adding required keys to apt... OK
2020-09-21_14:26:58_CDT [openHABian] Installing selected openHAB version... OK
2020-09-21_14:27:09_CDT [openHABian] Setting up openHAB service... OK
2020-09-21_14:27:10_CDT [openHABian] Creating dependencies to jointly start services that depend on each other... OK
2020-09-21_14:27:10_CDT [openHABian] Adding delay on loading openHAB rules... OK
2020-09-21_14:29:34_CDT [openHABian] Adding an openHAB dashboard tile for 'openhabiandocs'... Replacing... OK
2020-09-21_14:29:48_CDT [openHABian] Preparing openHAB folder mounts under '/srv/openhab2-*'... OK
2020-09-21_14:29:50_CDT [openHABian] Applying file permissions recommendations... OK
2020-09-21_14:30:05_CDT [openHABian] Applying miscellaneous system settings... OK
2020-09-21_14:30:05_CDT [openHABian] Setting up Samba network shares... OK
2020-09-21_14:30:06_CDT [openHABian] Setting up Samba service... OK
2020-09-21_14:30:10_CDT [openHABian] Updating openHAB Log Viewer (frontail)... OK
2020-09-21_14:30:11_CDT [openHABian] Configuring openHAB Log Viewer (frontail)... OK
2020-09-21_14:30:11_CDT [openHABian] Setting up openHAB Log Viewer (frontail) service... OK
2020-09-21_14:30:12_CDT [openHABian] Adding an openHAB dashboard tile for 'frontail'... Replacing... OK
2020-09-21_14:30:12_CDT [openHABian] Adding slightly tuned bash configuration files to system... OK
2020-09-21_14:30:12_CDT [openHABian] Adding slightly tuned vim configuration file to system... OK
2020-09-21_14:30:12_CDT [openHABian] Adding openHAB syntax to vim editor... OK
2020-09-21_14:30:13_CDT [openHABian] Adding openHAB syntax to nano editor... OK
2020-09-21_14:30:14_CDT [openHABian] Adding openHAB scheme to multitail... OK
2020-09-21_14:33:25_CDT [openHABian] We hope you got what you came for! See you again soon ;)
1 Like

Certainly so. But splitting brains (dev <-> user) all day is giving me enough of an headache already.
So please you or anyone reading this suggest any changes to the docs that make this more understandable, and I’ll be happy to add them.

1 Like

You don’t have to change anything in openhabian.conf. Changes only take effect when you initiate an unattended installation run.
If all you wanted to do is switch from Zulu 8 to 11, you should simply have used openhabian-config in interactive mode.

Well yes. But that’s the fate of the 5% you chose to be part of :expressionless:
And every of your fellows would have needed his own “simple sentence”.

Worse even, I did not write this part of the code myself so didn’t know how exactly it was supposed to work.
And it wasn’t changed in years. I wonder why it worked for you earlier.
So quite something you would not want to touch as a developer.
I nonetheless did now and think (hope) I didn’t break anything in doing so.

Just want to mention that the official documentation (https://www.openhab.org/docs/installation/openhabian.html#other-linux-systems-add-openhabian-just-like-any-other-software) explicitly states that you should change the “openhabian.conf” and the “install” command in the docu is the “unattended” way. As I am also not a Linux expert I just copy and paste the commands from the docu in my console and hope that it works :slight_smile:

The only thing that confused me, why I ran into the issue, is that the config file contains the line “do not touch/change” but YES, you need to change it in order for the step-by-step guide in the docu to work on a manual Linux install when the username and password are different.

Suggested Solution:
My install problem could have been prevented when instead of “do not touch/change” the comment would have been something like “changes to this file are only required if the operating system was installed manually and user/pass are different to what you see below.”
Because the “do not touch/change” comment contradicts what the install guide says resulting in confusion.

1 Like

Well, to give some background: the unattended install was only ever meant to be used in the image based postinstall.
There the user to exist is known upfront, hence the comment which is correct in that context.
when we made the unattended install available to non-image installers, too, we should have changed that but it slipped us.

Also it was not intentional to instruct non-image installers to use unattended install at all hence all the comments about stuff that may fail when doing so.
If you had read the document openhabian.md top-down (the online docs are an import of that) I think you would have noticed.
Unfortunately the way we linked it into the online docs caused readers to jump right to the unattended section.

Apologies. But that’s the sort of problems that happen sometimes if someone starts a project and some others continue driving it.
cc: @ndye @holgerf

1 Like

All good, we provide feedback in order to help improve the system for everybody and make it more accessible. I totally understand the situation :grinning:

FYI, that was changed now.

1 Like