Update: This answer was my first attempt at the solution (which does work), and the "safe" way of doing it. However, the "quick and easy" (but less "safe") registry edit that I posted as a second answer appears to be working for multiple users as well. This answer contains the background on the problem and why both of these techniques work for correcting it.
From reading through several Github issues (including, from the looks of it, one that you posted there), this appears to be a problem with the recent Store update of the Ubuntu app. The ubuntu.exe or ubuntu2004.exe (edit: I now believe this only happens with ubuntu2004.exe, but please let me know if you experience this on the ubuntu.exe version) is broken after update.
The ubuntu.exe command really does two things -- It first checks to see if Ubuntu is installed in WSL. If not, it extracts the Ubuntu rootfs and asks you to configure a username and password. If it's already installed, it launches WSL using that distribution.
The problem seems to have actually started in the previous version of the "Ubuntu 20.04" app in the Microsoft Store. The name of the distribution that is installed should be (historically), Ubuntu-20.04. The previous version appears to have had a bug where this was renamed Ubuntu2004.LTS (thanks @Pat for pointing this out in the comments).
This would have caused a similar problem for all users that updated. However, it seems Canonical quickly pushed a fix for the issue.
Unfortunately, if you installed during that window where the "bad version" was in the Store, then the fix breaks things for you, because now:
ubuntu2004.exe is looking for a distribution named Ubuntu-20.04.- It doesn't find it (because your version is incorrectly named
Ubuntu20.04LTS), so it attempts to run the rootfs/configuration stage again. But the WSL files are already extracted and configured, leading to the error.
There are several options:
Personally, I'd just change any link to use the wsl.exe command instead of ubuntu.exe (or ubuntu2004.exe). Assuming that Ubuntu is your default WSL distribution (found via wsl -l -v), then will have the same effect and just launch it. - Edit -- It's worthwhile to actually fix this.
From the Github reports, you can truly fix the issue by unregistering the Ubuntu distribution. Note that this is a destructive operation that will remove your existing Ubuntu distribution.
Assuming that the distribution still runs, via the wsl command, it is possible to back it up before unregistering, then restore it afterwards.
I would do this in two steps:
First, create a backup of the distribution via the wsl --export command. Exit the distribution, then go to PowerShell and:
wsl -l -v
# Change "Ubuntu-20.04" in the next line to match the distribution name in use
wsl --export Ubuntu-20.04 ubuntu_backup.tar
Second, find the virtual drive for your Ubuntu WSL distribution. Start in File Explorer with:
%userprofile%\AppData\Local\Packages
Then find the CanonicalGroupLimited...Ubuntu (the name may vary.
Inside that, find ..\LocalState\ext4.vhdx. Copy that file to a safe location.
With two different backups in place, it's time to unregister Ubuntu from WSL. Remember that this is a destructive operation:
wsl -l -v
# Change "Ubuntu-20.04" in the next line to match the distribution name in use
wsl --unregister Ubuntu-20.04
Rerun the ubuntu2004.exe or ubuntu.exe (either from the command-line or the Start menu)
Ubuntu will again run its installation and initial configuration (and it should now work with the "bad" version unregistered). While you can enter a username and password here, we're just going to throw this "installation" away anyway.
Exit the Ubuntu distribution
From PowerShell:
wsl --terminate Ubuntu-20.04 # or Ubuntu
Copy the ext4.vhdx that you saved above back into %userprofile%\AppData\Local\CanonicalGroup...Ubuntu...\LocalState over the newly created one.
At that point, the ubuntu.exe or ubuntu2004.exe command should work once again (as well as from the Start menu).
