Do you happen to recall at what point it failed?

I did the update to buster myself a while back, followed by a usrmerge, and it completed successfully. That said, my update was on 18922, so this may be a fixed-in-later-version issue.

Do you happen to recall at what point it failed?

I recall vividly. The first point of failure is the attempt to move pam modules directory. On the first of the two failed systems, I made the brilliant move of rsyncing them into place and breaking sudo in the process, because it obviously didn't know where to look for them without the not-yet-present symlink.

Has anybody successfully upgraded to buster on windows 18362 (or before) ??

Has anybody successfully upgraded to buster on windows 18362 (or before) ??

The upgrade completes fine. It's the usrmerge command that resulted in problems for me. I haven't tried again since applying the July update.

I was able to reproduce this. By accident, unfortunately. Running usrmerge left me with a broken Debian install in WSL that required a reinstall to recover from.

I tried it again on a fresh install from the Microsoft Store, which gave me Debian 10.9, and it failed the same way. I'm using WSL 1. Not sure if the permission issue is any different under WSL 2.

I'm hoping this is resolved by default when the Debian distro in the store is updated to Debian 11 and I can do a fresh install with merged-usr already applied by default.

Setting up usrmerge (21) ...
mv: cannot move '/lib/x86_64-linux-gnu/security' to '/usr/lib/x86_64-linux-gnu/security': Permission denied

FATAL ERROR:
mv --no-clobber /lib/x86_64-linux-gnu/security /usr/lib/x86_64-linux-gnu/security: rc=1

You can try correcting the errors reported and running again
/usr/lib/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)

Followup: usrmerge does work without error when running Debian as WSL 2.

And migrating back to WSL 1 after running usrmerge while in WSL 2 does work as well.

So anyone needing to use WSL 1 and wanting to do a usrmerge, your workaround is to just switch your Debian to WSL 2 first, run usrmerge, and then switch back to WSL 1.

Followup: usrmerge does work without error when running Debian as WSL 2.

And migrating back to WSL 1 after running usrmerge while in WSL 2 does work as well.

So anyone needing to use WSL 1 and wanting to do a usrmerge, your workaround is to just switch your Debian to WSL 2 first, run usrmerge, and then switch back to WSL 1.

Does Anyone try this way?

Same problem here, when upgrading my WSL 1.0 from Ubuntu 20.04 to 21.10 the usrmerge+WSL1 broke my installation :( ...

Any guidelines on how to upgrade to WSL2 to run /usr/lib/usrmerge/convert-usrmerge and then convert back to WSL 1 ?

Apparently as simple as:

wsl --set-version Ubuntu 2

I'm not sure it actually changed, since wsl -l -v still listed my "Ubuntu" installation as version 1 ... but after I did this running /usr/lib/usrmerge/convert-usrmerge worked (I wonder if all it needed was a reboot).

In any case I moved it back (??) by doing:

wsl --set-version Ubuntu 1

And then I bumped into issue #4640, which is then solved by removing a sudo rm -f /etc/apt/apt.conf.d/20snapd.conf. Notice snapd package had already been removed because it also breaks the upgrade from 20.04 to 21.10 for some obscure reason.

For those who may come later:

Got the same error trying to update my Debian WSL1 install

Preparing to unpack .../archives/usrmerge_31_all.deb ...
Unpacking usrmerge (31) ...
Setting up usrmerge (31) ...
mv: cannot move '/lib/x86_64-linux-gnu/security' to '/usr/lib/x86_64-linux-gnu/security': Permission denied

FATAL ERROR:
mv --no-clobber /lib/x86_64-linux-gnu/security /usr/lib/x86_64-linux-gnu/security: rc=1

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)

Converting the WSL1 install to WSL2 made it so that convert-usrmerge could succeed.

PS C:\Users\Max> wsl --set-version sid1 2
Conversion in progress, this may take a few minutes...
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
Conversion complete.

Tried running convert-usrmerge (needs sudo) but it works!

max@MAX-630i:sid1:/mnt/c/Users/Max$ sudo /usr/lib/usrmerge/convert-usrmerge
sudo /usr/lib/usrmerge/convert-usrmerge
The system has been successfully converted.

Converted back to WSL1 and the rest of my updates are running fine!

Here is a fun hack that worked for WSL1:
The key is 9P FS works even when WSL is shut down.
Lets suppose you already started. If not, the first step is to fail:

