E: cannot read /etc/apt/trusted.gpg.d/ #27
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?
mmdebstrap 1.2.1
on debian bookwormI don't have the directory
/etc/apt/trusted.gpg.d/
andmmdebstrap
fails 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-keyring
package installed on your system??I have
debian-archive-keyring
installed, and the keys are in/usr/share/keyrings/
This is how my
/etc/apt/sources.list.d/bullseye.sources
looks like:Then you just messed up your
debian-archive-keyring
package: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-keyring
package, 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.list
and instead using deb822-style debian.sourcesMoving away from using
/etc/apt/trusted.gpg
file (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-statoverride
is 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
mmdebstrap
gives 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
2f27eccad4
I've done some testing with mmdebstrap from git, on debian bookworm.
/etc/apt/sources.list
file doesn't exist/etc/apt/trusted.gpg.d/
directory doesn't exist/etc/apt/sources.list.d/bookworm.sources
exists with the following content:Running this command (mmdebstrap in current directory):
./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian
Produces this output:
Now if I do:
mkdir /etc/apt/trusted.gpg.d/ && rm -r /bookworm-chroot
And run the same command as before:
./mmdebstrap --dry-run bookworm /bookworm-chroot https://deb.debian.org/debian
I 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.sources
Thank you for the quick fix, everything works now.
If you just want to verify whether it succeeds or not, you can pass
/dev/null
instead 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::trustedparts
which is/etc/apt/trusted.gpg.d/
if you didn't set it to a different directory.It relies on whatever
Dir::Etc::trustedparts
points 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.