Open sirredbeard opened 5 years ago
I can reproduce this, but it doesn't make sense. @dmach, @j-mracek, do you have any ideas what's going on here?
I am running into this as well
@sirredbeard @hugo-vrijswijk @Conan-Kudo It looks like a serious issue. Please could you open a bugzilla (https://bugzilla.redhat.com/) with additional information about version of dnf, libdnf. Thanks a lot.
Is there any particular information you would find useful, e.g. strace, etc.?
Because of worharround:
sudo rm -r /var/lib/rpm/.rpm.lock
I believe that the issue is in RPM. DNF never couch "/var/lib/rpm/" location with a default setting.
We've been here before with rpm issues on WSL.
Last time it was the result of an mmap bug in the WSL1 translation layer causing the berkeley DB implementation in rpm to go haywire, see bug report.
In the past we have been told Red Hat will not help us with these issues on WSL, hence we've been working with Oracle on them.
If you think Red Hat is willing to lend a hand now, I would be glad to submit a bug report to the Red Hat bugzilla.
In the past we have been told Red Hat will not help us with these issues on WSL
It is not Red Hat that does not wanna help, as we (@sjenning Seth Jennings and I) experienced these same issues when we were working on the official Fedora images. However, this is NOT caused by us, but by missing/incorrect functionality from the WSL environment (LXSS/WSL1). Since then we have been reassigned to work on other issues and projects. Also, these issues do not exist on WSL2.
Steps to reproduce:
$ sudo dnf install nano -y
## install nano to show dnf is working$ sudo dnf update -y
## update$ sudo dnf install lynx -y
## try to install lynxExpected results:
lynx is installed successfully.
Actual results:
Workaround:
$ sudo rm -r /var/lib/rpm/.rpm.lock
Info:
Reproducible on Windows builds 17134 and 18908
dnf and dnf-yum have been updated since the most recent Fedora Remix for WSL release but excluding them from updates does not avoid the above-described issue.