Kali Linux on WSL break after upgrade

Question

so my problem is as follows. I install Kali Linux from the wsl store with $wsl --install -d kali-linux. Following has been installed

PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2019.2"
VERSION_ID="2019.2"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"

If I then do $sudo apt-get update, I get the following error

Get:1 http://kali.download/kali kali-rolling InRelease [30.6 kB]
Err:1 http://kali.download/kali kali-rolling InRelease
  The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <devel@kali.org>
Fetched 30.6 kB in 1s (40.9 kB/s)
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://kali.download/kali kali-rolling InRelease: The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <devel@kali.org>
W: Failed to fetch http://http.kali.org/kali/dists/kali-rolling/InRelease  The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <devel@kali.org>
W: Some index files failed to download. They have been ignored, or old ones used instead.

Then i manually install kali-archive-keyring_2020.2_all.deb with $sudo dpkg -i kali-archive-keyring_2020.2_all.deb Then I do $sudo apt-get update and it updates the repositories as expected.

Then I do $sudo apt-get upgrade And so far it works I upgraded my kali to

PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2021.4"
VERSION_ID="2021.4"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"

Now when I execute the command $sudo apt-get upgrade it says that there are packages kept back.

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  apt apt-utils bind9-host bsdmainutils bsdutils coreutils cron curl dnsutils dpkg e2fsprogs fdisk findutils iproute2
  iptables isc-dhcp-client libbind9-161 libbsd0 libc-bin libc6 libcryptsetup12 libcurl4 libdevmapper1.02.1 libext2fs2
  libgnutls30 libiptc0 libirs161 libisccc161 libisccfg163 libldap-2.4-2 liblocale-gettext-perl liblwres161 libmount1
  libp11-kit0 libpam-modules libpam-modules-bin librtmp1 libselinux1 libsemanage-common libslang2 libstdc++6
  libsystemd0 libtext-charwidth-perl libtext-iconv-perl libudev1 libxml2 libxtables12 login logrotate mawk mlocate
  mount net-tools passwd perl-base procps rsyslog sed sudo systemd tar udev util-linux vim-common vim-tiny wget whois
0 upgraded, 0 newly installed, 0 to remove and 67 not upgraded.

From this point it doesn't matter what I am trying to install it always results in following error and the kali is broken I'm not able to further work with the OS.

/usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
dpkg: error processing package libc6:amd64 (--configure):
 installed libc6:amd64 package post-installation script subprocess returned error exit status 127
Errors were encountered while processing:
 libc6:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

For example if I try $sudo apt-get update afterwards it results in sudo: account validation failure, is your account locked?

I looked the errors up but I was not lucky finding any plausible solution for this. I would appreciate any help regarding this problem. Thanks in advance!

Answer 1

I can reproduce this, and I'm really surprised they let this slip through. The problem, as described in this answer is that the Kali files are woefully out-of-date for the manually installed version.

And sadly, it looks like that location is what is being used when we do wsl --install for Kali.

Updating the keyring (as you tried) used to be enough to fix it, but not any longer. Now even more signatures and/or packages are out of date.

We might find a way to fix them as well, but the easiest solution for now is to install using the Microsoft Store, rather than the wsl --install command. I have Kali installed in WSL from the Microsoft Store, and it installs as 2021.3 off the bat.

Note that you should do another wsl --unregister kali-linux first before installing the Microsoft Store version.

Alternatives

If you can't install from the Microsoft Store (and, from the comments, you can't, due to corporate policy), then there are a few alternatives. All involve obtaining a Kali tarball and then wsl --importing it.

I've personally tested each of these successfully with Kali:

