Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #176620 > unrolled thread

apt-get is not following preferences.d

Back to article view | Back to linux.debian.user

Contents

  apt-get is not following preferences.d Matthias Bodenbinder <matthias@bodenbinder.de> - 2017-01-12 19:40 +0100
    Re: apt-get is not following preferences.d Michael Lange <klappnase@freenet.de> - 2017-01-12 19:50 +0100
      Re: apt-get is not following preferences.d Matthias Bodenbinder <matthias@bodenbinder.de> - 2017-01-13 09:20 +0100
        Re: apt-get is not following preferences.d Gene Heskett <gheskett@shentel.net> - 2017-01-13 09:50 +0100
        Re: apt-get is not following preferences.d Michael Lange <klappnase@freenet.de> - 2017-01-13 10:20 +0100
          Re: apt-get is not following preferences.d Michael Lange <klappnase@freenet.de> - 2017-01-13 11:10 +0100
    Re: apt-get is not following preferences.d Sven Hartge <sven@svenhartge.de> - 2017-01-12 20:40 +0100
      Re: apt-get is not following preferences.d Matthias Bodenbinder <matthias@bodenbinder.de> - 2017-01-23 08:50 +0100
        Re: apt-get is not following preferences.d Michael Lange <klappnase@freenet.de> - 2017-01-23 12:00 +0100
          Re: apt-get is not following preferences.d Matthias Bodenbinder <matthias@bodenbinder.de> - 2017-01-25 07:20 +0100
            Re: apt-get is not following preferences.d Michael Lange <klappnase@freenet.de> - 2017-01-25 20:10 +0100
              Re: apt-get is not following preferences.d Matthias Bodenbinder <matthias@bodenbinder.de> - 2017-01-27 07:10 +0100
                Re: apt-get is not following preferences.d Michael Lange <klappnase@freenet.de> - 2017-01-27 19:10 +0100
                  Re: apt-get is not following preferences.d davidson@freevolt.org - 2017-01-27 19:50 +0100
                Re: apt-get is not following preferences.d davidson@freevolt.org - 2017-01-27 19:20 +0100

#176620 — apt-get is not following preferences.d

Hi,

I have a weird behaviour on one of my debian boxes. It is running Mint LMDE and the issue is the following:

I have several additional sources defined: debian testing, debian backports, etc. I have defined priorities for the repos so that testing has prio 300 and does not replace the stable packages automatically. That works fine if I do an "apt-get update" followed by an "apt-get dist-upgrade". No issue.

The issue only occurs directly after boot. Somehow there is an "apt-get update" excecuted during boot time and this is ignoring the repo priorities. If I do a "apt-get dist-upgrade" directly after boot it wants to upgrade all packages to the testing version ("1547 upgraded, 358 newly installed, 97 to remove and 36 not upgraded."). This is a mistake.

After boot the priorities are all set to 500. Example:

####
12# apt-cache policy zip vim-common
zip:
  Installed: 3.0-8
  Candidate: 3.0-11
  Version table:
     3.0-11 0
        500 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
 *** 3.0-8 0
        500 http://ftp.de.debian.org/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status
vim-common:
  Installed: 2:7.4.488-7+deb8u1
  Candidate: 2:8.0.0134-1
  Version table:
     2:8.0.0134-1 0
        500 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
 *** 2:7.4.488-7+deb8u1 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2:7.4.488-7 0
        500 http://ftp.de.debian.org/debian/ jessie/main amd64 Packages
####

If I do an "apt-get update" everything is back to normal. 

####
15# apt-cache policy zip vim-common
zip:
  Installed: 3.0-8
  Candidate: 3.0-8
  Version table:
     3.0-11 0
        300 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
 *** 3.0-8 0
        500 http://ftp.de.debian.org/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status
vim-common:
  Installed: 2:7.4.488-7+deb8u1
  Candidate: 2:7.4.488-7+deb8u1
  Version table:
     2:8.0.0134-1 0
        300 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
 *** 2:7.4.488-7+deb8u1 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2:7.4.488-7 0
        500 http://ftp.de.debian.org/debian/ jessie/main amd64 Packages
####

What is going wrong here? Any idea?

Matthias

[toc] | [next] | [standalone]

#176621

Hi,
On Thu, 12 Jan 2017 19:35:59 +0100
Matthias Bodenbinder <matthias@bodenbinder.de> wrote:

> Hi,
> 
> I have a weird behaviour on one of my debian boxes. It is running Mint
> LMDE and the issue is the following:
> 
> I have several additional sources defined: debian testing, debian
> backports, etc. I have defined priorities for the repos so that testing
> has prio 300 and does not replace the stable packages automatically.
> That works fine if I do an "apt-get update" followed by an "apt-get
> dist-upgrade". No issue.
> 
> The issue only occurs directly after boot. Somehow there is an "apt-get
> update" excecuted during boot time and this is ignoring the repo
> priorities. If I do a "apt-get dist-upgrade" directly after boot it
> wants to upgrade all packages to the testing version ("1547 upgraded,
> 358 newly installed, 97 to remove and 36 not upgraded."). This is a
> mistake.
(...)
Just a shot in the dark:
maybe the apt-get update at boot time is done before a network connection
has been established? I noticed that this can lead to the exact behavior
you describe when pinning is in use. Apparently a bug in apt.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

It would be illogical to kill without reason.
		-- Spock, "Journey to Babel", stardate 3842.4

[toc] | [prev] | [next] | [standalone]

#176640

Am 12.01.2017 um 19:43 schrieb Michael Lange:
> Just a shot in the dark:
> maybe the apt-get update at boot time is done before a network connection
> has been established? I noticed that this can lead to the exact behavior
> you describe when pinning is in use. Apparently a bug in apt.
>
> Regards
>
> Michael

Hello Michael,

I gave it a try. I unplugged the network and did an apt-get update. This 
is throwing all the errors that the repos are not available. But in the 
end the next "apt-get dist-upgrade" indeed wants to update all packages 
to testing.

So it seems that this is an issue with network not ready while apt-get 
update is being performed.

How do I fix this? Where to look?

And thank you for the hint, Michael.
Matthias

[toc] | [prev] | [next] | [standalone]

#176641

On Friday 13 January 2017 03:16:50 Matthias Bodenbinder wrote:

> Am 12.01.2017 um 19:43 schrieb Michael Lange:
> > Just a shot in the dark:
> > maybe the apt-get update at boot time is done before a network
> > connection has been established? I noticed that this can lead to the
> > exact behavior you describe when pinning is in use. Apparently a bug
> > in apt.
> >
> > Regards
> >
> > Michael
>
> Hello Michael,
>
> I gave it a try. I unplugged the network and did an apt-get update.
> This is throwing all the errors that the repos are not available. But
> in the end the next "apt-get dist-upgrade" indeed wants to update all
> packages to testing.
>
> So it seems that this is an issue with network not ready while apt-get
> update is being performed.
>
> How do I fix this? Where to look?
>
> And thank you for the hint, Michael.
> Matthias

An old geezers thoughts on this is that if I see any error fetching the 
lists when I do an apt update, or apt-get update, I consider the system 
frozen in place until such time as the update succeeds w/o any errors. 
And I'll for sure question this list if the errors persist to the next 
day.  Debian may have suffered a machine failure, and its replacement 
might take a day to configure, and possibly another day to get 
synchronized, and only then might I update my sources list. But in these 
times, there is a high likelyhood of a round-robin setup at the debian 
site, spreading the load to 2 or 3 more other machines. So quite often 
and update done immediately after a failed update, works fine.

We users appreciate that, very much.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#176643

Hi,

On Fri, 13 Jan 2017 09:16:50 +0100
Matthias Bodenbinder <matthias@bodenbinder.de> wrote:

(...)
> I gave it a try. I unplugged the network and did an apt-get update.
> This is throwing all the errors that the repos are not available. But
> in the end the next "apt-get dist-upgrade" indeed wants to update all
> packages to testing.
> 
> So it seems that this is an issue with network not ready while apt-get 
> update is being performed.
> 
> How do I fix this? Where to look?

Not sure, you might try to grep through the files in /etc/init
and /etc/init.d if you find the one that calls apt-get update , then see
which package it belongs to and consider removing that package (or maybe
if possible configure it to leave apt-get alone).
Or, a quick-and-dirty solution that I have been using here occasinally
with services that fail at boot because the network isn't ready yet, you
can try to restart that service (or simply force another apt-get update)
with a line like
    printf "apt-get update" | at now + 2 minutes
somewhere where it is sure to be called close to the end of the boot
process.

I think the first solution is certainly the better one, though :-)

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

There is a multi-legged creature crawling on your shoulder.
		-- Spock, "A Taste of Armageddon", stardate 3193.9

[toc] | [prev] | [next] | [standalone]

#176645

On Fri, 13 Jan 2017 10:16:06 +0100
Michael Lange <klappnase@freenet.de> wrote:

(...)
> Not sure, you might try to grep through the files in /etc/init
> and /etc/init.d if you find the one that calls apt-get update , then see
> which package it belongs to and consider removing that package (or maybe
> if possible configure it to leave apt-get alone).

A small correction to this: of course the package should be *purge'd*,
not simply removed, to make sure the file in /etc/init/whatever will
actually go away.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Women professionals do tend to over-compensate.
		-- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before",
		   stardate 1312.9.

[toc] | [prev] | [next] | [standalone]

#176625

Matthias Bodenbinder <matthias@bodenbinder.de> wrote:

> What is going wrong here? Any idea?

Possibly https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849382

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#176928

Am 12.01.2017 um 20:31 schrieb Sven Hartge:
> Matthias Bodenbinder <matthias@bodenbinder.de> wrote:
>
>> What is going wrong here? Any idea?
>
> Possibly https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849382
>
> Grüße,
> Sven.
>

Yes, this is exactly what happens on my PC. But it has no solution.

In the meantime I found a workaround. I moved /etc/cron.daily/apt out of 
the way. It looks like this script is being executed during boot before 
the network is ready.

How can I make sure that the script /etc/cron.daily/apt is only executed 
when network is up? What is this script good for anyways?

Matthias

[toc] | [prev] | [next] | [standalone]

#176933

Hi,

On Mon, 23 Jan 2017 08:40:32 +0100
Matthias Bodenbinder <matthias@bodenbinder.de> wrote:

(...)Yes, this is exactly what happens on my PC. But it has no solution.
> 
> In the meantime I found a workaround. I moved /etc/cron.daily/apt out
> of the way. It looks like this script is being executed during boot
> before the network is ready.
> 
> How can I make sure that the script /etc/cron.daily/apt is only
> executed when network is up? What is this script good for anyways?

>From what the comment at the top of the script says:

# This file understands the following apt configuration variables:
# Values here are the default.
# Create /etc/apt/apt.conf.d/02periodic file to set your preference.
(...)
#
#  APT::Periodic::Update-Package-Lists "0";
#  - Do "apt-get update" automatically every n-days (0=disable)
#    

it looks like you have a file /etc/apt/apt.conf.d/02periodic where 
APT::Periodic::Update-Package-Lists is set to "1" (or so). Here (on
Jessie) such a file does not exist, and as promised the updates don't
happen.

Regards

Michael



.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

What kind of love is that?  Not to be loved; never to have shown love.
		-- Commissioner Nancy Hedford, "Metamorphosis",
		   stardate 3219.8

[toc] | [prev] | [next] | [standalone]

#176993

Am 23.01.2017 um 11:47 schrieb Michael Lange:
> Hi,
>
> On Mon, 23 Jan 2017 08:40:32 +0100
> Matthias Bodenbinder <matthias@bodenbinder.de> wrote:
>
> (...)Yes, this is exactly what happens on my PC. But it has no solution.
>>
>> In the meantime I found a workaround. I moved /etc/cron.daily/apt out
>> of the way. It looks like this script is being executed during boot
>> before the network is ready.
>>
>> How can I make sure that the script /etc/cron.daily/apt is only
>> executed when network is up? What is this script good for anyways?
>
>>From what the comment at the top of the script says:
>
> # This file understands the following apt configuration variables:
> # Values here are the default.
> # Create /etc/apt/apt.conf.d/02periodic file to set your preference.
> (...)
> #
> #  APT::Periodic::Update-Package-Lists "0";
> #  - Do "apt-get update" automatically every n-days (0=disable)
> #
>
> it looks like you have a file /etc/apt/apt.conf.d/02periodic where
> APT::Periodic::Update-Package-Lists is set to "1" (or so). Here (on
> Jessie) such a file does not exist, and as promised the updates don't
> happen.
>
> Regards
>
> Michael

Hello Michael,

I do not have that file /etc/apt/apt.conf.d/02periodic. I put 
/etc/cron.daily/apt back where it belongs and this morning the pinning 
was screwed up again. This is really weird.

Matthias

[toc] | [prev] | [next] | [standalone]

#177000

Hi,

On Wed, 25 Jan 2017 07:18:07 +0100
Matthias Bodenbinder <matthias@bodenbinder.de> wrote:

(...)
> 
> I do not have that file /etc/apt/apt.conf.d/02periodic. I put 
> /etc/cron.daily/apt back where it belongs and this morning the pinning 
> was screwed up again. This is really weird.

Then you could try to create the file and add the line 

APT::Periodic::Update-Package-Lists "0";

and see if that helps. Maybe your system somehow has a different default.

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Is truth not truth for all?
		-- Natira, "For the World is Hollow and I have Touched
		   the Sky", stardate 5476.4.

[toc] | [prev] | [next] | [standalone]

#177025

Am 25.01.2017 um 20:04 schrieb Michael Lange:
> Hi,
>
> On Wed, 25 Jan 2017 07:18:07 +0100
> Matthias Bodenbinder <matthias@bodenbinder.de> wrote:
>
> (...)
>>
>> I do not have that file /etc/apt/apt.conf.d/02periodic. I put
>> /etc/cron.daily/apt back where it belongs and this morning the pinning
>> was screwed up again. This is really weird.
>
> Then you could try to create the file and add the line
>
> APT::Periodic::Update-Package-Lists "0";
>
> and see if that helps. Maybe your system somehow has a different default.
>
> Regards
>
> Michael

I created that file with this line but it does not help. Still the same 
odd pinning after boot.

So my problem might not be related to /etc/cron.daily/apt. I guess I 
have to start searching again :-(

Matthias

[toc] | [prev] | [next] | [standalone]

#177044

On Fri, 27 Jan 2017 07:00:19 +0100
Matthias Bodenbinder <matthias@bodenbinder.de> wrote:

> I created that file with this line but it does not help. Still the same 
> odd pinning after boot.
> 
> So my problem might not be related to /etc/cron.daily/apt. I guess I 
> have to start searching again :-(

Though the fact that removing the file helps seems to indicate that it
actually is related.  
Have you read the documentation at the beginning of the file, maybe on
your system the options are different than here (Jessie)?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

A princess should not be afraid -- not with a brave knight to protect her.
		-- McCoy, "Shore Leave", stardate 3025.3

[toc] | [prev] | [next] | [standalone]

#177046

On Fri, 27 Jan 2017, Michael Lange wrote:

> On Fri, 27 Jan 2017 07:00:19 +0100
> Matthias Bodenbinder <matthias@bodenbinder.de> wrote:
>
>> I created that file with this line but it does not help. Still the same
>> odd pinning after boot.
>>
>> So my problem might not be related to /etc/cron.daily/apt. I guess I
>> have to start searching again :-(
>
> Though the fact that removing the file helps seems to indicate that it
> actually is related.
> Have you read the documentation at the beginning of the file, maybe on
> your system the options are different than here (Jessie)?

Just for example, you might consider setting the verbosity to a
non-default, informative value in /etc/apt/apt.conf.d/02periodic

[from the preamble comments in /etc/cron.daily/apt]
#  APT::Periodic::Verbose "0";
#  - Send report mail to root
#      0:  no report             (or null string)
#      1:  progress report       (actually any string)
#      2:  + command outputs     (remove -qq, remove 2>/dev/null, add -d)
#      3:  + trace on

[toc] | [prev] | [next] | [standalone]

#177045

On Fri, 27 Jan 2017, Matthias Bodenbinder wrote:
> Am 25.01.2017 um 20:04 schrieb Michael Lange:
>> Hi,
>> 
>> On Wed, 25 Jan 2017 07:18:07 +0100
>> Matthias Bodenbinder <matthias@bodenbinder.de> wrote:
>> 
>> (...)
>>> 
>>> I do not have that file /etc/apt/apt.conf.d/02periodic. I put
>>> /etc/cron.daily/apt back where it belongs and this morning the pinning
>>> was screwed up again. This is really weird.
>> 
>> Then you could try to create the file and add the line
>> 
>> APT::Periodic::Update-Package-Lists "0";
>> 
>> and see if that helps. Maybe your system somehow has a different default.
>> 
>> Regards
>> 
>> Michael
>
> I created that file with this line but it does not help. Still the same odd 
> pinning after boot.
>
> So my problem might not be related to /etc/cron.daily/apt. I guess I have to 
> start searching again :-(

Looking through the other defaults described in /etc/cron.daily/apt ,
this one looks relevant:

#  APT::Periodic::Enable "1";
#  - Enable the update/upgrade script (0=disable)

If I were you, I would do

# echo 'APT::Periodic::Enable "0";' >> /etc/apt/apt.conf.d/02periodic

and see if that works.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web