Folks, I have a Turris Omnia and now a Mox too, and after applying today’s security updates to the Omnia, I saw the Turris MOX network boot package and installed it. I then tried setting up the Mox.
The mox does not have an SD card, so I plugged it straight into the Omnia via ethernet, per the netboot docs. I do have the “managed devices” side-bar in Foris, and I have content there, but the Mox never appears.
I have a USB stick in the Omnia so do have a /srv/ and I realized that the problem might be that I use a different (pre-existing) ISC dhcpd install on my network for DHCP, with the Omnia’s set to disabled for br-lan. So I added DHCP items for the mox MAC, filename "turris-netboot/mox"; and next-server pointing to the Omnia.
The mox appears on the network on the correct IP, so DHCP itself is working, but I see nothing appear in the Foris menus.
I’ve spent a while trying to pick through the dnsmasq/etc setup on the Omnia and can’t figure out what’s supposed to be happening, so can’t figure out what configuration I need to provide to get the pairing up and working.
Anyone have any pointers to help me out here please?
Apart from DHCP (you don’t need any extra options apart from giving it IP and maybe IP of the server) you also have to have tftp server enabled and running on top of /srv/tftp
MOX reads what to boot pxelinux.cfg/default-arm-mvebu-turris_mox where is also full cmdline that is needed and after pairing, it fetches specific signed image from turris-netboot directory.
I had the same problem - default-arm-mvebu-turris_mox was empty and similar situation, custom configuration for TFTP and /srv is symlink to SSD.
I read this script https://gitlab.labs.nic.cz/turris/turris-netboot/blob/master/manage.sh (regen part).
I tried run netboot-manager regen, but without success.
The script check key ~/.ssh/reg_key.pub and if it does not exist, tries to create it. In my case, key wasn’t created (I don’t known why, but time is expensive for experiments). I created the key manually by ssh-keygen -t ed25519 -f ~/.ssh/reg_key -N "" -C "registration_key. After, I tried to re-run netboot-manager regen, but default-arm-mvebu-turris_mox was stay empty. I removed it and re-runed netboot-manager regen. Change! Script “said”: can’t create /srv/tftp/pxelinux.cfg/default-arm-mvebu-turris_mox: Permission denied.
Steps for help (for my case):
check permission on /srv/tftp/pxelinux.cfg/ - I set 777
remove default-arm-mvebu-turris_mox
run netboot-manager regen
check size of default-arm-mvebu-turris_mox
4.1 if is empty, try to generate registration key and go back to step 2
4.2 if is empty, I don’t known why
turn on your MOX and wait for some seconds
run netboot-manager list-incoming
5.1 if you see serial number, you’r win
5.2. run netboot-manager accept <serial>
Question for miska:
Before MOX I use TFTP for booting “rescue OS” with “incompatible” configuration
What’s right access/owner for /srv/tftp/pxelinux.cfg and /srv/tftp/turris-netboot?
Thank you. Without your contribution, I wouldn’t have solved the netboot. I had also set TFTP for booting (old article in the Turris documentation). FYI simply shutting down, deleting the settings does not solve nothing (NFS)?
Although the information with permissions may have fallen.
I think that at least someone from Turris team could write note in the official documentation that this article is outdated. After all, someone probably bought Omnia plus Mox as an AP.
Edit: Don’t misunderstand me. It is not meant as a criticism of Turris team. But I think it’s better to write two sentences here and there. And save some time on support for individual users, but that’s another topic.
I have a Turris Omnia without wifi. I also have a Turris MOX which is - hopefully correctly - paired with Turris Omnia. I would like to use the MOX as wifi-AP, thus I tried to adjust the content of /etc/config/netboot according to the documentation. However, the wifi is not working correctly.
Thanks for your quick reply. Currently, I have a running solution with an AP based on MerlinWRT (RT-AC87U). However, it would be nice to switch to a solution based on Turris solely. The pairing works for LAN connections (I have a MOX-C module besides the MOX-A module with wifi). All in all I guess I should wait for the stable relaease of 3.11.6.
Having received my MOX last week I finally managed to get Netboot working.
The DHCP needed to be on the TO not my Pihole (next job is to redirect from pihole the PXE).
After switching dhcp back to the TO I then got the permission error which was resolved by 777 on the config file.
Seems to be a lot of grief to get something that should be working out of the box, but it seems to be there now.
I’ve not got any further than the exclamation mark next to the registered MOX and spinning waiting wheels next to the devices and channels on the wifi setup page, any pointers would be appreciated…
OK - netboot works when the DHCP is on the TO, but when the DHCP is on my pi-hole (running on a LXC on the TO) with
dhcp-option=66,“192.168.1.1”
dhcp-boot=pxelinux.0,1.192.168.1
I can now see the device come in as Incoming, I can accept it and then it transfers the image and boots up to a heartbeat led on the MOX but the state in the managed devices screen shows an exclamation mark “!” - nothing in the documentation on this. Plus the device seems inaccessible on any of the DHCP IP addresses I see assigned to it in the syslog on the TO controlling router.
My current assumption is that I need to generate a token on the remote device and upload to remove the “!” but if I can not get the IP address then this is hard to achieve!
It appears clear that netboot provides a ‘dumb’ device which extends your WiFi using the ethernet cable and SSID names on your controlling router and no web based presence. So my MOX is now netbooting and also extending the wifi from the TO router.