• Option 1: Copy WSL Kali from another Computer that can access the Microsoft Store

  This is probably the most reliable method if it works for you. You won't be installing any Store package on your work computer, so it shouldn't violate that policy, at least.

  • Use another, non-work PC (assuming you have access) to install WSL and Kali from the Store.

  • Configure it with your username and password (the one you want to use on your work computer ultimately -- It doesn't matter whether it exists in Windows on that computer or not).

  • Optionally, go ahead and sudo apt get update && sudo apt get upgrade.

  • Exit Kali

  • From PowerShell or CMD:

    wsl --export kali-linux kali_clean.tar`
    

  • Transfer the resulting tarball to your work computer using a USB drive, assuming that's allowed by policy. If USB isn't allowed, then put the resulting tarball somewhere in the cloud that you have access and download it to your work computer. If you're going to be installing a VM as an alternative anyway, it seems to me that this is just as safe (and policy-compliant) as that process anyway. Ultimately, your going to download something to get Kali (or any other distribution) on your work computer.

  • Now on your work computer ...

  • Skip to the instructions below for "Installing and Configuring Kali from tarball" ...

---

• Option 2: Build from Kali WSL build-script

  • Kali is one of the few distributions I've seen that makes their WSL build process very easy to find. It's listed directly on the Get Kali page.

  • You'll need a separate WSL instance first here. Since we know that Ubuntu works from the wsl --install -d Ubuntu, just start out with that. You can delete it when you are done.

  • In Ubuntu ...

    sudo apt install -y debootstrap
    git clone https://gitlab.com/kalilinux/build-scripts/kali-wsl-chroot.git
    cd kali-wsl-chroot
    sudo ./build_chroot.sh
    # The build should complete for x64 but fail for ARM.  That's okay as long as `./x64/install.tar.gz` is created.
    sudo mv ./x64/install.tar.gz /mnt/c/somewhere/on/c/kali.install.tar.gz`
    

  • Exit Ubuntu

  • Uninstall the Ubuntu distribution (wsl --unregister Ubuntu) if you want.

  • Skip to the instructions below for "Installing and Configuring Kali from tarball" ...

---

• Option 3: Use Kali Docker image to create a tarball

  • Microsoft provides instructions here on how to manually import almost any distro. You'll need to:

  • First install another distribution such as Ubuntu (which does work correctly via wsl --install, of course)

  • Install Docker Desktop (if policy and license allows). Note that Docker Desktop now requires a paid license for corporate use, depending on the size of your company. As an alternative, you can install Docker Engine (which continues to be free/OSS) in the Ubuntu distribution.

  • docker pull kalilinux/kali or docker pull kalilinux/kali-rolling (see Kali Docker images.

  • Run the image (docker run kalilinux/kali:latest)

  • Get the name of the image from docker ps -a

  • Export the container to a tarball with docker export <name_or_id_from_above> kali.tar

  • Continue below to the instructions for "Installing and Configuring Kali from tarball" ...

---

Installing and Configuring Kali from the tarball

• Create a directory in Windows for Kali. I tend to use something like %userprofile%\WSL\instances\kali myself.

• cd to that directory in PowerShell.

• wsl --import Kali . path\to\kali.tar --version 2 (or kali.tar.gz for Option 2)

• This will create a Kali instance using the tarball which can then be started with wsl -d kali.

• You can also set it as the default with wsl --set-default kali.

• For the second (build script) and third (Docker image) options, you'll need to adduser your WSL user and set its password:

  adduser <username>
  usermod <username> -aG adm,cdrom,sudo,dip,plugdev
  

• For all of these, WSL will automatically start as the root user. That can be changed by creating /etc/wsl.conf per this Super User answer.

Answer 2

I would say that you missed using apt dist-upgrade instead of just apt upgrade. Unfortunately as a consequence I think you've probably broken your Kali so you'll have to wipe and reinstall.

Answer 3

This is a common problem with rolling-release distributions: if you don't more or less constantly keep up with their updates, trying to "catch up" after a long period of not updating will cause the update to fail.

So far, no rolling-release distribution have claimed to provide updateability from any past version to the current up-to-date state. Doing that would require either really rigorous change management which would slow down the introduction of new features and eradication of old bugs, or testing each new package with every past version of every package that depends upon it and that the package itself depends on, and setting the dependency metadata accordingly. The latter requires a lot of work, and the amount might exponentially with each new update.

So, in practice there is always some "sliding window" of time in which a rolling-release distribution should be updated. If you miss that window, the likelihood of problems is going to increase.

Kali's documentation says: (emphasis mine)

When should you update Kali?

If you have a default installation of Kali, you should be checking for updates every few weeks. If you need a new version of a tool, or hear about a security update, that may speed up the timetable. However, a good practice is that you ensure all tools work before an engagement and during that engagement you should not update. As Kali is a rolling release, once in a while issues will sneak into rolling and may break a tool that is needed.

If you are using last-snapshot, you will not receive updates until we release the next version of Kali for that year. For this reason, it is a good idea to follow the Kali Twitter, or check the Kali website every few months. Kali has a release four times a year, and follows a loose quarterly schedule.

So even if you used the last-snapshot version instead of the rolling one, quarterly releases would mean a jump from 2019.2 to 2021.4 would skip a total of 9 other releases in between them. Even using apt dist-upgrade, I would not bet on that being successful.

If Microsoft offers Kali 2019.2 for WSL today in December 2021, you should consider it utterly frozen and non-upgradeable at this point. You could use it as-is if it fits your requirements. If you need a newer version for WSL, you'll have to find a newer version packaged for WSL specifically.