Hi,
does openhabian keep his installation log?
I followed it on the webpage, but somehow lost the connection
openhabian was unresponsive for 10 minutes, then i decided to powercycle the machine.
not the greatest start…
so now I have no clue in what state he is? did it finished? failed? openhab is installed so I guess he finished?
i hope the machine is not half-baked from day1 now…
ok found it, /boot/first-boot.log
phew, it finished succesfully and hanged on reboot
+ echo '2023-08-22_18:27:09_+04 [openHABian] First time setup successfully finished. Rebooting your system!'
2023-08-22_18:27:09_+04 [openHABian] First time setup successfully finished. Rebooting your system!
++ timestamp
++ printf '%(%F_%T_%Z)T\n' -1
+ echo '2023-08-22_18:27:09_+04 [openHABian] After rebooting the openHAB dashboard will be available at: http://knx:8080'
2023-08-22_18:27:09_+04 [openHABian] After rebooting the openHAB dashboard will be available at: http://knx:8080
++ timestamp
++ printf '%(%F_%T_%Z)T\n' -1
+ echo '2023-08-22_18:27:09_+04 [openHABian] After rebooting to gain access to a console, simply reconnect using ssh.'
2023-08-22_18:27:09_+04 [openHABian] After rebooting to gain access to a console, simply reconnect using ssh.
+ sleep 12
++ command -v python3
+ [[ -x /usr/bin/python3 ]]
+ bash /boot/webserver.bash inst_done
+ sleep 12
++ command -v python3
+ [[ -x /usr/bin/python3 ]]
+ bash /boot/webserver.bash cleanup
+ running_in_docker
+ [[ -n '' ]]
+ grep -qs 'docker\|lxc' /proc/1/cgroup
+ [[ -f /.dockerenv ]]
+ return 1
+ reboot
I attempted to migrate my system to openhabian 1.8 and failed.
after initial setup, system hanged after reboot.
could it be related to zram? if zram does not like reboot, then setup script should not use it (i had zram enabled in openhabian.conf)
then I installed mosquitto service, stopped it, copied over my working config and db, and it broke the service, it refused to start with no meaningful errors.
then I decided to reboot the system and it never came back (again stuck on reboot…)
i did a power cycle, still no dice.
at that point I inserted my old sdcard and call it quits.
i have no idea in what state that machine is now, might check it on another PI, dont want any more downtime in my graphs 
even though another pie is also responsible for some graphs
Just a note, that’s openHABian’s install log. Other installation approaches have different logs (and sometimes no log at all).
Any non-meaningful errors?
I’m afraid I can’t be of much help with the errors you encountered without lots more details but if it won’t even boot I’m thinking it’s going to lead to the same result anyway and you’ll want to start over and try again. So maybe it’s not worth looking into. This time though review the debug and trouble shooting section of the openHABian docs so you can gather all the information we will need to help.
well, the error with mosquitto was not very helpful
openhabian systemd[1]: Unit mosquitto.service entered failed state.
openhabian systemd[1]: mosquitto.service holdoff time over, scheduling restart.
openhabian systemd[1]: Stopping MQTT v3.1 message broker...
openhabian systemd[1]: Starting MQTT v3.1 message broker...
openhabian systemd[1]: mosquitto.service start request repeated too quickly, refusing to start.
openhabian systemd[1]: Failed to start MQTT v3.1 message broker.
openhabian systemd[1]: Unit mosquitto.service entered failed state.
but now when I think of it, it might have easy been an issue with permissions of the files I copied over, not sure if on openhabian it runs under mosquitto user but nevertheless
in the end of the day, mosquitto is not your problem,its not openhab
failure to reboot a machine that is working perfectly on the other hand, has me thinking about zram as that is the only thing suspicious.
even if I fixed that mosquitto issue, the machine died after reboot, so abort abort, mission failed.
Mosquitto also has it’s own log file. That’s where you’ll find what Mosquitto is having problems with. Systemd is just going to log overall status of the service.
yeah, it complained cannot bind to requested address.
there was no address configured, just
listener 1883
same config works on the old machine
but he only wrote it once to the logs, after the service itself got broken it failed to start it completely, not even reaching the point it writes logs
but anyway, i was lucky that this failed, as this was the first thing I did, otherwise i would have continued to zigbee2mqtt, then if that worked, started openhab, checked everything is fine, then relax, had a beer, rebooted and lost everything
surely not because of zram.
not the best choice …
have you also tried to connect a monitor to watch the boot process ?
I’m far from an expert, but I recently had struggles reinstalling the Mqtt broker. I had stopped using it some time ago (with the remoteOpenHAB) and either disabled or purged it. Anyway the conflict seemed to be 1883 was still held by the old installation. I also can’t recall how I finally got it working, but recall using sudo netstat -antp to see if the port was already in use. You could start there.
the only choice when you are blind on a headless server
but i might pop the sd card into another machine as I’m curious what happened to it and why its not booting.
might be faulty sd card, as everything else is identical to the usual raspbian that just works…
edit: oh, another thing, i did sudo systemctl disable openhab as I didnt want it to keep starting in this state of the machine. but I dont see how this could have messed the machine so bad it doesnt boot anymore…
show the error message, please. So far I haven’t seen any. Without all is just speculation.
OH can’t be the reason.
I’ve booted the sd card with openhabian to examine what is the issue, and, as I expected, it booted fine.
So I guess we will never find out what caused it to halt during reboots. that is the beauty of working on a headless system
One thing I noticed that on the login/welcome screen where it lists information, it listed the last IP that it got from dhcp (even though at the moment I booted it to check it, lan cable was not connected)
So it ignored the fact that I had configured a fixed IP (which was the last IP used to access this machine before the fatal reboot). But anyway, at that moment after reboot it was not available on any of the addresses.