Initial startup couldn't do its "magic", now what?

Setup, Configuration and Use Beginners
1

On Pine64: I need to know what was supposed to happen at startup bsides just “magic”.

Here is my environment:
I am borrowing a Pine64 from a library, sitting in their library. They provide no wired connection to their network, only wireless. Authentication onto their wireless is via a web page that requires a membership number entered via keypad and mouse click or enter key. So I assumed the OpenHABian image would not be able to navigate a wireless connection, and I made a cable to connect the Pine64 to my laptop eth0, which I have served with dhcpd to give an address to a dhcp client. I authenticate onto the library network with my laptop browser. This setup works perfectly fine for other images, namely longsleep’s.

The plan is that I will allow OpenHABian to configure itself on the u-SD card, return the library’s Pine64 to the check-in desk, and when I get a chance to travel the hour drive to where my Pine64 board is being a thermostat during this winter cold snap, try the configured OpenHABian in my own board.

This page indicates that step one was to get an image and write it to u-SD card. I made sure the u-SD card was genuine (three I bought were not, two were). I chose the larger image named openhabianpine64-2017021801-git088eb4e.img.xz. I booted the Pine64 with it without being able to have a clue as to what environment the image was expecting. There begins my frustrations.

The dhcp address was not delivered as the image needed. I had to change it to a static IP address (my laptop is acting as router for the board while I am located in a tech library that has some goofy connection protocol via a http page, etc. and I couldn’t get the board to take dhcp from my laptop even though the same board does with other images) Also, during startup of the Pine64 with the aforementioned image, I noticed several minutes of pause before the login prompt. Was the “magic” being done during that pause? I had no way of knowing based on the sparse documentation. Another frustration.

Now there is no “openhabian-config” as near as I can find. Who knows what else might be missing.

There is no http daemon running. There is sshd running.

My question is, how do I get openhabian-config now, along with everything that might be missing, and what exactly IS missing? Evidently all daemons are launched via systemd, right? I don’t see and systemd service files in /etc/systemd/system for an http server. Where should I find them? I need more details than “magic”, please! Thank you for letting me vent.

2

Hello Ken,
the openHABian “magic” is a simple installation script, which will install all promoted components on first boot, provided the pine is connected to the internet. My suspicion would be, that this was not the case, hence the missing components. Please check the content of /var/log/first-boot.log to get a feeling at which step the setup failed. I just realized that this file path is different than for the RPi, I’ll make sure to document this.

Here are two options: Either you try again and hopefully everything will go as planned this time. If you want more control, you can go the “manual” way. Install the normal longsleep image, then follow the steps described here. This way you will have full control and get clear feedback.

3

Thank you. I think you should not allow that installation script to run merely based on first boot. It should instead be more closely based on first full-fledged internet connection, not even first local network connection

Here is the entirety of that file:

2016-02-11_16:33:04_UTC [openHABian] Booting for the first time!
2016-02-11_16:33:04_UTC [openHABian] Ensuring network connectivity…
2016-02-11_16:34:45_UTC [openHABian] Network unreachable, can’t continue. Please reboot and let me try again.

This, even though I had rebooted with a static IP address configured

4

I am not…

image.png1035×221 6.81 KB

The script is trying to ping a google server for around 5 minutes before giving up. At this point the script should be executed once more on the next reboot. It should have worked…

5

Thank you for further details. What I’ll do is tweak on the image before I ever boot into it the first time. I’ll make the /etc/network/interface.d/eth0 file and interfaces file have the right info (static address) before first boot.

BTW, the first boot, maybe twice, had a long pause (5 mins?) prior to the login prompt. I simply didn’t have enough info to know what to expect on the screen and in what sequence. I thought maybe a script was executing or maybe just a startup process retry.

Thank you.

6

I’ll add a warning when a user logs in quickly after first boot and the setup routine is still running. That shouldn’t happen too often as the setup only takes around 10-15 minutes.

The way openHABian works right now is a bit different to how you’d normally expect it. When we started with openHABian, it was designed for a special unattended network installation for the Raspberry Pi. What we do now is take the existing base image for one platform (e.g longsleep’s image) and modify it so it executed the openHABian setup on first boot. I’ve questioned myself if it would be the better option to provide images, in which this setup process already is finished and you can boot directly into the working system. The downside to that is, that we’ll need to update the image more often. The current method is a bit special but it worked out quite good so far…

7

I was thinking of the online documentation letting the user know in more detail what to expect on the screen as the initial startup progresses, rather than their expectations be solely based on what the executing script informs them. That way we’ll know if something has gone awry even before the script has had a chance to launch. Right now, we have no idea where in the startup sequence the script should have started.

8

Got 'er going. Thank you very much!!!

1 Like
9

I would ask you to prefer some other alternative to making images that include the /boot because they can’t accommodate us changing our /boot/uEnv.txt file to run our rootfs on usb drive, which we do like this:

root=/dev/sda1
bootdelay=20

in /boot/uEnv.txt. Where /dev/sda1 contains the rootfs. Specified here

Other means also exist to off-load boots to usb drive which involve even more extensive image differences to what you’d be able to accommodate by focusing on making entirely new images to apply your mods.

ON SECOND THOUGHT: A person could just write your image to the usb drive and be fine if they continue to boot from previous /boot on u-SD that specifies the rootfs to be a new one, your image, just written to the usb drive.