I try to install openhabian 1.5 on a Raspian 3B+. I follow the Installation Guide for openhabian on openhab.org.
I have downloaded the latest “openHABianPi” SD card image file and written it to a SD card using Etcher. Raspi is connected via ethernet, directly to the router. I’ve monitor and keyboard attached, so I can see, what is going on.
My problem:
Installation seems to run successfully, except for few entries:
[ TIME ] Timed out waiting for device /dev/serial1
=> should be ok, there is no serial device attached [DEPEND] Dependency failed for Configure Bluetooth Models connected by UART
=> should be ok, there is no Bluetooth Modem connected [openHABian] Setting timezone based on IP geolocation... FAILED [FAILED] Failed to start /etc/rc.local Compatibility
Whenever I reboot the Raspi, setup starts again - with the same errors again. I’m unable to leave this loop. And I have no idea, what to do to enable geolocation (if this is the cause of the setup loop) or what to do to fix the “Compatibility” Error.
I’ve no idea, what is wrong. I managed to eliminate the Setting timezone based on IP geolocation problem by directly setting the timezone in openhabian.conf (on a freshly flashed SD image). But still installation fails and I cannot see any reason why. That is what I see in first-boot.log:
openhabian@openhab:~$ sudo cat /boot/first-boot.log
2020-03-21_09:53:28_GMT [openHABian] Starting the openHABian initial setup.
2020-03-21_09:53:28_GMT [openHABian] Storing configuration… OK
2020-03-21_09:53:28_GMT [openHABian] Starting webserver with installation log… OK
2020-03-21_09:53:34_GMT [openHABian] Changing default username and password… SKIPPED
2020-03-21_09:53:34_GMT [openHABian] Setting up Ethernet connection… OK
2020-03-21_09:53:34_GMT [openHABian] Ensuring network connectivity… OK
2020-03-21_09:53:34_GMT [openHABian] Waiting for dpkg/apt to get ready… OK
2020-03-21_09:57:23_GMT [openHABian] Updating repositories and upgrading installed packages… OK
2020-03-21_10:27:34_GMT [openHABian] Installing git package… OK
2020-03-21_10:29:41_GMT [openHABian] Cloning myself… OK
2020-03-21_10:29:49_GMT [openHABian] Executing ‘openhabian-setup.sh unattended’…
2020-03-21_10:29:50_GMT [openHABian] Checking for root privileges… OK
Hit:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
Hit:2 http://archive.raspberrypi.org/debian buster InRelease
Reading package lists…
2020-03-21_10:30:27_GMT [openHABian] Loading configuration file ‘/etc/openhabian.conf’… OK
2020-03-21_10:30:28_GMT [openHABian] Setting timezone based on openhabian.conf… OK (Europe/Berlin)
2020-03-21_11:30:40_CET [openHABian] Setting locale based on openhabian.conf… OK
2020-03-21_11:37:39_CET [openHABian] Setting hostname of the base system… OK
2020-03-21_11:37:40_CET [openHABian] Setting the GPU memory split down to 16MB for headless system… OK
2020-03-21_11:37:40_CET [openHABian] Enabling Audio output… OK
2020-03-21_11:37:42_CET [openHABian] Installing basic can’t-be-wrong packages (screen, vim, …)… OK
2020-03-21_11:43:05_CET [openHABian] Installing additional needed packages… OK
2020-03-21_11:47:49_CET [openHABian] Adding slightly tuned bash config files to system… OK
2020-03-21_11:47:49_CET [openHABian] Adding slightly tuned vim config file to system… OK
2020-03-21_11:47:49_CET [openHABian] Downloading and setting up FireMotD… OK
2020-03-21_11:54:10_CET [openHABian] Installing Java Zulu 32-Bit OpenJDK… OK
2020-03-21_11:58:41_CET [openHABian] Installing or upgrading to latest openHAB release (stable)… OK
2020-03-21_12:03:16_CET [openHABian] Adding an openHAB dashboard tile for ‘openhabiandocs’… OK
2020-03-21_12:03:17_CET [openHABian] Adding openHAB syntax to vim editor… OK
2020-03-21_12:03:20_CET [openHABian] Adding openHAB syntax to nano editor… OK
2020-03-21_12:03:20_CET [openHABian] Adding openHAB scheme to multitail… OK
2020-03-21_12:03:21_CET [openHABian] Preparing openHAB folder mounts under /srv/… OK
2020-03-21_12:03:22_CET [openHABian] Applying file permissions recommendations… OK
2020-03-21_12:03:44_CET [openHABian] Applying miscellaneous system settings… Creating persistent systemd journal folder location: /var/log/journal
Keeping at most 30 days of systemd journal entries
Vacuuming done, freed 0B of archived journals from /run/log/journal/b97c04ccbb724cac9ab189de553813e9.
OK
2020-03-21_12:03:45_CET [openHABian] Setting up Samba network shares… OK
2020-03-21_12:10:04_CET [openHABian] Installing Node.js for arm (prerequisite for other packages)… OK
2020-03-21_12:11:46_CET [openHABian] Installing the openHAB Log Viewer (frontail) relative to nodejs base /usr/lib… OK
2020-03-21_12:16:07_CET [openHABian] Adding an openHAB dashboard tile for ‘frontail’… OK
2020-03-21_12:16:09_CET [openHABian] Execution of ‘openhabian-setup.sh unattended’ completed.
2020-03-21_12:16:09_CET [openHABian] Waiting for openHAB to become ready…1…2…3…4…5…6…7…8…9…10…11…12…13…14…15…16…17…18…19…20…failed.
After a reboot the installation procedure starts over again.
Problem might be related to the error message Failed to start /etc/rc.local Compatibility that I alway receive directly after the lines above, but which is not logged in first-boot.log. When I execute systemctl status rc-local.service as recommended by the error message I get:
'rc-local.service: Control process exited, code=exited, status=1/FAILURE`
I’m using a standard Raspi 3B+, connected via a wired Ethernet directly to the router.
I’ve no idea how to fix this. Seems as if openhabian is not that “hassle free” as it claims
Im using this image: openhabian-pi-raspbian-201908050414-gitca0976f-crc6a66b5a1.img.xz
I examined the loop in first-boot.bash, that I observe to count to 20 and then fail. Looking at the code I see, that it continuously checks http://localhost:8080/start/index and waits for success (200, OK.)
As a trial to give openhab more time to start, I modified first-boot.bash in such a way that it counts to 100 instead of 20. (Again I used a freshly flashed SD card, and manually set timezone and locale in openhab.conf.) Then I started the next installation trial. That’s what I observed::
While the counter was counting the CPU had a heavy load between 50% and 95% by the “openhab” process
Calls to http://localhost:8080/start/index were constantly failing while the loop counted.First with “connection refused” then, at the count of approx 27, with “404 file not found”
At the count of 57 the loop suddenly stopped and failed. So it failed before reaching the end of the loop. Immediately, at the same time, three things happened:
Error message [FAILED] Failed to start /etc/rc.local Compatibility was shown
Essentially openHABian install has finished and is waiting for openHAB to start properly but it fails to.
Hard to say what the problem is. Is your inet access open or did you cripple that ?
You can rm -f /opt/openHABian-install* to stop your box from re-starting install on boot, then move on to debug openHAB itself. Try to purge and re-install the packages (apt-get purge openhab2 openhab2-addons openhab2-addons-legacy, then ... install ...).
Enable debug (see OH docs) and see openhab.log what it is doing to hopefully get a hint why it does not start up. Eventually use openhabian-config to add packages or to switch to testing or snapshot repo.
I had the same issue, two different SD cards, in the end tried flashing the SD card not with Etcher but with the Raspberry Pi Imager, and that solved my installation loop, tried twice on both cards. When I get my system up and running I will retry with Etcher just to confirm that was the issue, as that’s the only thing I’ve changed.
So give it a try and report back, maybe it works for you. I know some other similar issues were reported fixed after using Win32DiskImager, so there might be something wrong with Etcher, or the combination of Windows/Etcher…
No that’s no good idea, please stop spreading that.
It’ll result in many configurations out there, each to slightly differ, foiling openHABian benefits.
There’s actually a debug guide available now. On the system it’s in docs/.
Anyone to have problems getting openHABian to install please read that first before posting over here.
The Linux install on Raspbian Lite is not equivalent to the image? I thought the OS & scripts were identical except there is an additional WebUI during initial installation…
Theory and practice. As soon as you instruct or enable users to do stuff themselves, and be it just the input to NOOBS, this will result in (most just minimally) diverting versions. These may or may not be of relevance, but in principle you never know. Hence my request not to nudge users there but go with the debug guide.
That makes the openHABian devs responsible for the OS support then.
I am not here in a Linux support capacity.
If your wish is to avoid those different versions, then remove the generic Linux install instructions.
No it doesn’t. But as that indeed would be something we cannot provide, the way forward is to get everybody to have a RPi to (only) use the openHABian image.
If you have x86 hardware you’re on your own when it comes down to OS support questions.
Just want to add that indeed, when I had the openHABian instalation fail, I tried the manual Linux install, which ended up in a lot o head scratching, user renaming, permission issues, samba issues. So, I would say that is for advanced users with patience and knowledge beyond what the average user possess.
To give feedback what actually was the reason for my problem: I accidentally used a Raspi B+ instead of a Raspi 3B and didn’t notice that . Raspi B+ does not have enough power for openHAB and is not officially supported. Obviously a very clear example of a “stupid_user_error”.
Thanks for being frank ( ) to admit.
Then again, we do support RPi 1 so at least it should install… yes it has just 1 core (instead of 4 on newer systems) and just 512 MB (or even 256?), the latter of which is a problem.
I recently changed parameters to affect mem usage so you could try to install again. No warranties though, and clearly it’s not a good idea to run on such a lame box. Get a RPi4/2GB.
. Raspi B+ does not have enough power for openHAB and is not officially supported. Obviously a very clear example of a “stupid_user_error”.
) to admit.