sudo /usr/lib/usrmerge/convert-usrmerge

I ran into the above issue. However I did the following:
from a root terminal

• if you already borked your system you can get via wsl.exe -u root in a cmd
• if your PAM isnt dead one of:
  • sudo su with your PW
  • su - with root PW
• you cannot break these up individually with sudo. sudo and su break after the first command... if you didnt read that first, see the first bullet of this list.

mv /lib/x86_64-linux-gnu/security /usr/lib/x86_64-linux-gnu/security
ln -s /usr/lib/x86_64-linux-gnu/security /lib/x86_64-linux-gnu/security
/usr/lib/usrmerge/convert-usrmerge
#fails because ha ha /lib cannot be moved!!
chmod o+w /
ln -s /usr/lib /libtmp
exit

now in a cmd do wsl --shutdown.
In your favorite way from windows:

• delete \\wsl$\Debian\lib
• move \\wsl$\Debian\libtmp to \\wsl$\Debian\lib
  (I used explorer... I use WSL for a reason, could care less about windows file manipulation command line)
• start up your wsl again and run

chmod o-w /
/usr/lib/usrmerge/convert-usrmerge

then read and weep:

The system has been successfully converted.

edit: Fix delete instruction I mistyped, and add instruction from the top in case anybody tries from the top, and its \\wsl$, not \\$wsl

Here is a fun hack that worked for WSL1: I ran into the above issue.

Thanks for these tips @boxfire! This saved my install. I use WSL2, so the other tips about switching to WSL2 didn't apply to me, but yours worked fine. Just one tweak:

* delete `\\$wsl\Debian\tmp`

This should say to delete lib, not tmp.

Thanks, and fixed. Yeah this saved me big time too, and I refused "convert to WSL2" as any reasonable solution, period.

You can pry my wicked win32 hacks inside WSL1 programs from my cold dead hands...
WSL1 forever!! or rather at least until back to native linux if it sunsets.

For anyone googling this, this is the actual solution: https://askubuntu.com/a/1486648/1733922

In window explorer, just copy \\wsl$\Debian\lib\x86_64-linux-gnu\security to \\wsl$\Debian\usr\lib\x86_64-linux-gnu\security, then in wsl termianl sudo apt update && sudo apt upgrade -y, finally it comes

The system has been successfully converted.

this didn't work for me, but I moved C:\Debian\rootfs\usr\lib\x86_64-linux-gnu\security to C:\Debian\rootfs\usr\lib\x86_64-linux-gnu\security_1 and ran apt upgarde which generated the same result. It ended up just creating a new security folder in the end, so it looks good to me
We don't have WSL2 on WinServ 2019, so everyone's pointers here has been greatly appreciated

I also ran into this issue while updating my Debian WSL1 from 11 to 12 (on Windows 10). After migrating to WSL2 temporarily, usrmerge would succeed and I changed to WSL1 again.

The root cause is: WSL1 currently doesn't support moving (renameing) directory while some file in that directory is being used. For example, if /somedir/somefile is being used, then mv /somedir /somedir2 will result in Permission denied.

The sudo program uses dynamic libraries in /lib/x86_64-linux-gnu/security/. So if you are using sudo to execute commands, you will never be able to move that directory. Thus the workaround is: do not use sudo in linux shell, use wsl -u root in windows command prompt instead.

Here are the steps to workaround this specific problem under WSL1:

1. Run wsl --shutdown to fully close all linux processes.
2. Run wsl -u root to get root access and do fixes in linux shell, you might need to run /usr/lib/usrmerge/convert-usrmerge multiple times.

I was getting the following error when upgrading to bookworm while currently on WSL 2:

Setting up usrmerge (35) ...

FATAL ERROR:

/lib/modules/ is a mount point.
Probably this system is using User Mode Linux.

To continue the conversion please:
- replace '/lib/modules/' with '/usr/lib/modules/' in /etc/fstab
- reboot
- try again

E: usrmerge failed.
dpkg: error processing package usrmerge (--configure):
 installed usrmerge package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 usrmerge
E: Sub-process /usr/bin/dpkg returned an error code (1)

The problem here is WSL mounts the modules directory into /lib when starting up debian.

The way I fixed it was downgrading to WSL 1, following @boxfire workaround above (#4279 (comment)), then upgrading back to WSL 2.

wsl --set-version Debian 1

// @boxfire workaround

wsl --set-version Debian 2

There's probably a more sane way to do this where the modules directory can be configured to mount somewhere else.

I ran into the same problem as @tezhm. The problem I have is that I can't switch to WSL1. The following error occurs:

wsl --set-version Debian_WSL2 1
Conversion is in progress. This process can take several minutes.
Error: 0xd000000d
Error code: Wsl/Service/0xd000000d

Any ideas?

@pickard1 sorry I am unsure, luckily downgrading to WSL 1 worked for me. The problem is that /lib has a mounted directory modules which I'm pretty sure WSL 2 is creating since it doesn't create in WSL 1. If somehow you could configure WSL 2 to not do that then I'm guessing the usrmerge conversion should work without needing to downgrade to WSL 1.

@tezhm. The question is whether this can be solved configurationally. Of course, this doesn't work on the live system because the resource is always busy. So a umount, for example, won't work like that.
You can't find much information online about what Microsoft is doing... i will try ....

I did it. :-)
After I set the mountFsTab=false option in [automount] in wsl.conf, I was able to remove the mountpoints for /lib/modules. Then the upgrade went through!!

I did it. :-) After I set the mountFsTab=false option in [automount] in wsl.conf, I was able to remove the mountpoints for /lib/modules. Then the upgrade went through!!

Thank you @pickard1 ! This worked for me.

Here are the exact steps I performed.

I edited my .wslconfig and added:

[automount]
mountFsTab=false

Then I performed a wsl.exe --shutdown and wsl.exe -u root. Then I ran mount | grep '\/usr\/lib\/' to get a list of the mounts in use (there were 4). I then began running umount /usr/lib/... for each of these. Some of them are dependent on each other so it might fail to unmount until you unmount one of the others. Once you get them all unmounted, then run /usr/lib/usrmerge/convert-usrmerge.

If that completed successfully, then remove the entry you added in the .wslconfig and do another wsl.exe --shutdown.

Apparently as simple as:

wsl --set-version Ubuntu 2

I'm not sure it actually changed, since wsl -l -v still listed my "Ubuntu" installation as version 1 ... but after I did this running /usr/lib/usrmerge/convert-usrmerge worked (I wonder if all it needed was a reboot).

Had the same issue with Debian, while upgrading from buster to bookworm.

One thing to mention is the wsl command effectively terminated the running session (I didn't knew if it needed to be closed during the wsl --set-version Debian 2

I didn't try switching back to WSL 1 as I find no reason at this point. I switched back to WSL1 because the DNS integration didn't work anymore for me (my employer uses zscaler and had to import the CA root certificate as suggested in this post: https://stackoverflow.com/questions/72167566/wsl-docker-curl-60-ssl-certificate-problem-unable-to-get-local-issuer-certi/73497278#73497278).

In any case I moved it back (??) by doing:

wsl --set-version Ubuntu 1

And then I bumped into issue #4640, which is then solved by removing a sudo rm -f /etc/apt/apt.conf.d/20snapd.conf. Notice snapd package had already been removed because it also breaks the upgrade from 20.04 to 21.10 for some obscure reason.

Yes, just disable the sanpd integration:

sudo mv /etc/apt/apt.conf.d/20snapd.conf{,.disabled}

#4640 (comment)

Seconding #4279 (comment), I had to sudo apt install something on my wsl (Debian Bookworm) and it got the same error. So I downgraded to WSL1, do what #4279 (comment) suggested, and upgraded back to WSL2. Once that's done, everything worked and the issue is solved.

I would still recommend you have a backup before doing this because it is still sketchy.

I came here because of problems upgrading WSL2 version of Ubuntu 20 to 22.
What happened was that usrmerge was unable to mv /lib/modules to /usr/lib/modules because of the presence of the WSL2 kernel in /lib/modules.

The solution was to temporarily switch back to WSL version 1. Then, run dpkg --configure -a to finish the failed install. Finally switch back.

WSL will place the kernel in the old place, /lib/modules and not /usr/lib/modules but at least usrmerge has finished and won't complain.

ln -s /usr/lib /libtmp

For Ubuntu do-release-upgrade it must be ln -s usr/lib /libtmp.

Renaming/Deleting the directory is possible in Windows even if the wsl machine is dead in the Explorer finding the folder rootfs. It is in

• %USERNAME%\AppData\Local\Lxss
• %USERNAME%\AppData\Local\Packages\SOME_DISTRIBUTION_NAME
• A directory choosen while importing the machine