This has probably been asked for and answered somewhere but I’m probably not using the right search terms, please point me to it if so!
I’m running the latest available version of DietPi on an Odroid C2 at work to display a metrics dashboard. It boots up whenever the TV is turned on where it is connected to, set up to start the chromium kiosk to a specific URL.
On a cold boot this does not work reliably as it has to connect to wifi and sync the time, and this seems to happen after chromium is already loaded. This causes several seconds of the “no internet” page and it also messes with the login cookie/token that is used to keep track of the login state of the web page when it does load because the time has suddenly changed.
Is there any setting built in to wait for wifi and NTP time sync before continuing boot and starting applications? Or time sync alone for that matter, since the network HAS to be connected for that.
The delay may be worse since I am using DHCP, but I can’t set a static IP due to company network policy unfortunately.
there are no clocks on these sbcs - unless you put one on.
So booting the system emulates a RTC and checks NTP to set it. It’s a setting in dietpi-config.
set a static ip and turn of wait for internetconnection on boot under config - advanced network options I think. Somewhere in there as well is a config option for how to sync the RTC and when. You can tell it once a month, or once an hour etc but you have to be online when it does it clearly… so booting and checking, while your interface is down, and ignoring it and booting anyway, it will fail to update because it’s not online.
option 1. $8 gets you a pack of 5 RTC you can plug in your board and 4 spares.
option 2. boot, without waiting for network or syncing clock, set auto login script to run internet check and rtc / ntp update, and if successful, continue to chrome kiosk. If fails, load a locally stored HTML error page that says what happened with your #phone on it
option 3. turn off check sync time RTC etc at boot. turn off wait for internet at boot. keep the server up long enough for the rtc emulation to do its work before rebooting, and schedule reboots daily, accordingly so it doesn’t interfere with time sync and break your setup.
EDIT: DHCP - set a sticky ip by giving it admin your mac address (or make one up and config it so you never have to talk to it admin again if you change boards just change the mac lol). Or wins or however dhcp is done there. It’s a one line thing. not a big deal unless its a consumer router. Or set a static ip in the upper range of the dhcp server that doesn’t get used. Like if the pool is 200 addresses for 50 people and 100 devices just set your ip at 200… itll work til it doesnt and you can tell admin see this is whhy I need a static / sticky ip if you get any flak from them
I’ve looked through the dietpi-config options on my home installation before to see if there is such option but I could not find it so far.
Using a custom script on boot to wait for network and /or NTP time sync and then start the chromium kiosk .sh script is a good one, I haven’t thought of that yet.
Alternatively I may try setting the IP address it has been assigned static anyway since so far it has been the same for weeks. But having it reserved on the DHCP side is out of the question since it’s a large externally managed 10.x.x.x corporate network spanning multiple countries and they have a strict network policy unfortunately.
sounds like your dhcp server is doing some kind of name/mac resolution to assign ips - so you could test this by changing host name but not mac and see if you get same ip. If so, now change mac address and hostname both and see what iip you get. now change it back to originals and see what you get. if you get same ip you started with, but it changes when you change mac and or host name, then you know that your ip is tied to the machine name or mac, rather than random, so a static ip with that “'sticky dhcp” address will not cause any trouble until the admin makes a DHCP-pool-wide config change.
not optimal, will work for now, for testing… but once you test it is working i’d contact the it admins just to inform them you have this machine set up this way to do this thing only and here’s how they can connect and check themselves if thhey want to… and see what their feedback is.
Sounds like they wont want twhatever you’re doing because they are not in control of it. my assumption as former global it admin for nokia. No one wants user servers randomly placed on their network. it’s a security risk “potentially”. Assumed so anyway.
I always found and blocked such servers as part of my job for this very reason. I can’t be responsible for your whatever thing working howeveer it works wherever on my secure network without some kind of “image” that is corporate approved and locked down to start with.
So I wish you the best - i’m sure you trying to benefit everyone there - but dont be shocked when they are not happy about your “help”
ONE LAST THING:
if it’s possible : tether it off some workstation’s working internet connection and you’re in a private network, only one service open / port open, and it has to go through that workstation… so none of the IT staff should be wiser and you wont be opening up holes in the network
Thanks again for more possible solutions.
I found that setting the DHCP assigned address as static did the job already, the connection and time sync have completed before chromium loads the page.
For good measure I also implemented starting the chromium script with a custom service using a unit file like @Jappe and @th2j mentioned instead of using the built-in dietpi autoboot feature for chromium.
I had to tweak the script some more as it didn’t start and gave errors in the systemctl log when I tried it, but this works now:
@bjmurrey Recently there was a security breach and since then they have become paranoid about everything. The wifi network I am using is a secured internal network with different range (192.168.x.x) and isolated from the main 10.x.x.x network where the workstations are on. I can’t tell why DHCP is taking so long to complete, but as long as this works I’m fine with it. If it causes issues in the future then I’ll try just using DHCP again since the script should handle that now.
