okay but that’s a bug then. Can you fix that along the way, too?
When testing openHABian v1.12.0-beta4, I noticed something strange when adjusting username and userpw in the openhabian.conf.
I changed the default user and the default password:
# if it exists, the default user (with its working environment) will be renamed to this username given here ...
username=test_user
# ... and given this password. The password will be removed from this file after completion for security reasons.
userpw="test_pw"
But the log then shows this:
+ echo -n '2025-09-09_08:39:14_UTC [openHABian] Changing default username ... '
2025-09-09_08:39:14_UTC [openHABian] Changing default username ... + [[ -z test_user ]]
+ id openhabian
+ echo SKIPPED
SKIPPED
++ timestamp
++ printf '%(%F_%T_%Z)T\n' -1
+ echo -n '2025-09-09_08:39:14_UTC [openHABian] Changing default password... '
2025-09-09_08:39:14_UTC [openHABian] Changing default password... + [[ -z test_pw ]]
+ echo test_user:test_pw
+ chpasswd
chpasswd: (user test_user) pam_chauthtok() failed, error:
Authentication token manipulation error
chpasswd: (line 1, user test_user) password not changed
So the username change gets skipped, and chpasswd throws an error when setting the password.
I added some debug output, and it looks like id "$userName" is not available at that point. Apparently the user hasn’t been created yet or is not available in the PAM/Shadow DB at that stage.
What confuses me even more is that I can log in later with test_user and test_pw — but not always.
And the user openhabian:openhabian still exists afterwards as well, and I can log in with it too.
This function is supposed to only be used on first boot of an image and I’m regularly using it without problems.
I’ve investigated this further and can now reliably reproduce and explain the behavior.
I tested this on Raspberry Pi OS Bookworm, where /boot/userconf.txt is processed immediately and the user becomes available right away.
On Trixie, however, the userconfig.txt handling is significantly delayed. The systemd service userconfig.service reports as “finished” before the new user is actually present in the passwd/shadow database. openHABian, however, runs its username/password logic too early and therefore misses the newly created user.
Actual behavior on Trixie:
-
id "$userName"returns “not found” because the user has not yet appeared -
openHABian logs: “Changing default username … SKIPPED”
-
chpasswdfails because the user does not exist yet -
only several seconds later the user suddenly shows up
-
depending on timing, this can lead to both
openhabianand the custom user existing, inconsistent passwords, or unpredictable login success
In my measurements, the user created via userconf.txt appears 10–20 seconds after boot on Trixie, even though userconfig.service is already inactive. Bookworm does not show this delay.
Fix / Workaround:
Instead of relying on the service state, it is more reliable to explicitly wait until the user is present:
for i in {1..200}; do
if id -u "$userName" >/dev/null 2>&1; then
break
fi
sleep 1
done
This makes the username/password setup stable on both Bookworm and Trixie.
If desired, I can also submit this as a PR using the tryUntil() routine.
Thanks for your investigation. Yes please make it a PR with tryUntil()
Could you please create a PR then retrieve and deploy the image GitHub builds for your PR to re-validate beta5 if we still need to wait for the user to ‘appear’.
beta5 is based on the first Raspi OS trixie update which may have changed things. Thanks.
I’ve tested it now and it works.
The tryUntil() for Wi-Fi is definitely required — without it the connection is not reliable, and it usually takes a few attempts until it finally connects.
For the user creation, the delay no longer seems strictly necessary with the latest Trixie update, as the user appears immediately. But it doesn’t hurt to keep the function in place.
1 Like
have you tried using the hotspot?
There’s still a problem with the selector web page not coming up. Wonder if your fix changes anything about that.
I’ve tested this with the following settings:
# WiFi settings. An ethernet connection is recommended.
# If you have a RPi3 or higher, RPi0W or a supported external WiFi dongle, the WiFi
# ...
wifi_ssid="xxxxx"
wifi_password="xxxxxx"
# start comitup hotspot if internet is not reachable
hotspot=enable
hotspotpw=openhabian
With my fix, the system now connects to Wi-Fi reliably, so the hotspot never comes into play anymore.
Without the fix, Wi-Fi didn’t come up at all, so the device stayed in hotspot mode.
Regarding the “selector page” you mentioned:
Do you mean the page on port 81 that shows the installation progress?
If not, could you clarify which page exactly you’re referring to?
I meant the web page that the hotspot directs you to when you connect to its AP.
Connecting there should fire up your browser, but that didn’t work reliably.
So my question is if with your fix it now does? I tested it once and it worked, but that of course is not a proof and I need others to confirm.
Ah, I see … the redirect didn’t work for me before the fix either.
The hotspot itself always works for me, but the automatic redirect never appeared. I think this is because many modern devices force HTTPS or IPv6, while comitup only uses HTTP redirects. Because of that, the captive portal does not appear automatically.
nope, it used to work with bookworm
So does it work for you now?
No, it still doesn’t work.
I can’t reach it via the IP anymore either.
but the hotspot AP shows up? Pls check the log if comitup gets installed and started.
Eventually try to get it to work using comitup-cli
The hotspot AP does show up.
Comitup is installed and the service starts, but it doesn’t work correctly because port 53 is already in use.
In the log I see:
dnsmasq: failed to create listening socket for port 53: Address already in use
Here is thecomitup-cli output:
Host openHABian-5.local on comitup version 1.43
'single' mode
HOTSPOT state
State: HOTSPOT
Connection: openHABian-5
Points:
1: Pretty Fly For A WiFi
2: Vodafone-5B64
3: TP-Link_9C12
4: Du kommst hier nicht rein!
5: WLAN Schnorrer, hier klicken
6: Vodafone Homespot
7: Vodafone-FC9C
8: Vodafone-5D6C
9: WLAN-853348
10: Vodafone Hotspot
11: Vodafone-0424
Available commands:
(r)eload
(i)nfo
(l)ocate the device
re(n)ame the device (restarts the service)
connect to <n>
(m)anual connection
(x) Factory reset (no warning)
(q)uit
Just want to leave a positive Feedback to V12 Beta 5 which I flashed to a SD Card running on a Raspi 4 - it is the first time (at least for me) I could Install the “deConz” optional component from within the openhab config tool without Errors. When I tried the same using the official Release from August 2025, the “deConz” Installation failed (most likely because of the Java libs). Now in Beta 5 after restoring the v4.3.3 full Backup everything is Up&running . Thanks a lot 
!
1 Like
Hi @mstormi
I just wanted to add something
The default for all the openhabian’s is to store memory dumps from Java when it fails is $OPENHAB_USERDATA one of the side effects of this is that it unnecessarily increases the size of the backups that are run from the openhabian-config tool
Either a message saying there are large files there or excluding it would be a great additional for the openhabian-config tool Either- I am putting this under the this beat in case it needs some bigger amendments that can be included here.
Well that is not so straightforward as you put it.
First, very few Installations produce these, but if so, you (user) will want to keep them.
Second, it is not openHABian to create the backup, it’s openhab-cli from openhab-distro.
I suggest you open a request with that repo on GitHub to exclude files named with some pattern from backups.
ok , thanks i will do so - you are of course correct about very few systems producing them - I was debugging a system that I needed to do because of system failures and then was backing up (because of System failures) and then i filled the partition causing a … system failure 
I’ve created a PR to exclude heap and crash dumps as well as the big model files from a few voice add-ons from the backup.
3 Likes