scottmuc / infrastructure

Documentation / Automation for personal third-party infrastructure

The Unlicense

11 stars 2 forks source link

Rebuild WSL - Recovering from broken state #43

Closed scottmuc closed 2 years ago

scottmuc commented 2 years ago

Yay for Repaving!

As much as possible is documented inline in this issue template. In case of problems you may find help by viewing all the previous repave issues. Have fun!

Steps

[x] Delete previous WSL instance if applicable
[x] Ensure WSL2 is being used
[x] Install latest Ubuntu
[x] Clone and run coalesce script
[x] Initalize 1Password
[x] Attempt DNS Change
[x] Configure PI (tests ansible)
[x] Make this template slightly better

scottmuc commented 2 years ago

I believe I broke my WSL instance when I introduced /etc/resolv.conf configuration in https://github.com/scottmuc/infrastructure/commit/68b5b0e679844c708cdfd64a24e28d221d2a7a01.

What was previously there was a symlink to ../run/resolvconf/resolv.conf. I'm not 100% sure what's going on but I think this is related to me configuring WSL to not generate the resolv.conf.

This task is to recreate the instance and see this is a one-time issue due to the nature of how I introduced this configuration change.

scottmuc commented 2 years ago

Trying to make some commits from Windows and discovering that my configuration automation in Windows is rather lacking compared to WSL and macOS.

scottmuc commented 2 years ago

Pleasantly surprised that despite all the changes that I've made to WSL since the last repave, things generally worked immediately (terraform and ansible).

Things to improve upon:

Windows programming automation (git config, gpg keys, Powershell editing)
Repave WSL more often. It's pretty smooth now.

scottmuc commented 2 years ago

It also looks like 2 reboots are necessary for the /etc/resolv.conf to stick. I believe it's because of the following:

Upon first boot, the configuration is auto-generated. Running coalesce_this_machine temporarily fixes it, but the /etc/wsl.conf settings haven't been used.
After the first reboot, the auto-generated resolv.conf is back, and I believe that's because WSL hasn't had a chance to incorporate the overriding settings. Another coalesce_this_machine is required to permanently set the file.
After a second reboot, I can verify that the file remains as originally configured.

Something to look at is managing WSL config on the windows host, rather than the instance itself.