mirror of
https://github.com/sickcodes/Docker-OSX.git
synced 2026-01-11 21:10:25 +01:00
Can't contact recovery server from Docker-OSX during installation in a proxied environment #295
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @OverthrowTheGoauld on GitHub (Jan 1, 2022).
Hello:
Before I post the problem, here are the outputs you have required.
Now, the output of installation (I deleted all images and started with a clean slate):
When this boots up, I get an initial 5 second delay (some wake-failure), and then the boot resumes.
As per your instructions, I ran Disk Utility, and converted the 278+GB QEMU harddisk space (where does this number come from? - I do not have a 278 GB free partition, or even 278 GB free space in /var/lib) to APFS/GUID with the name Mac OSX HD. I leave the other 400MB QEMU partition and the mac OS base system alone.
Next, I click on "Reinstall mac OS Big Sur". The machine waits a while before presenting me with the mac OS Big Sur (To set up the installation of mac OS Big Sur, click Continue) screen.
After I click Continue, I get "The recovery server could not be contacted." after a short while.
Then I open up Terminal from the top menu.
Examining the network leads to:
(can't copy paste)
(I assume that 10.0.2.15 is the IP address provided by the fake DHCP server in the arch-based docker container inside which you are running OSX.)
The network on the host (while the container is running) is:
I next tried a fix suggested in (https://gist.github.com/levlaz/16b63384bd5e1bee3593be0d91aedbd7):
After quitting Terminal, I retry the above reinstall ... steps. Same result.
The above strongly suggests that my problem is not the time offset, but an actual inability to contact non-proxied addresses. This sounds like a proxy problem (see below).
To check whether it was the authentication in the proxy playing a role, I supplied URLs: http://username:password@10.10.78.61:3128 in the --env options above (is the .json file (see below) overriding what I supply on command line?).
(The password contains an underscore, just in case that matters.)
The same happens again.
When I add --dns 10.10.1.2 (taken from /etc/resolv.conf on the host), the same happens again. This is not a DNS issue as supplying the IP address of a public time server outside of the proxied environment (time-a-g.nist.gov: 129.6.15.28) results in the same problem as the Exchange problem above.
So, this is not a DNS issue.
Finally, I added the username and password to the config.json (see below) file and tried this process again. No joy.
I have tried to Reset NVRAM on the boot screen as well, since that often impacts things with OSX. No effect.
So, whatever network service (since that is what I suspect) is directly related to the fact that mac OS recover server needs to communicate over a non-proxiable port (such as whois, etc.). Can't I download the BaseImage.dmg file from somewhere? I have downloaded the InstallAssistant.pkg file for Big Sur (and tried to follow the instructions at https://davejansen.com/install-macos-11-big-sur-in-a-vm-qemu-kvm/), but that cannot work since the xar utility needed to extract this is not available at the link therein.
However, puzzlingly, Docker is able to connect (? - the 301 error does not look promising) to net for the nginx container (so the problem above is probably not directly related to the fact I have a proxied setup - see details below):
I have setup proxy the best I can:
Some of the environment variables:
Contents of config.json (under the user jon):
So, I am forced to conclude that the network issue (if it is a network issue) is unique to the Docker-OSX container. Despite the ability to download images over proxy, I have a nagging suspicion that this is due to the nature of the proxy I have to work with.
One possible lacuna in my setup:
I have already invested a non-trivial amount of time in this, and believe that the likelihood of me finding a solution to the issue above on my own is low enough for me at this time to request your assistance.
If you need further information, please ask.
@sickcodes commented on GitHub (Jan 13, 2022):
Xar is available: https://github.com/sickcodes/aur/tree/master/xar
Fork: https://github.com/tpoechtrager/xar
@OverthrowTheGoauld commented on GitHub (Jan 14, 2022):
Thanks.
This is not available on Debian. Is there any source code available?
On Thu, Jan 13, 2022 at 2:36 PM sickcodes @.***> wrote:
@sickcodes commented on GitHub (Jan 15, 2022):
Here you go: https://github.com/sickcodes/aur/raw/master/xar/xar_1.6.1-5_amd64.deb
@OverthrowTheGoauld commented on GitHub (Apr 5, 2022):
Sorry, have been traveling for a few weeks. Lost track of this.
Can you suggest why networking does not appear to work at all?
@rodrigofbm commented on GitHub (Aug 2, 2022):
I'm facing the "The recovery server could not be contacted." message too on Fedora 36