Re: Problems with apt in a clean stretch install.
Hi,
I'm glad you could finally fix the issue.
On Wed, 5 Jul 2017 12:15:33 +0930
"Wayne Hartell" <w.hartell@ozemail.com.au> wrote:
> I know I just wrote a long e-mail on this, but I think I just figured
> out in my own mind exactly what is going on and wanted to document it.
>
>
>
> As others have said the /etc/apt/trusted.gpg file is the issue.
>
>
>
> It seems that what is happening is this:
>
>
>
> 1. For some reason the first use of software-properties-gtk
> creates this file, but (the bug I presume) is that it's not created
> correctly. It's empty and potentially has the wrong permissions on it.
Maybe there is actually a bug in software-properties-gtk. I mentioned
earlier that on Jessie the permissions of the file are 0600, I now
checked on a laptop with Sparky linux (which basically *is* stretch) and
found that the file's permissons on that system are 0644, so maybe the
newer version of apt requires this and software-properties-gtk fails to
set this correctly?
>
> a. I suspect it being empty is the consequence of the
> permissions, but I am just guessing.
Maybe, but since this file appears to be the place where custom added keys
go (whereas keys from debian keyring packages apparently go
to /etc/apt/trusted.gpg.d/ ) it might also be ok if there are none. From
what you experienced it seems possible that maybe newer versions of apt
require a new format of this file and again software-properties-gtk fails
torespect this, but that is of course just another guess.
>
> 2. Running 'apt-get update' will now produce errors about user
> "_apt" and not being able to read the /etc/apt/trusted.gpg file.
>
> 3. Making /etc/apt/trusted.gpg readable (i.e., 0600 --> 0644) only
> obfuscates the problem; now the empty file is accessible (so no errors
> about reading it), but the keys are not available
> and /etc/apt/trusted.gpg.d is now ignored and results in key errors.
> [Wild goose chase may now commence].
This might back up my above guess.
>
> 4. The real fix is to delete /etc/apt/trusted.gpg and after that
> point it seems not to be created again (even if running
> software-properties-gtk). Everything works again since
> the /etc/apt/trusted.gpg.d folder can once again be interrogated.
When I run apt-key list here, /etc/apt/trusted.gpg always seems to be
evaluated first, so I guess that if this file is corrupted the command
just stops with an error message.
If one wants to confirm that it is actually software-properties-gtk who
creates a corrupted trusted.gpg file it should be possible to add (for
testing purposes) a key from a third party repo manually with
software-properties-gtk and later again with apt-key add and compare the
result. If it works from the command line and fails from the gui it would
be proof enough to desreve a bug report, I think.
Regards
Michael
.-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-.
War isn't a good life, but it's life.
-- Kirk, "A Private Little War", stardate 4211.8
Reply to: