[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt{-cache,-get,itude} show wrong version of package after update



On Wed 28 Mar 2018 at 21:07:35 (+0200), Jean-Baptiste Thomas wrote:
> > Try running:
> > sudo apt-get update # one more time, to be sure
> > # then
> > apt-cache policy ntp
> >
> > and see what version it refers to.
> 
> Thanks for the suggestions folks but there's not much to see
> there, no packages are pinned.
> 
> I've made some progress, though. A closer look at the output
> reveals that "Packages" is "Ign:", which is apparently [1]
> apt-get's way of saying "I was unable to download it but that's
> not a problem".
> 
>   # apt-get update
>   Ign:1 http://mymirror/debian stretch InRelease
>   [...]
>   Get:3 http://mymirror/debian stretch Release [118 kB]
>   Get:4 http://mymirror/debian stretch Release.gpg [2434 B]
>   Ign:5 http://mymirror/debian stretch/main amd64 Packages
>   [...]
> 
> strace tells me that apt-get uses the cached version in
> /var/lib/apt/lists/, which may be why it thinks that not being
> able to download it is not a problem.
> 
> Unfortunately, the Packages file in /var/lib/apt/lists/ is out
> of date by months because it pertains to 9.2 while the mirror
> has 9.4. Diffing the two shows why apt-get looks for the wrong
> version of ntp :
> 
>  Package: ntp
> -Version: 1:4.2.8p10+dfsg-3+deb9u1
> +Version: 1:4.2.8p10+dfsg-3+deb9u2
>  Installed-Size: 1804
> 
> What I'd like to know now is : what prevents apt-get from
> downloading the Packages file from the mirror ? Wget can !
> 
> [1] https://superuser.com/questions/454867/

Move all the files out of /var/lib/apt/lists/ so that apt-get update
has to download fresh copies. That should get you back on track.

By all means take the opportunity to compare the old and the new files
to look for causes. In the simplest scenario, which probably is not
the cause but might illustrate the kind of problem, a failed download
could leave a file with a timestamp at the point of failure. That
erroneous timestamp would be more recent than the mirror's (correct)
timestamp and could cause update to think there's nothing to do on
subsequent runs until the original file on the mirror was modified.

Cheers,
David.


Reply to: