openHABian Failing - Never Have Had Problems Before

Hello,

I have used openHABian to successfully install openHAB2 on probably at least 10 different Linux-based machines before over the last year or so without issue. I recently had to wipe my main Linux openHAB 2 server and start with a clean OS installation. I am running MX Linux 19.2 (which is essentially Debian 10 “Buster”) and have followed the same openHABian installation/setup process / instructions that I have always used without issue except I cannot for the life of me get it to work properly. I’ve tried for the better part of a week now to get this working and it’s driving me BONKERS. I run the script as I always have when setting up openHAB, as a “Manual / Fresh Setup” but something is just wrong with the script. It doesn’t seem like it’s actually installing openHAB when it says it is and skips to the part where it says it is setting up the delayed rule loading for OH startup and then it hangs there and then just shows the main openHABian menu. No error messages or anything. Then if I manually try to run through some of the setup steps, such as fixing permissions under “Apply Improvements” it then gives the following error:

There was an error or interruption during the execution of:                  │ 
                                                       │   "10 | Apply Improvements"                                                  │ 
                                                       │                                                                              │ 
                                                       │ Please try again. If the error persists, please read                         │ 
                                                       │ /opt/openhabian/docs/openhabian-DEBUG.md or                                  │ 
                                                       │ https://github.com/openhab/openhabian/blob/master/docs/openhabian-DEBUG.md   │ 
                                                       │ how to proceed.    

When I attempt to follow the Debug documentation referenced in that error message, it tells me to look at two log files that should have been created, but they are not there.

The only other clues I can find are from the main openHABian terminal window output. It seems to be an issue with PATH variables or user configuration/permissions:

richard@HomeServer:~
$ ohabian
2020-09-02_08:40:34_CDT [openHABian] Checking for root privileges... OK
2020-09-02_08:40:34_CDT [openHABian] Loading configuration file '/etc/openhabian.conf'... OK
2020-09-02_08:40:34_CDT [openHABian] openHABian configuration tool version: [master]v1.6-alpha-791(2582488)
2020-09-02_08:40:34_CDT [openHABian] Checking for changes in origin branch master... OK
2020-09-02_08:40:37_CDT [openHABian] Switching to branch master... OK
2020-09-02_08:41:00_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-02_08:41:01_CDT [openHABian] Installing basic can't-be-wrong packages (screen, vim, ...)... OK
2020-09-02_08:41:02_CDT [openHABian] Installing additional needed packages... OK
2020-09-02_08:41:03_CDT [openHABian] Beginning install of latest openHAB release (stable)... OK
2020-09-02_08:41:06_CDT [openHABian] Adding required keys to apt... OK
2020-09-02_08:41:08_CDT [openHABian] Installing selected openHAB version... OK
2020-09-02_08:41:21_CDT [openHABian] Setting up openHAB service... OK
2020-09-02_08:41:21_CDT [openHABian] Creating dependencies to jointly start services that depend on each other... OK
2020-09-02_08:41:21_CDT [openHABian] Adding delay on loading openHAB rules... OK
2020-09-02_08:43:22_CDT [openHABian] Adding an openHAB dashboard tile for 'openhabiandocs'... OK
2020-09-02_08:43:27_CDT [openHABian] Preparing openHAB folder mounts under '/srv/openhab2-*'... OK
2020-09-02_08:43:29_CDT [openHABian] Applying file permissions recommendations... FAILED (user audio)
2020-09-02_08:43:29_CDT [openHABian] Setting up Samba network shares... OK
2020-09-02_08:43:29_CDT [openHABian] Setting up Samba service... OK
2020-09-02_08:43:32_CDT [openHABian] Updating openHAB Log Viewer (frontail)... OK
2020-09-02_08:43:33_CDT [openHABian] Configuring openHAB Log Viewer (frontail)... OK
2020-09-02_08:43:33_CDT [openHABian] Setting up openHAB Log Viewer (frontail) service... OK
2020-09-02_08:43:34_CDT [openHABian] Adding an openHAB dashboard tile for 'frontail'... OK
2020-09-02_08:43:34_CDT [openHABian] Adding slightly tuned bash configuration files to system... cp: cannot create regular file '/home/user/.bash_profile': No such file or directory
FAILED (user bash_profile)
2020-09-02_08:43:42_CDT [openHABian] Updating Linux package information... OK
2020-09-02_08:43:42_CDT [openHABian] Applying file permissions recommendations... FAILED (user audio)
2020-09-02_09:53:06_CDT [openHABian] We hope you got what you came for! See you again soon ;)

Does anyone have any advice? I just want to turn my stupid lights on and this has been frustrating me for over a week now. I’ve purged openHAB multiple times, purged Zulu, have tried various versions of the Zulu OpenJDK, the Master vs. Stable version of openHABian, etc. but have not gotten anywhere here.

Thank you very much for your help!

Edited:

I have never had any issues whatsoever running openHAB or using openhabian-config whatsoever with my machine and current Debian 10 “Buster” operating system for the past two-plus years that I have been using openHAB in my home.

System/hardware summary:

Snaphot created on: 20200815_1336
System:    Host: <filter> Kernel: 4.19.0-10-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-amd64 
           root=UUID=<filter> ro quiet splash 
           init=/lib/systemd/systemd 
           Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 
           Distro: MX-19.2_x64 patito feo May 31  2020 base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Detachable System: Dell product: Latitude 5175 v: N/A serial: <filter> Chassis: 
           type: 32 serial: <filter> 
           Mobo: Dell model: 0RJJV5 v: A00 serial: <filter> UEFI: Dell v: 1.7.1 date: 11/29/2019 
CPU:       Topology: Dual Core model: Intel Core m5-6Y57 bits: 64 type: MT MCP arch: Skylake 
           family: 6 model-id: 4E (78) stepping: 3 microcode: D6 L2 cache: 4096 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 12096 
           Speed: 600 MHz min/max: 400/2800 MHz Core speeds (MHz): 1: 600 2: 600 3: 600 4: 600 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, 
           STIBP: conditional, RSB filling 
           Type: srbds status: Vulnerable: No microcode 
           Type: tsx_async_abort mitigation: Clear CPU buffers; SMT vulnerable 
Graphics:  Device-1: Intel HD Graphics 515 vendor: Dell driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:191e 
           Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa 
           resolution: 1600x900~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 515 (Skylake GT2) v: 4.5 Mesa 18.3.6 
           compat-v: 3.0 direct render: Yes 
Audio:     Device-1: Intel Skylake Imaging Unit 
           vendor: Dell Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor driver: N/A 
           bus ID: 00:05.0 chip ID: 8086:1919 
           Device-2: Intel vendor: Dell driver: N/A bus ID: 00:14.3 chip ID: 8086:9d32 
           Device-3: Intel Sunrise Point-LP HD Audio vendor: Dell driver: snd_hda_intel 
           v: kernel bus ID: 00:1f.3 chip ID: 8086:9d70 
           Sound Server: ALSA v: k4.19.0-10-amd64 
Network:   Device-1: Intel Wireless 8260 driver: iwlwifi v: kernel port: f040 bus ID: 01:00.0 
           chip ID: 8086:24f3 
           IF: wlan0 state: up mac: <filter> 
           IF-ID-1: vmnet1 state: unknown speed: N/A duplex: N/A mac: <filter> 
           IF-ID-2: vmnet8 state: unknown speed: N/A duplex: N/A mac: <filter> 
Drives:    Local Storage: total: 119.24 GiB used: 93.24 GiB (78.2%) 
           ID-1: /dev/sda vendor: LITE-ON model: L8H-128V2G-11 M.2 2280 128GB size: 119.24 GiB 
           block size: physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: <filter> rev: 10C 
           scheme: GPT 
Partition: ID-1: / raw size: 114.11 GiB size: 111.82 GiB (97.99%) used: 91.67 GiB (82.0%) 
           fs: ext4 dev: /dev/sda2 
           ID-2: swap-1 size: 4.88 GiB used: 1.58 GiB (32.3%) fs: swap 
           swappiness: 15 (default 60) cache pressure: 100 (default) dev: /dev/sda3 
Sensors:   System Temperatures: cpu: 53.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Repos:     No active apt repos in: /etc/apt/sources.list 
           No active apt repos in: /etc/apt/sources.list.d/agornostal-ubuntu-ulauncher-groovy.list 
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://ftp.us.debian.org/debian/ buster-updates main contrib non-free
           2: deb-src http://ftp.us.debian.org/debian/ buster-updates main contrib non-free #Added by software-properties
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://ftp.us.debian.org/debian/ buster main contrib non-free
           2: deb http://deb.debian.org/debian-security buster/updates main contrib non-free
           3: deb-src http://ftp.us.debian.org/debian/ buster main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/google-chrome.list 
           1: deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://mirrors.rit.edu/mxlinux/mx-packages/mx/repo/ buster main non-free
           Active apt repos in: /etc/apt/sources.list.d/nodesource.list 
           1: deb https://deb.nodesource.com/node_12.x buster main
           2: deb-src https://deb.nodesource.com/node_12.x buster main
           Active apt repos in: /etc/apt/sources.list.d/openhab2.list 
           1: deb https://dl.bintray.com/openhab/apt-repo2 stable main
           Active apt repos in: /etc/apt/sources.list.d/skype-stable.list 
           1: deb [arch=amd64] https://repo.skype.com/deb stable main
           Active apt repos in: /etc/apt/sources.list.d/spotify.list 
           1: deb http://repository.spotify.com stable non-free
           No active apt repos in: /etc/apt/sources.list.d/various.list 
           Active apt repos in: /etc/apt/sources.list.d/vscode.list 
           1: deb [arch=amd64] http://packages.microsoft.com/repos/vscode stable main
           Active apt repos in: /etc/apt/sources.list.d/zulu-openjdk.list 
           1: deb [arch=amd64] https://repos.azul.com/zulu/deb/ stable main
           Active apt repos in: /etc/apt/sources.list.d/zulu.list 
           1: deb http://repos.azulsystems.com/debian stable main
Info:      Processes: 268 Uptime: 5h 17m Memory: 3.59 GiB used: 2.71 GiB (75.4%) Init: systemd 
           v: 241 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: quick-system-in 
           running in: quick-system-in inxi: 3.0.36 

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: