Raspberry Pi openHab image does not install, debug does not work

I know this is long. I’ve included a log, command output, and I’ve tried to include every detail that might be important. The behaviors I’m getting make little or no sense to me. An automated installer should work, but it’s not and changing the debug level does not help.

  • Platform information:
    • Hardware: Raspberry Pi 3 & 4 using SD card for storage
    • OS: Lastest openHAB image (openhabian-pi-raspios64-202208152014-gitbe9d23e-crc8b028846.img)
    • Java Runtime Environment: See OS above
    • openHAB version: see OS above
  • Issue of the topic: It won’t install.

This is a follow-up to this thread. I’m starting a new thread because I have more information and have found a few things that do not “work as advertised” and think this needs some level of discussion.

I had tried to install oH a number of times by making an image, putting it in, booting it, and I have had similar results for 8-10 different install attempts (and I’m not exaggerating about that). Some of the issues include unclear documentation. I’ve found problems with logging levels and behaviors that don’t make sense. I’ve followed directions and found the results to be puzzling. I had gone through it so many times, I finally stopped, burned 5 more images on SD cards, took a break for most of the day, then started again, noting each step and what I got. Here’s what I did and the results.

  1. I burned the latest images for a Raspberry Pi as listed above. I have tried this image on a Pi 4 and a Pi 3. Basically the same results for each, in the long run, on EVERY attempt.

  2. Looked for openhabian.conf. On most attempts I didn’t do this, only started on recent attempts. I plugged the SD card with the oH image on it into a Pi system running Debian (or Raspbian - don’t remember which I have on that Pi). Since, on an oH system, openhabian.conf is on /etc, that’s where I looked. Note that the page on troubleshooting, under the 2nd subheading (" Did my Installation succeed? What to do in case of a problem?“), in the 2nd paragraph under that subheading, it talks about changing the debugmode to maximum. It does NOT say where this file is. In only ONE location on that page (” Other Linux Systems (add openHABian just like any other software)") does it ever mention the path of /opt/openhabian/build-image/openhabian.conf. And that is a section that should be skippable for working with a Pi image. Also note that the path /etc/openhabian.conf is given 3 times, twice in that same section and once in “Networking.” This is frustrating and confusing. I had not read the “Other Linux Systems” section since it didn’t apply to my situation. I had to hunt down, on my own, and find /opt/opehabian/build-image/openhabian.conf.

  3. I edited this file (/opt/openhabian/build-image/openhabian.conf) so I had debugmode=maximum and checked to be sure I had saved it.

  4. I ejected the SD card with my image from that Pi so there would be no buffer issues, then put it in a Pi 3 (again, I’ve tried it on a Pi 4 as well, with the same results) and turned the Pi on. When I do this, I leave a monitor on so I can see what’s going on.

  5. Eventually I get a screen for configuring my keyboard. After that, it asks me to supply a name for a default user and a password. I’ve noticed I get this BEFORE the user openhabian is created and after - it can show up either way. I have to pick the keyboard type and create a user and password. This time, I left it and pulled up the status on for the system and it reported, after about 3-5 minutes, that the configuration was done and it would reboot. When it did, I tried to log in through ssh and could not. I tried using the users openhab, openhabian, and pi. I couldn’t connect with ssh on any of them.

  6. I tried going through the configuration screen to define my keyboard and default user - this time I had a keyboard issue, but finally got a working keyboard. I specified to use “pi” as the default user and gave it my password. It automatically logged me in. I went back to my main workstation and could ssh in and connect using pi. I checked in /etc/passwd and /home. There was no user named either openhab or openhabian at all. I checked and found the file /opt/openHABian-install-successful existed. But I could not pull up the web interface for it.

  7. I looked at /opt/openhabian/build-image/openhabian.conf and still saw debugmode=maximum. I checked in /etc/openhabian.conf and saw debugmode=off. I checked /boot/first-boot.log. The results are at the end of the message. Note this is WITH debugmode set to maximum. But the log I got looks identical to the log I have been getting over and over, in every attempted install. Note, in that log, that packages just don’t install. None install. And, again, this log is on maximum debugging! Also note that even with the results in this log, the setup is STILL reporting that oH has been successfully installed.

  8. I’ve tried, in the past, deleting /opt/openHABian-install-successful and rebooting. I’ve done this AND set debugmode=maximum in /etc/openhabian.conf and when it finishes rebooting, that’s set to maximum, but first-boot.log is the same - not at all any other info for debugging.

  9. I’ve also touched the file /opt/openhabian-install-failed and rebooted. Same general results.

  10. I’ve done #8, but instead of rebooting, run /opt/openhabian/openhabian-setup.sh and picked the option to install oH. It does. Debugging in /opt/openhabian/build-timage/openhabian.conf is still maximum, but in /etc/openhabian.conf it’s off.

  11. Since no packages were shown as installed, my concern was that something was up with apt. I find that odd, since I have a number of Pis and a couple media servers on my LAN, all on Debian or Raspbian or a variation of Debian. Even one on Ubuntu. None of them have had issues with apt and package management. Sometimes there are delays, due to rural internet, and during one test install, internet was off for a while during a heavy storm. (So I tossed that install out as a poor example under bad conditions.) Since the first package I see in the logs that does not install is git, I checked on it:

dpkg-query: package 'git' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files.```

I saw this and, as a test, figured it would be good to test installing git:

```pi@openhabian:~ $ sudo apt-get install git

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for pi:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 git : Depends: liberror-perl but it is not going to be installed
       Depends: git-man (> 1:2.30.2) but it is not going to be installed
       Depends: git-man (< 1:2.30.2-.) but it is not going to be installed
 libc6-dbg : Depends: libc6 (= 2.31-13+rpt2+rpi1+deb11u4) but 2.31-13+rpt2+rpi1+deb11u3 is to be installed
 libc6-dev : Depends: libc6 (= 2.31-13+rpt2+rpi1+deb11u4) but 2.31-13+rpt2+rpi1+deb11u3 is to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).```

I haven't had this issue with apt for so long I don't remember if I've ever seen it. I switched to Debian based Linux from rpm based distros back around 2005 and in that dime, I don't remember seeing issues with unmet dependencies unless those packages are not in any repositories in my configuration. So I tried fixing it:

```pi@openhabian:~ $ sudo apt --fix-broken install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  libc6
Suggested packages:
  glibc-doc
Recommended packages:
  libnss-nis libnss-nisplus
The following packages will be upgraded:
  libc6
1 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
5 not fully installed or removed.
Need to get 2,460 kB of archives.
After this operation, 3,072 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.raspberrypi.org/debian bullseye/main arm64 libc6 arm64 2.31-13+rpt2+rpi1+deb11u4 [2,460 kB]
Fetched 2,460 kB in 3s (711 kB/s)
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 35706 files and directories currently installed.)
Preparing to unpack .../libc6_2.31-13+rpt2+rpi1+deb11u4_arm64.deb ...
Unpacking libc6:arm64 (2.31-13+rpt2+rpi1+deb11u4) over (2.31-13+rpt2+rpi1+deb11u3) ...
Setting up libc6:arm64 (2.31-13+rpt2+rpi1+deb11u4) ...
Setting up linux-libc-dev:arm64 (1:1.20220830-1) ...
Setting up libc6-dbg:arm64 (2.31-13+rpt2+rpi1+deb11u4) ...
Setting up libc-dev-bin (2.31-13+rpt2+rpi1+deb11u4) ...
Setting up libc-devtools (2.31-13+rpt2+rpi1+deb11u4) ...
Setting up libc6-dev:arm64 (2.31-13+rpt2+rpi1+deb11u4) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u3) ...```

Now that it's fixed, I try adding git again:
```pi@openhabian:~ $ sudo apt-get install git
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  git-man liberror-perl
Suggested packages:
  git-daemon-run | git-daemon-sysvinit git-doc git-el git-email git-gui gitk gitweb git-cvs git-mediawiki git-svn
The following NEW packages will be installed:
  git git-man liberror-perl
0 upgraded, 3 newly installed, 0 to remove and 18 not upgraded.
Need to get 7,287 kB of archives.
After this operation, 37.7 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian bullseye/main arm64 liberror-perl all 0.17029-1 [31.0 kB]
Get:2 http://deb.debian.org/debian bullseye/main arm64 git-man all 1:2.30.2-1 [1,827 kB]
Get:3 http://deb.debian.org/debian bullseye/main arm64 git arm64 1:2.30.2-1 [5,428 kB]
Fetched 7,287 kB in 5s (1,529 kB/s)
Selecting previously unselected package liberror-perl.
(Reading database ... 35706 files and directories currently installed.)
Preparing to unpack .../liberror-perl_0.17029-1_all.deb ...
Unpacking liberror-perl (0.17029-1) ...
Selecting previously unselected package git-man.
Preparing to unpack .../git-man_1%3a2.30.2-1_all.deb ...
Unpacking git-man (1:2.30.2-1) ...
Selecting previously unselected package git.
Preparing to unpack .../git_1%3a2.30.2-1_arm64.deb ...
Unpacking git (1:2.30.2-1) ...
Setting up liberror-perl (0.17029-1) ...
Setting up git-man (1:2.30.2-1) ...
Setting up git (1:2.30.2-1) ...
Processing triggers for man-db (2.9.4-2) ...```

So it works.

11) In the past, with previous installs, once I get that result, my thinking has been that something went wrong with apt and that it's fixed, so I ran the install script in /opt and the same packages did not install, just like before. I did not do it this time. I'm tired. I'm burned out. I need help with this. (To his credit, @Wolfgang_S has been helping me with these issues in the other thread I linked to above. I appreciate that.) 

Overall, it's odd that, time after time, I run an automated install on different Pis, both with the image on an SD card or on a USB memory stick and I get the same failures.

**SUMMARY**
I am encountering a number of problems with the automatic install:
1) The directions in Troubleshooting (and on the debugging page) do not specify just where openhabian.conf is located. (I've found that, but specificity would be helpful on the web pages!)
2) My changing the debugmode setting to maximum seems to have no effect on the debug logs provided. (And if I change it in /etc/openhabian.conf, in some situations when I reboot or use the setup script, that setting is set back to off.)
3) Even with a number of packages being reported as not installed, the process finishes and creates the file in /opt to say oH is installed
4) The big issue seems to be packages that are not being installed and when I run a test, I find there's a problem with apt that I can fix, but that does not help make the install work after that.
5) There's one issue I haven't mentioned that I'm hoping doesn't matter. I have done successful installs of oH on a Pi in the past without any issues. While there are times I doubt my internet connection, usually it's "normal." My wife and I stream a lot of video over it without problems and I upload and download files without issues. I use Starlink, which is LEO satellite (which is why it sometimes goes out during a heavy thunderstorm). Starlink uses CGNAT (Common Gateway Network Address Translation). That means that my house does not get an individualized IP address. I don't know if that matters and unless oH is doing something unusual that depends on my house having an individualized IP address, it shouldn't be an issue. If it is an issue, I think it needs correction, since Starlink came out of beta in April and they're adding more and more users. For many of us in the boondocks, it's going to be a big deal to use it, since it's the only good service in some areas and Starlink is spreading to many countries now.

I make mistakes. I would love to hear this is something simple I'm doing wrong, but since it goes bad when I just burn an image and boot it, I think there's a bug or that somehow I now have a situation that the setup system can't handle.


======================
/boot/first-boot.log:


2022-04-04_15:41:57_BST [openHABian] Starting the openHABian initial setup.
2022-04-04_15:41:57_BST [openHABian] Storing configuration… OK
2022-04-04_15:41:59_BST [openHABian] Starting webserver with installation log… OK
2022-09-09_06:38:50_BST [openHABian] Changing default username and password… OK
2022-09-09_06:38:59_BST [openHABian] Setting up Ethernet connection… OK
2022-09-09_06:38:59_BST [openHABian] Ensuring network connectivity… OK
2022-09-09_06:38:59_BST [openHABian] Waiting for dpkg/apt to get ready… OK
2022-09-09_06:39:12_BST [openHABian] Updating repositories and upgrading installed packages… OK
2022-09-09_06:39:49_BST [openHABian] Installing git package… FAILED
2022-09-09_06:39:52_BST [openHABian] Updating myself from GitHub - openhab/openhabian: openHABian - empowering the smart home, for Raspberry Pi and Debian systems, openHAB3 branch… OK
2022-09-09_06:39:52_BST [openHABian] Starting execution of ‘openhabian-config unattended’… OK
2022-09-09_06:39:52_BST [openHABian] Checking for root privileges… OK
2022-09-09_06:39:54_BST [openHABian] Updating Linux package information… \ ESC[2D| ESC[2D/ ESC[2D- ESC[2D\ ESC[2D| ESC[2D/ ESC[2D- ESC[2D\ ESC[2D| ESC[2D/ ESC[2D- ESC[2D\ ESC[2D| ESC[2D/ ESC[2D- ESC[2D\ ESC[2DOK
2022-09-09_06:40:03_BST [openHABian] Loading configuration file ‘/etc/openhabian.conf’… OK
2022-09-09_06:40:03_BST [openHABian] Adjusting swap size to 1819 MB… OK (reboot required)
2022-09-09_06:40:04_BST [openHABian] Setting timezone based on openhabian.conf… OK (Europe/Berlin)
2022-09-09_07:40:05_CEST [openHABian] Enabling time synchronization using NTP… OK
2022-09-09_07:40:05_CEST [openHABian] Setting locale based on openhabian.conf… FAILED (reconfigure locales)
2022-09-09_07:41:09_CEST [openHABian] Setting hostname of the base system based on openhabian.conf… OK
2022-09-09_07:41:09_CEST [openHABian] Setting the GPU memory split down to 16MB for headless system… OK
2022-09-09_07:41:09_CEST [openHABian] Enabling Audio output… OK
2022-09-09_07:41:10_CEST [openHABian] Installing basic can’t-be-wrong packages (screen, vim, …)… FAILED (remove raspi-config)
2022-09-09_07:41:12_CEST [openHABian] Installing additional needed packages… FAILED
2022-09-09_07:41:15_CEST [openHABian] Adding slightly tuned bash configuration files to system… OK
2022-09-09_07:41:15_CEST [openHABian] Adding slightly tuned vim configuration file to system… OK
2022-09-09_07:41:15_CEST [openHABian] tailscale VPN installation… SKIPPED (no preauthkey defined)
2022-09-09_07:41:15_CEST [openHABian] Applying miscellaneous system settings… OK
2022-09-09_07:41:15_CEST [openHABian] Installing FireMotD required packages (bc, sysstat, jq, moreutils)… FAILED
2022-09-09_07:41:18_CEST [openHABian] Fetching OpenJDK 11… FAILED
2022-09-09_07:41:20_CEST [openHABian] Installing OpenJDK 11… FAILED
2022-09-09_07:41:23_CEST [openHABian] Beginning install of latest openhab release (stable)… OK
2022-09-09_07:41:23_CEST [openHABian] Adding required keys to apt… OK
2022-09-09_07:41:24_CEST [openHABian] Installing selected openHAB3 version… FAILED
2022-09-09_07:41:37_CEST [openHABian] Getting initial openHAB configuration… SKIPPED (backup not found at /boot/initial.zip)
2022-09-09_07:41:37_CEST [openHABian] Activating the openHAB console on all interfaces… FAILED (sshHost)
2022-09-09_07:41:37_CEST [openHABian] Adding openHAB syntax to vim editor… OK
2022-09-09_07:41:42_CEST [openHABian] Adding openHAB syntax to nano editor… OK
2022-09-09_07:41:43_CEST [openHABian] Adding openHAB scheme to multitail… FAILED (remove default configuration)
2022-09-09_07:41:43_CEST [openHABian] Preparing openHAB folder mounts under ‘/srv/openhab-*’… OK
2022-09-09_07:41:50_CEST [openHABian] Installing Samba… FAILED
2022-09-09_07:41:53_CEST [openHABian] Installing Frontail prerequsites (NodeJS)… FAILED
Failed to open terminal.ESC[1;24rESC[4lESC)0ESC[m^OESC[37mESC[40mESC[1;24rESC[HESC[JESC[1;1HESC[35mESC[K

I didn’t and won’t dig into/retrace whatever you tried.
But as it seems you have made some “I want it my way” changes (such as to use your own user), my main advice is: don’t.
Start with and use the defaults. openHABian is an APPLIANCE, not a general purpose OS. Don’t mess around on Linux level.
When you have things working this way, you can restart and explore the options, but get the basics working first.

It does. You should be more careful and consequent in reading the docs.
Don’t jump around and cross-read, always mind the context, it is important. Seems you didn’t always do that, you are confusing yourself that way.
(just one example: as you want to install on RPi why do you read about installing on other Linux systems and use any of the information found there ? It obviously will not apply to RPi installs.)

While openhabian.conf ends up in /etc, with the Pi image, it is located on the first partition which is a Windows one - it can and should be mounted from your PC. That’s where to change parameters that apply during the installation. That’s where to set debugmode=maximum.
As the installation itself runs unattended, options to affect it must obviously be defined before.
All of this information is in the install docs, close to the beginning right where it belongs.

So you probably have attached a keyboard. The docs are explicit on that openHABian is meant to run headless and even tell you to remove any keyboard. It’s a likely source of your issues.

Remove the keyboard, mount the partition from your PC to edit openhabian.conf and set debugmode=maximum but nothing else.
Then try again and you should obtain a comprehensive /boot/first-boot.log.
Proceed with the debug guide if needed.

Thank you! This solved the issue.

This is what turned out to be the issue! Thank you!

Also an interesting note: I deal with a number of Pis around here, in my house, in our barn (which includes my workshop) and even one out in the middle of our big field, where it monitors conditions in the weatherproof box where my Starlink equipment is, on a post where the Starlink dish is mounted. I have several battery powered keyboard and mouse combination sets. They connect wirelessly to a USB dongle. (Both going to the same dongle.) When I’m using terminal only, the mouse is always off. I have the keyboard off most of the time except (to save the battery) when I’m typing. On most systems, it doesn’t see the keyboard until I turn it on. So I had always figured the USB dongle was “dead” or “invisible” to the OS unless the keyboard or mouse was turned on.

The setup system was having problems with just the dongle, even when the keyboard was off. So that’s worth noting.

So that solved the issue, but there is another related point that is not clear:

No, I have to disagree. I’m not saying this to argue, but if the issue is that one should NOT have a keyboard attached, as opposed to the install not needing one, it’s not clear. I searched for the word “keyboard” in the openHabian page. It’s referred to 3 times. Once in features:

Out of the box, the openHABian image provides lots of useful Linux tools:

* Hassle-free setup without a display or keyboard, connected via Ethernet or [Wi-Fi]

The next time it says, “openHABian is designed as a headless system, you will not need a display or a keyboard.” The third time is a stronger statement: " An RPi is not (well, not necessarily ) to be used with a keyboard and display."

The difference is all three of these points make it clear a keyboard and monitor are not needed. They do not say, “Make sure a keyboard is not plugged in during setup.” I had read these sections while going through the documentation. If it had specified the keyboard interfered instead of that it was just not needed, I would not have had it plugged in.

This isn’t just about semantics. I have a number of headless Pi systems running several different OSes, most a variation of Debian. I always leave a keyboard and monitor hooked up when any OS is setting up and running for the first time. I’ve never had an issue before. Even in the pre-RPi days, when I worked with headless systems that did not have connections for a keyboard or monitor, I never had a situation where I had to disconnect, say, the ethernet or serial cable while software was setting itself up.

There is a clear difference between saying, “This is not needed,” and saying, “This must be left off.”

I don’t know how to say this without sounding snarky, and that is NOT the intent. I have found everyone on this board to be super-helpful. I’m converting to oH from another system because I found more help here on oH than I found for the other system.

However, I think this is an important point. It’s not so much for you, @mstormi, unless you’re on the documentation team, as I’m including it for reference, since that’s one of the topics here. Speaking as a former special ed teacher, and someone with some learning disability issues myself, I feel I need to address this. (I taught writing, including technical writing as part of my job in that situation. And after I burned out and started a business based on my own software, I had to do a lot of technical writing and make it simple and easy so my customers would spend as little time as possible reading it so they could do their jobs.)

Not everyone can read documentation linearly. Many people, due to learning issues, need to put things together in a way that helps them attach each new piece of information with what they already have in their heads. So that means reading this section and, if it refers to another, go there and read it. HTML is great for people with that kind of issue because we can go through links and put pieces together in our own way. But even for those without learning disabilities, when you have a section like Troubleshooting, that is easily linkable, that section needs to be treated as self-sufficient. It’s like writing a function in programming - each function has local variables and you don’t use a global one unless you specifically declare it. So in a section like Troubleshooting, or on the Debugging page, IF the intent is maximum clarity for readers, terms from other sections should be redefined, just the way global variables need to be spelled out.

Writing style says if you use abbreviations, to start with defining the full term - but, beyond that,if you have a sectional document, include a redefining of it in the major sections. If you have an HTML document with a section you can link to, then it’s important to redefine the term in each linkable section - like working with global and local variables. It’s not reasonable to expect someone starting a document at a link in the middle fo the page to go up the page to find out, for instance, just which filepath (out of several) is being specified.

Again, I’m not saying this to be snarky. OpenHab documentation, for the most part, is amazingly well done and I know people hate writing documentation. But I think this is a small change that should be considered - both for helping people with learning disabilities, as well as for keeping in mind that when people follow a link, they’ll start reading at that link.

@mstormi is a very big part of openHABian and without his contrubutions openHAB would not be as accessable as it is. One thing that he can not do is forget how it works and start from the beginning none of us can.

Please rewrite the doc as it can be your valuable contributon to openHAB

Seems we have an unfortunate diff of the docs sources which contain an explicit warning about this and its mirror on the website which is what you read.
@Confectrician could you please take a look? I’ve just manually triggered another docs update action but the missing change is dated Aug, 4 while there has been another docs action run after that so seems something’s wrong there.

Thank you for checking on that - and for seeing that I was not trying to just be snarky about things!

I’m self-taught, so sometimes I have to clarify terms. Are you saying that the document source does have this warning and the warning has not yet made it to the web page? (Just making sure I’m following.)

Also, I’m curious, in case you or anyone else can shed some light on this. What is going on that the keyboard being plugged in creates an issue? My guess is that when Debian detects a keyboard, it brings up the dialog to specify keyboard settings and when that happens, it doesn’t get to other functions (like, maybe, updating repositories?) until after the keyboard has been specified and, meanwhile, oH’s install system is still proceeding? I’m just wondering why the keyboard presence can interfere and why that isn’t something that can be easily taken care of?

Sorry it affects the learning disabled (wasn’t aware) but sorry, no. To write everything self-sufficient while also covering basic other demands at good docs such as Do Not Repeat is not possible for the kind of complex, layered, dependent technical information like this that we need to cover.
That is no “small” change like you suggest it is.
Redundant information is a real bummer when you have to also maintain the docs as these are ‘living’ documents that need to be reworked on certain occasions.
This is a trade-off and it was consciously decided to minimize redundancies.

While I highly appreciate you are trying to help weaker and way too often ignored members of society, I also believe that trying to apply your general teaching principles to this type of task and document isn’t appropriate.
This is no teaching literature to some science. It’s a manual for software, it’s an install recipe.
It HAS to be read linearly else you will be missing important steps, information or overlook preconditions (which is what happened to you).
Even some learning disabled person can linearly read a document - in addition to taking whatever cross-read-on-off self study approach first to get to understand the stuff.
I expect any reader to at a minimum fully read the web page once. There’s many (not you) that are even too lazy to do that and frankly, I have little pity on them when they fail because of stuff they would have known if they had consciously and comprehensively read the documentation I have written for them which I did in addition to writing the software in the first place !

We cannot cater for all possible entries and traversions. People to google, to search on the OH site, people to follow whatever link on the internet pointing to us ?
What’s next, condense it so much that the 5-line Google preview excerpt will also be self-sufficient ? Again sorry but no, sorry.

As @denominator mentioned I myself wrote most of this and yes, it was annoying, cumbersome work I hated but thought I had done an at least somewhat good job on until I read your critics.
As James also pointed out, anyone can write and enhance existing docs.
Now that you have followed a non-linear and unfortunate path but finally got it working, you should be having collected enough knowledge of the openHABian install procedure that you can now rewrite the docs to match your aspired standard. Put that to use with your teaching and writing competencies, and the docs team will be happy to take your PR.

The last stable version docs website build is dated to Aug 12th.
The changes affected have been introduced in the docs Aug 15th.
So the build system did not recognize those changes correctly, alltough the configuration is looking good after checking it.

I have to investigate what is happening and why it is not triggering the builds for the stable homepage.
Anyway i will setup a scheduled build once a week now as a workaround as long as the problem has not been identified.

1 Like

Hm, i just merged your lates changes via deployment automation and the automated build started as expected. :man_shrugging:

I will still have it under observation from now on.

1 Like