Ask
20
@ssh_serkan ·

Package updates fail in my subsystem distribution because the signing keys are missing, and I cannot install the tool that fixes keys

A freshly installed distribution inside the Linux subsystem cannot update its package lists — everything fails with signature verification errors saying the repository is not signed.

The usual advice is a key management command, which fails because the tool it depends on is not installed. And I cannot install it, because installing anything requires working package lists.

Another neat circle. How do I break out of it?

4 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @hyperv_hakan · 3w ago

    The circle breaks the same way as any bootstrap problem: fetch one file by hand, verify it, and install it with a tool that does not need the network.

    The distribution publishes a keyring package containing the current signing keys. Download that package directly with a downloader that is already present, then install it with the low-level package tool rather than the network-aware one.

    The key point is to verify the file before trusting it. You are installing a trust anchor over a channel you have not authenticated, so compare its checksum against the value published by the distribution, fetched from a machine that works. Skipping that step converts a package problem into a security problem.

    After installing the keyring, refresh the package lists and everything proceeds normally.

    29
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @wsl_wanda · 2w ago

    Worth understanding why this happens specifically to subsystem installations, because it tells you how to avoid it.

    Distribution images made available through the subsystem are snapshots, and they can be considerably older than the current release. Signing keys are rotated periodically, and an image built before a rotation ships with keys that have since been replaced. Everything worked the day it was published and breaks for everyone who installs it afterwards.

    So the recurring fix is: install the image, then immediately update the keyring before anything else.

    It is also an argument for getting images from the distribution's own current source rather than an older packaged one, where that is an option. A current image does not have the problem at all.

    25
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @winadmin_wiktor · 2w ago

    One trap worth flagging: advice for this problem circulates with specific file names and URLs, and those go stale.

    Keyring package names and locations change over time, so a command copied from a two-year-old answer frequently returns a not-found error — which people then interpret as a further problem rather than as an outdated instruction.

    The durable approach is to look up the current keyring package on the distribution's own site and use today's name, rather than copying a command. Slower by two minutes and it works on the first attempt.

    20
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @helpdesk_hana · 2w ago

    The other honest option, if the distribution has just been installed and contains nothing you care about: delete it and install a current image.

    Unregistering a distribution and installing it again takes a couple of minutes, and if the underlying problem is that the snapshot is old, a current one avoids the whole exercise.

    Worth doing that before spending an hour on a machine you set up ten minutes ago.

    12
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report