mmdebstrap stretch fails with NO_PUBKEY AA8E81B4331F7F50 NO_PUBKEY 112695A0E562B32A #2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hello,
I have an automated base image running every day which suddenly stopped working from apr, 3rd. And I can't figure out the reason why it fails on those keys. The log is :
Hi there! Take a look at #1.
Can you share your invocation? This works for me:
I can reproduce the problem with the bare invocation :
My exact invocation is :
I've tried without my caching proxy, same problem.
Should I try with the patch in #1 ?
And I was mistaken, it started to fail on 03/30 (it worked on 03/29).
issue following commands (in case you're using git):
and then try your setup again.
What says
dpkg-query --show --showformat='${Version}\n' gnupg?On my machine:
2.2.27-2.I gest Buster's release :
Should I pull buster-backport's one ?
No, you shouldn't. I've been working on this issue.
I've been able to hit same error using "buster" container:
Dunno how to fix it ASAP and is it mmdebstrap bug or something else had broken.
Also, @josch, should i modify my MR with respect of "stretch" as host (it has old gnupg without
--show-keyssupport)?I'm still unable to reproduce this. You say you are running mmdebstrap from git on Debian buster? This works for me:
@rockdrilla no, mmdebstrap from git only has to work with what is currently Debian stable -- oldstable is not supported, especially now that it will soon become oldoldstable.
Your latest invocation works, but the bare one does not. The host is indeed an up-to-date Buster.
My latest runs :
It's a build host with stretch/buster/bullseye APT sources and their trusted keys, maybe this context is important.
If you are mixing stretch, buster and bullseye, then the context is indeed extremely important. What is also important is your apt configuration and which keys apt is trusting and not trusting in your specific setup. There are several ways forward:
a) show how to get from a clean install to a state that triggers the problem
b) tell us enough about your setup so that we can replicate it
c) find somebody else with the same problem and figure out the similarities between your setups
@rockdrilla says that they can reproduce the problem inside a buster container -- can you show us how to set up that container?
Funny, I can reproduce it with podman but I cannot reproduce it with the exact same rootfs and a simple
chrootto enter it.EDIT Okay, now I can reproduce it even without fancy container software:
@rockdrilla do you see an easy way to support old gnupg versions without
--show-keys?@zerodeux what is the reason you use mmdebstrap from git instead of the version in buster?
@josch The reason is the Jessie support you added in 0.6.0 (Buster's is 0.4.1), I still need to build legacy Jessie stuff (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945119).
I have been using 0.6.0 since then, I only tried 0.7.5 and HEAD to see if this would fix this GPG key problem.
@zerodeux okay, I understand. Now the problem with HEAD is, that it uses a gpg option that is not available in buster. One workaround for you would be to not have the package
libdistro-info-perlinstalled when using 0.7.5. Is that a possibility for you?If you're talking about the host, I have already checked that it is installed (libdistro-info-perl 0.21), it does not fix the pb with 0.7.5 or HEAD.
If you're talking about the host, I have already checked that it is installed (libdistro-info-perl 0.21), it does not fix the pb with 0.7.5 or HEAD.
Additionally, this boils down to apt not knowing about the keys anymore. For example if you try to build a jessie chroot with mmdebstrap HEAD on Debian unstable you will get:
The workaround is to tell mmdebstrap about the location of the gpg key manually by passing a full apt sources.list line:
This is of course missing the security and updates mirror locations, so ideally, you'd want to create a sources.list file with content like this:
And then run mmdebstrap like this:
Alternatively, you can also let apt know about and trust
/usr/share/keyrings/debian-archive-removed-keys.gpgby putting the keys into/etc/apt/trusted.gpg.dYou misread. Did you try not having libdistro-info-perl installed?
Ohhh sorry. I can do that, it's not one of my dependency. It changes the error with something that obviously prompted me to install libdistro-info-perl in the first place :
This workaround does work for me and it's acceptable on my build VM. Thanks a lot !
Yeah, so the actual problem is, that there is really no good way to map a Debian distro to a gpg key file reliably. It breaks once new keys get uploaded and the distroinfo information becomes outdated. This will remain a problem for distros that are oldstable or oldoldstable until we have a reliable way to figure out keyring locations from a distro name.
@josch, which releases i'm/we're targeting to support (in past)?
@rockdrilla mmdebstrap should work on the current stable and be able to create oldstable, stable, testing and unstable chroots. The version right now does not work on stable, which is okay because the next release will only happen once testing has become the new stable.