Re: Problems with apt in a clean stretch install.
On Wed 05 Jul 2017 at 11:10:44 (+0200), Michael Lange wrote:
> 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.
This is a very long thread, and I make no apologies if I have missed
something, but I've seen no reference to §5.3.2 in the Release Notes
for stretch. This touches on changes made to apt and troubleshooting
its new user-privelege mode. (It's a long time since I'd read these
but was revisiting them in connection with other threads.)
Cheers,
David.
Reply to: