The probably most convenient autoinstall option when you have the need to iterate quickly on testing full image builds for toradex devices is to use tezi autoinstall feature through a locally hosted webserver.
However, achieving this is not straight forward unfortunately, and the official Toradex documentation points out hints at how to hack/do this:
The Toradex Easy Installer always tries to load an image_list.json from the hard-coded URL http://tezi.toradex.com/image_list.json. Using a custom DNS server one can redirect tezi.toradex.com to a local development PC.
Share your Network via LAN to the board
Of course, in order for you being able to zero touch install the local image you built to your Toradex board is to have your host setup as a ethernet gateway.
For this, I recommend to share your LAN via NetworkManager.
There are few tutorials out there on how to do this, e.g. see https://help.ubuntu.com/community/Internet/ConnectionSharing or use google.
It is important to note down the IP that your host will have when acting as the gateway for your board.
By default the network manager sharing IP is 10.42.0.1 by default for NetworkManager, but can be changed (if you want check google).
Configure your host for DNS hijacking
On Ubuntu simply starting a custom dnsmasq server on your host as outlined in the official Toradex docs linked above is not enough.
When digging deeper as of why one cannot start a dnsmasq like described on Toradex website it turns out that in recent Ubuntu releases systemd-resolved will take precedence on serving port 53 (for DNS) on your host network.
To work around, I use the following trick:
First, I run the dnsmasq that I want to use to hijack the tezi.toradex.com DNS entry with inside a docker container.
docker run -d --name dnsmasq \
asac/dnsmasq-alpine \
--address=/tezi.toradex.com/10.42.0.1 \
-k \
--log-facility=-
Note: Replace 10.42.0.1 with the IP you use as gateway for the shared LAN connection if you changed the default in NetworkManager.
Next, I have to configure systemd-resolved so that it uses our docker container as its primary DNS upstream source.
For that we have to find the IP address of our dnsmasq container:
$ docker inspect dnsmasq | \
jq -r ".[].NetworkSettings.Networks.bridge.IPAddress"
172.17.0.2
And adjust the systemd-resolved config /etc/systemd/resolved.conf:
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details
[Resolve]
DNS=172.17.0.2
#FallbackDNS=
Domains=~.
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes
Remember that you need to adjust both the DNS as well as the Domains entry in the file above for it to work!
When done with editing the config files we restart systemd-resolved:
sudo systemctl restart systemd-resolved
And we are done.
Next time you boot into an TEZI installer that is connected to your host via LAN cable, it will use the image_list.json that is hosted at the top level directory of your hosts webserver (e.g. nginx).
Assuming the images_list.json refers to a valid tezi image that has autoinstall: flag enabled, you will be able to monitor install progress from within the TEZI system by tailing /var/volatile/tezi.log.
Enjoy!
Top comments (8)
A bit less well known feature of Tezi 2.0 is its zeroconf capabilities: You can announce a HTTP Server which serves Tezi images via Zeroconf e.g. using AVAHI, see developer.toradex.com/software/tor....
Hi Stephan, I tried moving to 2.0b5, using zeroconf to auto install. I see the following error if I announuce an autoinstall image through avahi:
USB Gadget: RNDIS enabled
"AVAHI_CLIENT_S_REGISTERING"
Using the 'xdg-shell' shell integration
Scanning media initially...
Network up in 0.109 seconds
Tezi Server lookup successfully
Downloading image list from "tezi.toradex.com/image_list.json"
Downloading image list from "tezi.toradex.com/image_list_3rdpar..."
"AVAHI_CLIENT_S_RUNNING"
"AVAHI_BROWSER_CACHE_EXHAUSTED"
"New service 'Custom Toradex Easy Installer Feed' of type _tezi._tcp in domain local on protocol IPv4."
Adding zeroconf feed "Custom Toradex Easy Installer Feed"
Downloading image list from "alap19.local:80/~asac/tezi/image_l..."
"AVAHI_BROWSER_ALL_FOR_NOW"
Emit abort...
Emit abort...
Emit abort...
Emit abort...
Emit abort...
Emit abort...
Emit abort...
Emit abort...
Emit abort...
... interestingly enough if i start tezi without -autoinstall and use vnc to install my image it works... hmmm
Hm, that is wired. The "Emit abort..." is a message which is caused by aborting all image list downloads, which is triggered when an image installation starts. So it seems that Tezi actually starts to autoinstall an image, which triggers the abort of all other image (list) downloads. I wonder why that autoinstall does not make progress. So Tezi is at this point stuck in the main window?
Yeah see the screenshot. thats how tezi looks like when its in that state...
dev-to-uploads.s3.amazonaws.com/i/...
If feels like a race... sometimes if i start manually after it failed with tezi -autoinstall it seems to work (though very rare at this point i cannot get it to work). But if i start without -autoinstall i can select the image and install it and it works.
Full log is this:
Here the tezi UI when i start it without -autoinstall...
dev-to-uploads.s3.amazonaws.com/i/...
Indeed. I actually found out about it, but I couldn't connect to it with available rdp clients on ubuntu 18.04...
The latest 2.0bx releases use VNC again. We switched a bit back and forth there, sorry about that :-)
sweeeet ... i will start playing with it soonish then I guess :P