I expect this is a subiquity bug more than a Tart problem so have raised it here with full details:
https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/2022856
but raising this here in case anybody has seen similar issues.
Also, I wanted to try a workaround of running a simple local webserver to serve the user-data and pointing the Ubuntu installer to use the use-data over the network instead of from a local cdrom iso, to see if I can isolate the difference from my working x86_64 build if this is an installer code path issue or an ARM code path or even a Tart related issue.
However, the installer hits the exact same error.
I had used tty2 to determine the IP and gateway, ran a python3 -m http.server on the Mac and did a curl http://192.168.64.1:8000/user-data to check that it worked.
You can reproduce using the network autoinstall user data via this command:
which will start the python web server and then run the alternate http autoinstall configuration to show this.
I expect this is a subiquity bug more than a Tart problem so have raised it here with full details:
https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/2022856
but raising this here in case anybody has seen similar issues.
Also, I wanted to try a workaround of running a simple local webserver to serve the user-data and pointing the Ubuntu installer to use the use-data over the network instead of from a local cdrom iso, to see if I can isolate the difference from my working x86_64 build if this is an installer code path issue or an ARM code path or even a Tart related issue.
However, the installer hits the exact same error.
I had used tty2 to determine the IP and gateway, ran a
python3 -m http.serveron the Mac and did acurl http://192.168.64.1:8000/user-datato check that it worked.You can reproduce using the network autoinstall user data via this command:
which will start the python web server and then run the alternate http autoinstall configuration to show this.