-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Podman Init wont Resolve DNS Windows WSL #14495
Comments
@baude @ashley-cui PTAL |
I tested version 4.0.3, both versions have same issue. |
Please check the following command: The output is something like this:
If I start the machine with But I don´t know how the make this setting permanent. |
I actualy have to do this alot and wrote a script to auto config our Dev Laptops to provision new instances of WSL Fedora35 for general dev work here is a powershell snippet for making it persists however it requires killing the WSL instance if (Test-Path \\wsl$\podman-machine-default\){
Write-Host -BackgroundColor Gray -ForegroundColor Black "Patching podman-machine-default Network"
wsl -d Fedora35 rm -f \\wsl$\podman-machine-default\etc\wsl.conf \\wsl$\podman-machine-default\etc\resolv.conf
wsl -d Fedora35 echo -e "[network]\ngenerateResolvConf = false" | tee -a \\wsl$\podman-machine-default\etc\wsl.conf
((Get-Content "\\wsl$\podman-machine-default\etc\wsl.conf") -join "`n") + "`n" | Set-Content -NoNewline "\\wsl$\podman-machine-default\etc\wsl.conf"
wsl -t podman-machine-default
wsl -d podman-machine-default unlink /etc/resolv.conf
$DNSList=Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object -ExpandPropert ServerAddresses
foreach ($DNS in $DNSList) {
wsl -d podman-machine-default echo -e "nameserver $DNS" | tee -a \\wsl$\podman-machine-default\etc\resolv.conf
}
wsl -d podman-machine-defaultecho -e "search lan example.com" | tee -a \\wsl$\podman-machine-default\etc\resolv.conf
((Get-Content "\\wsl$\podman-machine-default\etc\resolv.conf") -join "`n") + "`n" | Set-Content -NoNewline "\\wsl$\podman-machine-default\etc\resolv.conf"
}else{
Write-Host -ForegroundColor Red "Cant access \\wsl$\podman-machine-default\"
exit;
}
It checks to see if the WSL instance exists then patches the wsl.conf to stop the auto regen of the resolve.conf next adding all the nameservers from windows to the list and adds a search lan if needed But due to it killing the WSL instance the machine startup has not progressed and will not start it would be better if there was some way we could configure the resolve.conf before the init command trys to update fedora or if there was some way to make an existing WSL instance into a podman machine |
I´m not able to use your example code. |
Had the same issue with podman 4.1.0 on windows. I first ran
Then I I followed here to change the I exit
|
@b03602036 I arrived at /root/bootstrap etc. without having to do as much! |
I got suspicious with WSL and Windows Firewall (depending on your Windows build) Click on Untick vEthernet WSL Didn't make any difference though! :( Found it suggested somewhere when you search for |
By the way @Siythrun the entry |
Remark: Update: |
I just reset my dev machine, reinstalled WSL, followed by podman 4.1.1 and then ran init - Is there any approach I can use to debug the install and find this locked file? |
@n1hility PTAL |
You will find the downloaded files in |
Thanks @nobodyman1 - actually between each init I have been running |
Other related WSL Issues: microsoft/WSL#4285 microsoft/WSL#8365 We can provide a way for you to perform manual configuration actions through init, but if you need to overwrite resolv.conf there is likely a WSL networking problem at play. Are any of you who are experiencing this problem using a VPN or special firewall? A common cause for this sort of thing is that your windows defender policy is dropping packets. Could you guys check the following
What you should see is that these are consistent. The value of resolv.conf matches the gateway address which also matches the windows WSL vEthernet interface IP. This is just a rudimentary check that the file is generated correctly and still in sync with the active network. Next try
Then reboot the system completely and try the same, does it work then? Assuming there is no special firewalls or a VPN, the next thing to look at is your Windows Defender Firewall policy. A simple first test is to try completely fully disabling windows defender off (not just the interface). Go to Control Panel\System and Security\Windows Defender Firewall. Turn off for everything. If you do so does DNS start working? If so you can turn it back on and try to figure out why: After you start a wsl command, If you look at the inbound rules, using the following powershell command:
You should see something like this (when WSL is running)
The interface for the UDP rule should match the name in your ipconfig output. If instead you have a UID that does not exist, then that would be a problem. If that or anything else with the rules looks off, you could create your own DNS rules just apply them to the any interface. If everything looks correct you could still confirm its dropping the packets, you can enable logging by launching windows defender firewall -> advanced settings -> right clicking on the (Windows Defender Firewall with) icon above the Rules icons, and choose properties, then pick the public tab, then logging, enable log dropped packets, and specify a file location for the log. It rotates so depending on how much dropped traffic you have it might fly by. Then you attempt a dns query and if its logged then you confirm thats the source of the problem. If it is dropping then you can try the same solution, create a custom rule to get it working. If you exhaust the Windows Defender route then it likely is some other networking issue, a VPN client, a firewall in an AV tool, or some other network interface that might be mucking with the routing. |
Podman machine does a number of customization steps, so thats why you are receiving this error. Until we have a simpler override mechanism, what might work as a temporary hack, is you could modify the rootfs that we start from: https://github.com/fedora-cloud/docker-brew-fedora/blob/35/x86_64/fedora-35-x86_64.tar.xz If you add your custom resolv.conf and a /etc/wsl.conf to the tarball with
then you pass that the new tar.xz to
I'm not completely sure if those files will survive, but worth a try. |
thanks @n1hility |
I patched the tar.xz with wsl.conf, but then get this
So I tried intercepting the init by pasting the tar (with same name) into
Next was to create a fast node server, and serve the file that way, which gave the same failure.
about 1 hour later
|
I found an alternative way - for those urgently needing to get Podman to run.
and if you get as lucky as me ...
Now to get on with the next step ;-) This should in principle always work as the podman "disk" is a vhd and the container concept is portable - but I am not responsible if you break something! |
Here's my workaround, it requires a separate WSL instance (I used ubuntu) and you'll need to run the commands as root so the owner bits are properly saved.
And here's a scripty version of it. May contain typos. #!/bin/bash
# In powershell: cd to where TAR_IN is located, run 'wsl -d <distro> -u root --', then run this script
TAR_IN="fedora-35-x86_64.tar.xz"
TAR_OUT="fedora.tar.xz"
mkdir /fed && tar xfJ "$TAR_IN" -C /fed
pushd /fed
echo -e "nameserver 1.1.1.1\n" >./etc/resolv.conf
echo -e "[network]\ngenerateResolvConf = false\n" >./etc/wsl.conf
tar cvfJ "/$TAR_OUT" *
popd
mv "/$TAR_OUT" . |
For other people trying this: turns out that this works with |
It doesn´t work for me. If I use |
Indeed: the |
But how does it work? There is no documentation available! |
@nobodyman1 it's documented here: https://docs.podman.io/en/latest/markdown/podman-machine-init.1.html and yes, I've already used it in another context |
Thanks a lot. Now it works with |
need the echo -e "[network]\ngenerateResolvConf = false\n" >./etc/wsl.conf in the script. |
A friendly reminder that this issue had no activity for 30 days. |
podman 4.2 (just released) now fetches a prebuilt image with no package downloads. If you run into a routing or firewall issue that prevents wsl from functioning, machine init should still succeed. You can use podman machine ssh or the wsl prompt to provide custom dns settings after the init process completes. |
@n1hility Can we close this issue? |
@rhatdan Yes I think so. There is a follow-up feature request we could potentially do that allowed a user to provide a custom dns server on init vs manually editing wsl.conf and resolv.conf. This issue has gone on pretty long though, so probably makes sense to split that into another issue. |
please |
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Podman machine unable to resolve DNS
Steps to reproduce the issue:
Describe the results you received:
When trying to install packages for Fedora 35 the WSL VM is unable to resolve the repo mirrors
Describe the results you expected:
I would expect it to use the hosts DNS server settings to resolve
Additional information you deem important (e.g. issue happens only occasionally):
This might be related to an issue with WSL microsoft/WSL#3438
It is important not for me to be able to access the Internet on any WSL instance I always need to config the resolve.conf to have the appropriate DNS nameservers
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
The ability to update the resolve conf as part of the init would be appreciated or to run init wait for it to fail fix the VM manually and then continue the setup
The text was updated successfully, but these errors were encountered: