E: cannot read /etc/apt/trusted.gpg.d/ #27
Loading…
Add table
Add a link
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?
mmdebstrap 1.2.1on debian bookwormI don't have the directory
/etc/apt/trusted.gpg.d/andmmdebstrapfails with the errorE: cannot read /etc/apt/trusted.gpg.d/The reason why I don't have that directory is because I define the signing keys in the deb822-style debian.sources directly.
If I simply create that directory, but keep it empty, mmdebstrap works.
mmdebstrap should not assume that that directory exists.
I'm a bit puzzled. Does this mean you do not have the
debian-archive-keyringpackage installed on your system??I have
debian-archive-keyringinstalled, and the keys are in/usr/share/keyrings/This is how my
/etc/apt/sources.list.d/bullseye.sourceslooks like:Then you just messed up your
debian-archive-keyringpackage:You deleted files that were owned by a package. This is bad practice and you should not do that. On the next update of your
debian-archive-keyringpackage, these files will be back so your deletion doesn't even have a lasting effect. Why would you want the directory deleted?Note that debian is on track for making these changes:
Moving away from using
/etc/apt/sources.listand instead using deb822-style debian.sourcesMoving away from using
/etc/apt/trusted.gpgfile (already done in bookworm) and/etc/apt/trusted.gpg.d/directory, in preference to specifying the keys directly in the sources file.Using a new directory for user-supplied 3rd party keyrings,
/etc/apt/keyrings/instead of asking users to put them in/etc/apt/trusted.gpg.d/(where they could sign any packages) or/usr/share/keyrings/(which interferes with package management). This is already done in ubuntu.All of this was discussed at debconf 2022, and there probably is a writeup of this somewhere on the debian wiki, but I can't find it right now. I also remember the speaker having a blogpost about it.
You are right. I'm not arguing that mmdebstrap shouldn't make this change.
But the reasons you gave initially are the wrong ones. The ones you gave now are the ones you should've listed in your initial report.
dpkg-statoverrideis used to prevent writing to that directory so that no package will accidentally drop a keyring that will be trusted to sign all packages.Additionally, package updates do not replace config files in
/etc/if it detects that they have been deleted by the user.dpkg --force-confmiss <package>would be needed to reinstall these config files(I'm not 100% sure about this though)
But why do you need the directory deleted?
I don't need it deleted, I simply noted surprising behavior that
mmdebstrapgives a hard error if it can't find that directory, but it doesn't even need any contents of that directory.My workaround of creating that directory and keeping it empty allowed mmdebstrap to proceed.
Fixed in
2f27eccad4I've done some testing with mmdebstrap from git, on debian bookworm.
/etc/apt/sources.listfile doesn't exist/etc/apt/trusted.gpg.d/directory doesn't exist/etc/apt/sources.list.d/bookworm.sourcesexists with the following content:Running this command (mmdebstrap in current directory):
./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debianProduces this output:
Now if I do:
mkdir /etc/apt/trusted.gpg.d/ && rm -r /bookworm-chrootAnd run the same command as before:
./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debianI get this output:
So something somewhere in the code still relies on existence of
/etc/apt/trusted.gpg.d/despite it having no contents.Perhaps my bad, this invocation indeed works perfectly:
./mmdebstrap --dry-run bookworm /bookworm-chroot /etc/apt/sources.list.d/bookworm.sourcesThank you for the quick fix, everything works now.
If you just want to verify whether it succeeds or not, you can pass
/dev/nullinstead of a directory.What platform are you running this in??
Yes, because you didn't tell mmdebstrap which keys to use. By default it searches for keys in the location that your local apt knows as
Dir::Etc::trustedpartswhich is/etc/apt/trusted.gpg.d/if you didn't set it to a different directory.It relies on whatever
Dir::Etc::trustedpartspoints to in case you did not pass an alternative keyring viaSigned-By. If you don't want that, then tell your local apt to look into a different directory but this is not up to mmdebstrap.podman
Indeed using:
fixes everything. Thank you once again.