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

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

Error while upgrading from Wheezy to Stretch

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

Contents

  Error while upgrading from Wheezy to Stretch David Parker <dparker@utica.edu> - 2018-04-11 21:40 +0200
    Re: Error while upgrading from Wheezy to Stretch deloptes <deloptes@gmail.com> - 2018-04-11 23:20 +0200
    Re: Error while upgrading from Wheezy to Stretch Patrick Bartek <nemommxiv@gmail.com> - 2018-04-12 01:40 +0200
    Re: Error while upgrading from Wheezy to Stretch David Wright <deblis@lionunicorn.co.uk> - 2018-04-12 03:00 +0200
      Re: Error while upgrading from Wheezy to Stretch Dan Ritter <dsr@randomstring.org> - 2018-04-12 12:50 +0200
        Re: Error while upgrading from Wheezy to Stretch David Wright <deblis@lionunicorn.co.uk> - 2018-04-12 20:40 +0200
          Re: Error while upgrading from Wheezy to Stretch David Parker <dparker@utica.edu> - 2018-04-19 17:00 +0200
            Re: Error while upgrading from Wheezy to Stretch Roberto C. Sánchez <roberto@debian.org> - 2018-04-19 17:20 +0200
              Re: Error while upgrading from Wheezy to Stretch Greg Wooledge <wooledg@eeg.ccf.org> - 2018-04-19 17:30 +0200
                Re: Error while upgrading from Wheezy to Stretch Roberto C. Sánchez <roberto@debian.org> - 2018-04-19 17:40 +0200
                  Re: Error while upgrading from Wheezy to Stretch David Parker <dparker@utica.edu> - 2018-04-19 17:50 +0200
                    Re: Error while upgrading from Wheezy to Stretch Roberto C. Sánchez <roberto@debian.org> - 2018-04-19 19:50 +0200
                  Re: Error while upgrading from Wheezy to Stretch Gene Heskett <gheskett@shentel.net> - 2018-04-19 20:50 +0200
                    Re: Pinning (was Re: Error while upgrading from Wheezy to Stretch) Greg Wooledge <wooledg@eeg.ccf.org> - 2018-04-19 21:00 +0200
                      Re: Pinning (was Re: Error while upgrading from Wheezy to Stretch) <tomas@tuxteam.de> - 2018-04-19 21:30 +0200
                      Re: Pinning (was Re: Error while upgrading from Wheezy to Stretch) Gene Heskett <gheskett@shentel.net> - 2018-04-19 21:50 +0200
                        Re: Pinning (was Re: Error while upgrading from Wheezy to Stretch) Greg Wooledge <wooledg@eeg.ccf.org> - 2018-04-19 22:30 +0200
                    Re: Error while upgrading from Wheezy to Stretch Dan Ritter <dsr@randomstring.org> - 2018-04-19 21:30 +0200
                      Re: Error while upgrading from Wheezy to Stretch Gene Heskett <gheskett@shentel.net> - 2018-04-19 22:40 +0200
                    Re: Error while upgrading from Wheezy to Stretch Roberto C. Sánchez <roberto@debian.org> - 2018-04-20 00:50 +0200
            Re: Error while upgrading from Wheezy to Stretch <tomas@tuxteam.de> - 2018-04-19 17:30 +0200
    Re: Error while upgrading from Wheezy to Stretch songbird <songbird@anthive.com> - 2018-04-12 17:00 +0200
    Re: Error while upgrading from Wheezy to Stretch Jimmy Johnson <field.engineer@gmail.com> - 2018-04-20 05:00 +0200

Page 1 of 2  [1] 2  Next page →

#194710 — Error while upgrading from Wheezy to Stretch

[Multipart message — attachments visible in raw view] — view raw

Hello,

I am trying to upgrade two test boxes from Wheezy to Stretch (skipping
Jessie).  The upgrade worked on one of them, although I ran into errors and
had to run "apt-get -f install" a few times, but that resolved the issues
and it ultimately worked.

However, on the second box, I ran into an error about halfway through the
upgrade, and I'm not able to get past it.  No matter what I do, I keep
running into version mismatch issue with libpam-modules.  It's preventing
the upgrade from finishing.

# apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer
required:
  libcfg4 libcib1 libclass-isa-perl libconfdb4 libcoroipcc4 libcoroipcs4
libcrmcluster1 libcrmcommon2 libevs4 liblogsys4 libpe-status3 libpengine3
libpload4 libquorum4 libsam4 libstonithd1 libswitch-perl
  libsystemd-login0 libtransitioner1 libvotequorum4
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libpam-modules
The following packages will be upgraded:
  libpam-modules
1 upgraded, 0 newly installed, 0 to remove and 199 not upgraded.
2 not fully installed or removed.
Need to get 0 B/308 kB of archives.
After this operation, 62.5 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Preconfiguring packages ...
dpkg: dependency problems prevent processing triggers for man-db:
 man-db depends on bsdmainutils; however:
  Package bsdmainutils is not configured yet.

dpkg: error processing archive
/var/cache/apt/archives/libpam-modules_1.1.8-3.6_amd64.deb (--unpack):
 dependency problems - leaving triggers unprocessed
Errors were encountered while processing:
 /var/cache/apt/archives/libpam-modules_1.1.8-3.6_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Any ideas or suggestions for resolving this will be greatly appreciated.

Thanks!
Dave

-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

[toc] | [next] | [standalone]

#194711

David Parker wrote:

> Any ideas or suggestions for resolving this will be greatly appreciated.

it is definitely less effort to upgrade to jessie and then to stretch - it
just takes a bit more time, but less effort in debugging.

can you reinstall or configure bsdmainutils?
or purge man and bsdmainutils and add them later if needed

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

#194713

On Wed, 11 Apr 2018 15:31:32 -0400 David Parker <dparker@utica.edu>
wrote:

> Hello,
> 
> I am trying to upgrade two test boxes from Wheezy to Stretch (skipping
> Jessie).  The upgrade worked on one of them, although I ran into
> errors and had to run "apt-get -f install" a few times, but that
> resolved the issues and it ultimately worked.
> 
> However, on the second box, I ran into an error about halfway through
> the upgrade, and I'm not able to get past it.  No matter what I do, I
> keep running into version mismatch issue with libpam-modules.  It's
> preventing the upgrade from finishing.
> 
> # apt-get -f install
> [snip]
> 
> Any ideas or suggestions for resolving this will be greatly
> appreciated.

Yes.  Retore both Wheezy systems from their respective back ups Then
read and follow the upgarde instructions which you should have done
first. And DON'T skip upgrading to interim releases to save time
thinking it's not necessary.  That piece of advice is in the
iinstructions, too, along with a lot of other wisdom to make your
upgrade as unproblematical as possible.

B

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

#194714

On Wed 11 Apr 2018 at 15:31:32 (-0400), David Parker wrote:
> I am trying to upgrade two test boxes from Wheezy to Stretch (skipping
> Jessie).  The upgrade worked on one of them, although I ran into errors and
> had to run "apt-get -f install" a few times, but that resolved the issues
> and it ultimately worked.
> 
> However, on the second box, I ran into an error about halfway through the
> upgrade, and I'm not able to get past it.  No matter what I do, I keep
> running into version mismatch issue with libpam-modules.  It's preventing
> the upgrade from finishing.

The other "incantation" that's worth trying is

# dpkg --configure -a

Cheers,
David.

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

#194717

On Wed, Apr 11, 2018 at 07:57:07PM -0500, David Wright wrote:
> On Wed 11 Apr 2018 at 15:31:32 (-0400), David Parker wrote:
> > I am trying to upgrade two test boxes from Wheezy to Stretch (skipping
> > Jessie).  The upgrade worked on one of them, although I ran into errors and
> > had to run "apt-get -f install" a few times, but that resolved the issues
> > and it ultimately worked.
> > 
> > However, on the second box, I ran into an error about halfway through the
> > upgrade, and I'm not able to get past it.  No matter what I do, I keep
> > running into version mismatch issue with libpam-modules.  It's preventing
> > the upgrade from finishing.
> 
> The other "incantation" that's worth trying is
> 
> # dpkg --configure -a

I would start by reinstating jessie in all of your sources
files, then try dpkg --configure -a, then apt-get -f install,
then apt-get dist-upgrade to jessie. After a successful jessie
reboot, upgrade to stretch.

-dsr-

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

#194734

On Thu 12 Apr 2018 at 06:42:33 (-0400), Dan Ritter wrote:
> On Wed, Apr 11, 2018 at 07:57:07PM -0500, David Wright wrote:
> > On Wed 11 Apr 2018 at 15:31:32 (-0400), David Parker wrote:
> > > I am trying to upgrade two test boxes from Wheezy to Stretch (skipping
> > > Jessie).  The upgrade worked on one of them, although I ran into errors and
> > > had to run "apt-get -f install" a few times, but that resolved the issues
> > > and it ultimately worked.
> > > 
> > > However, on the second box, I ran into an error about halfway through the
> > > upgrade, and I'm not able to get past it.  No matter what I do, I keep
> > > running into version mismatch issue with libpam-modules.  It's preventing
> > > the upgrade from finishing.
> > 
> > The other "incantation" that's worth trying is
> > 
> > # dpkg --configure -a

That's the short answer.

> I would start by reinstating jessie in all of your sources
> files, then try dpkg --configure -a, then apt-get -f install,
> then apt-get dist-upgrade to jessie. After a successful jessie
> reboot, upgrade to stretch.

dpkg --configure -a   and   apt-get -f install   can be useful
to fix a logjam, but when you get an error like
 E: Sub-process /usr/bin/dpkg returned an error code (1)
it's worth running dpkg directly, seeing which packages are stuck,
and then try   dpkg -i <all the affected package .deb filenames>
as this can sometimes fix circular and reciprocal dependencies
that running from apt* is unable to solve.

BTW if they're test boxes, keep on trying: you may learn something
useful about rescuing systems, which the reinstall people won't.

Cheers,
David.

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

#194861

[Multipart message — attachments visible in raw view] — view raw

Hi all,

Sorry I didn't get back to this sooner, had some crazy life stuff getting
in the way.

I should have said in my original post that there is a reason I'm trying to
jump from Wheezy to Stretch.  These boxes are in an HA cluster with
Pacemaker, Corosync, and DRBD.  I have all 3 of these installed from the
Debian packages.  Pacemaker is not in Jessie (apparently the devs missed
the deadline for inclusion), so an upgrade to Jessie uninstalls pacemaker
and all of its configuration.  That's what I was hoping to avoid, because
setting up an configuring Pacemaker always takes me a while to get right,
so an upgrade path which does not include the removal of it is preferable.

I did read the documentation and I did try Wheezy -> Jessie - > Stretch
first, but the problem was that Pacemaker was removed.  Hence, I was hoping
to skip Jessie.

If it's simply not possible to do this upgrade then I guess that's that.
I'll have to reinstall and reconfigure Pacemaker, which hopefully will
continue to be delivered in future releases without fail.

Thanks,
Dave

On Thu, Apr 12, 2018 at 2:35 PM, David Wright <deblis@lionunicorn.co.uk>
wrote:

> On Thu 12 Apr 2018 at 06:42:33 (-0400), Dan Ritter wrote:
> > On Wed, Apr 11, 2018 at 07:57:07PM -0500, David Wright wrote:
> > > On Wed 11 Apr 2018 at 15:31:32 (-0400), David Parker wrote:
> > > > I am trying to upgrade two test boxes from Wheezy to Stretch
> (skipping
> > > > Jessie).  The upgrade worked on one of them, although I ran into
> errors and
> > > > had to run "apt-get -f install" a few times, but that resolved the
> issues
> > > > and it ultimately worked.
> > > >
> > > > However, on the second box, I ran into an error about halfway
> through the
> > > > upgrade, and I'm not able to get past it.  No matter what I do, I
> keep
> > > > running into version mismatch issue with libpam-modules.  It's
> preventing
> > > > the upgrade from finishing.
> > >
> > > The other "incantation" that's worth trying is
> > >
> > > # dpkg --configure -a
>
> That's the short answer.
>
> > I would start by reinstating jessie in all of your sources
> > files, then try dpkg --configure -a, then apt-get -f install,
> > then apt-get dist-upgrade to jessie. After a successful jessie
> > reboot, upgrade to stretch.
>
> dpkg --configure -a   and   apt-get -f install   can be useful
> to fix a logjam, but when you get an error like
>  E: Sub-process /usr/bin/dpkg returned an error code (1)
> it's worth running dpkg directly, seeing which packages are stuck,
> and then try   dpkg -i <all the affected package .deb filenames>
> as this can sometimes fix circular and reciprocal dependencies
> that running from apt* is unable to solve.
>
> BTW if they're test boxes, keep on trying: you may learn something
> useful about rescuing systems, which the reinstall people won't.
>
> Cheers,
> David.
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

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

#194864

On Thu, Apr 19, 2018 at 10:57:09AM -0400, David Parker wrote:
> 
>    I did read the documentation and I did try Wheezy -> Jessie - > Stretch
>    first, but the problem was that Pacemaker was removed.  Hence, I was
>    hoping to skip Jessie.
>    If it's simply not possible to do this upgrade then I guess that's that. 
>    I'll have to reinstall and reconfigure Pacemaker, which hopefully will
>    continue to be delivered in future releases without fail.

It is likely that you would have received different, and perhaps more
constructive responses, had you included this detail in the initial
description. However, that is in the past.

That said, it should be possible to upgrade without pacemaker and other
packages which are important to you being removed. The only thing that
would *force* the removal would be if one the dependencies was no longer
satisified. None of the first-order dependencies of any of the pacemaker
packages have versions specified with < (i.e., a maximum version on the
dependency), so in general I would say that what you are describing is
unexpected. Of course, there are lots of dependencies and those
dependencies all have dependencies of their own. It is certainly
possible that somewhere further on down the chain a dependency is
getting marked for removal it is filtering up and causing the removal of
pacemaker.

So, some strategies that might enable you to get a wheezy -> jessie ->
stretch upgrade to work include:

 - remove pacemaker first (note: 'remove' and 'purge' have different
   meanings when it comes to apt, with 'remove' removing a package's
   executables and other static resources but preserving configurations
   and user-generated content, while 'purge' will also remove
   configuration files and user-generated content), proceed with
   upgrades, and re-install after the upgrades are complete
 - start the upgrade to jessie and get far enough along to identify the
   culprit(s) of the removal, then manually remove those with 'dpkg'
   using the '--no-force-depends' option; that will allow pacemaker to
   remain installed, though in a broken state, while the offending
   dependencies are removed, after which you can proceed with the
   upgrade and when you get to the jessie -> stretch step the new
   pacemaker should get pulled in and the new dependencies with it
   (note: this approach may require a fair amount of manual intervention
   at each step of the upgrade process)
 - backup your pacemaker configurations and user-generated files, let
   the upgrade process remove the packages, then restore everything
   after the upgrade is complete

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#194869

On Thu, Apr 19, 2018 at 11:18:43AM -0400, Roberto C. Sánchez wrote:
>  - backup your pacemaker configurations and user-generated files, let
>    the upgrade process remove the packages, then restore everything
>    after the upgrade is complete

I'm still stumped by the claim that the configuration is being removed
during the wheezy->jessie upgrade.  Removing a pacakge during an
upgrade SHOULD NOT remove the configuration (i.e. it should be a
"remove" rather than a "purge").

So, the "obvious" answer would seem to be "upgrade to jessie, then
upgrade to stretch, then reinstall the pacemaker package, and it should
still see the old configs".  Of course this is assuming the old
configs are compatible with the new version of the package.  I know
absolutely nothing about this specific package.

According to http://packages.debian.org/pacemaker there is also a
backport of the stretch version of the package in the jessie-backports
repository.  So perhaps there is some way to convince the jessie upgrade
to use the jessie-backports version of this package rather than removing
it.  But that's beyond my experience.

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

#194871

On Thu, Apr 19, 2018 at 11:26:20AM -0400, Greg Wooledge wrote:
> 
> According to http://packages.debian.org/pacemaker there is also a
> backport of the stretch version of the package in the jessie-backports
> repository.  So perhaps there is some way to convince the jessie upgrade
> to use the jessie-backports version of this package rather than removing
> it.  But that's beyond my experience.
> 

I totally forgot about backports. Generally, including backports
repositories of the upgrade target (i.e., the suite being upgraded to)
is not a good idea. However, this situation would qualify as extenuating
circumstances. Plus, someone who manages a HA cluster almost certainly
has the skills to deal with the occasional minor hiccup assocaited with
mixing backports into an upgrade.

The only thing I would say is use apt "pinning" to prioritize the
backports repository lower than the other repositories so you don't
accidentally get backports for *everything* that has a backport
available.

Regards,

-Roberto
-- 
Roberto C. Sánchez

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

#194872

[Multipart message — attachments visible in raw view] — view raw

I never thought to use the backports repo in Jessie to keep pacemaker
installed.  That's a great idea, I'll give it a try and see what happens.

Regarding Pacemaker's data and config, as far as I could tell, it was
gone.  I'm not positive what happened with it, but I wonder if the fact
that the pacemaker package was missing entirely from the new release caused
apt to just get rid of it during the upgrade.  I can also re-try that and
keep closer track of what gets removed.  I do know that when I upgraded
from Wheezy to Jessie and then to Stretch, and then I re-installed
Pacemaker in Stretch, it didn't find any old config data and acted like a
new installation.

Thanks!
Dave

On Thu, Apr 19, 2018 at 11:32 AM, Roberto C. Sánchez <roberto@debian.org>
wrote:

> On Thu, Apr 19, 2018 at 11:26:20AM -0400, Greg Wooledge wrote:
> >
> > According to http://packages.debian.org/pacemaker there is also a
> > backport of the stretch version of the package in the jessie-backports
> > repository.  So perhaps there is some way to convince the jessie upgrade
> > to use the jessie-backports version of this package rather than removing
> > it.  But that's beyond my experience.
> >
>
> I totally forgot about backports. Generally, including backports
> repositories of the upgrade target (i.e., the suite being upgraded to)
> is not a good idea. However, this situation would qualify as extenuating
> circumstances. Plus, someone who manages a HA cluster almost certainly
> has the skills to deal with the occasional minor hiccup assocaited with
> mixing backports into an upgrade.
>
> The only thing I would say is use apt "pinning" to prioritize the
> backports repository lower than the other repositories so you don't
> accidentally get backports for *everything* that has a backport
> available.
>
> Regards,
>
> -Roberto
> --
> Roberto C. Sánchez
>
>


-- 
Dave Parker '11
Database & Systems Administrator
Utica College
Integrated Information Technology Services
(315) 792-3229
Registered Linux User #408177

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

#194881

On Thu, Apr 19, 2018 at 11:45:11AM -0400, David Parker wrote:
>    I'm not positive what happened with it, but I wonder if the fact
>    that the pacemaker package was missing entirely from the new release
>    caused apt to just get rid of it during the upgrade.

Neither of the package front-ends that I have used (apt-get and
aptitude) do what you describe. In fact, on every system I have upgraded
I end up with a section called 'Obsolete and Locally Created Packages'
visible in aptitude. In the case of an upgrade, that section has
packages that are installed on the system but which no longer have an
available candidate from any of the available sources. Removal of a
package as part of a dist-upgrade only happens if its dependencies can
no longer be met.

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

#194884

On Thursday 19 April 2018 11:32:28 Roberto C. Sánchez wrote:

> On Thu, Apr 19, 2018 at 11:26:20AM -0400, Greg Wooledge wrote:
> > According to http://packages.debian.org/pacemaker there is also a
> > backport of the stretch version of the package in the
> > jessie-backports repository.  So perhaps there is some way to
> > convince the jessie upgrade to use the jessie-backports version of
> > this package rather than removing it.  But that's beyond my
> > experience.
>
> I totally forgot about backports. Generally, including backports
> repositories of the upgrade target (i.e., the suite being upgraded to)
> is not a good idea. However, this situation would qualify as
> extenuating circumstances. Plus, someone who manages a HA cluster
> almost certainly has the skills to deal with the occasional minor
> hiccup assocaited with mixing backports into an upgrade.
>
> The only thing I would say is use apt "pinning" to prioritize the
> backports repository lower than the other repositories so you don't
> accidentally get backports for *everything* that has a backport
> available.
>
> Regards,
>
> -Roberto

Hijacking a thread here, but it reads like I might be reading an expert.

"Pinning" is an interesting subject Roberto, interesting because the info 
on how to do it is generally skipped over, or only mentioned in passing, 
with NO examples of how to do it in the man pages available. I have it 
working on one machine, but it was a heck of a trip getting there, and I 
still have had no confirmation that I actually did it correctly. That 
machine is a raspi-3b running jessie. But with an rt-preempt kernel 
because its main reason-de-terre is LinuxCNC.  Its running a 3/4 ton 
metal working lathe.

In /etc/apt/preferences.d/kernel.pref:
pi@picnc:/etc/apt/preferences.d $ cat kernel.pref
Package:linux-kernel
pin: version 4.4.4-rt9-v7+
Pin-Priority: 1001

Package: linux-headers
Pin: version 4.4.4-rt9-v7+
Pin-Priority: 1001

Package: raspberrypi-bootloader
Pin: version 1.20170427-1
Pin-Priority: 1001

Package: raspberrypi-kernel
Pin: version 1.20170427-1
Pin-Priority: 1001

Is this the approved method? All I know is that for me, its working, and 
anything related to a kernel update is skipped.

Thanks for any further insight.

-- 
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]

#194885 — Re: Pinning (was Re: Error while upgrading from Wheezy to Stretch)

On Thu, Apr 19, 2018 at 02:47:05PM -0400, Gene Heskett wrote:
> Hijacking a thread here, but it reads like I might be reading an expert.
> 
> "Pinning" is an interesting subject Roberto, interesting because the info 
> on how to do it is generally skipped over, or only mentioned in passing, 
> with NO examples of how to do it in the man pages available.

For backports, the <https://backports.debian.org/Instructions/>
say:

  All backports are deactivated by default (i.e. the packages are pinned
  to 100 by using ButAutomaticUpgrades: yes in the Release files.

Beyond that, pinning is strongly discouraged in the IRC channel.  The
channel's bot says:

  Bugs are explained at
  https://web.archive.org/web/20121017070250/http://carlo17.home.xs4all.nl/howto/debian.html#errata

I don't know why the page was removed, forcing the archive retrieval.
But there you have it.

Usually a user's attempt to do pinning is one of the steps leading to
what we call a "frankendebian" system, which is completely broken and
unfixable.  Hence, the strong discouragement against using it.

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

#194888 — Re: Pinning (was Re: Error while upgrading from Wheezy to Stretch)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 19, 2018 at 02:59:04PM -0400, Greg Wooledge wrote:
> On Thu, Apr 19, 2018 at 02:47:05PM -0400, Gene Heskett wrote:
> > Hijacking a thread here, but it reads like I might be reading an expert.
> > 
> > "Pinning" is an interesting subject Roberto, interesting because the info 
> > on how to do it is generally skipped over, or only mentioned in passing, 
> > with NO examples of how to do it in the man pages available.
> 
> For backports, the <https://backports.debian.org/Instructions/>
> say:
> 
>   All backports are deactivated by default (i.e. the packages are pinned
>   to 100 by using ButAutomaticUpgrades: yes in the Release files.
> 
> Beyond that, pinning is strongly discouraged in the IRC channel.  The
> channel's bot says:
> 
>   Bugs are explained at
>   https://web.archive.org/web/20121017070250/http://carlo17.home.xs4all.nl/howto/debian.html#errata
> 
> I don't know why the page was removed, forcing the archive retrieval.
> But there you have it.
> 
> Usually a user's attempt to do pinning is one of the steps leading to
> what we call a "frankendebian" system, which is completely broken and
> unfixable.  Hence, the strong discouragement against using it.

Know what you're doing :-)

In general, pinning is a way to have packages from a later distro
without getting everything upgraded.

That said, if you pull in anything which wants a newer libc,
for example, you're going to have fun :-)

Pulling in some new kernels. as Gene is doing looks (more or
less) harmless... as long as the libc plays along.

In general, I'd say: if you are running stable, pinning is
almost always a bad idea. If you are running testing, there
are more reasons for it.

But be prepared to second-guess your installer and to understand
why it wants to take decisions the way it wants.

FWIW, I've been running a Frankendebian (testing/unstable) for well
over two years. It's OK, but, just for one example, I couldn't run
aptitude, because its dependency resolver became hopelessly confused
and always wanted to deinstall half of my system (apt was mostly
fine, though). Be prepared to deal with such things.

Two references to skim (a bit oldish, but AFAIK still relevant):

  This one has examples for pinning:
  https://wiki.debian.org/AptPreferences#Pinning

  This one talks about the kind of problems you might get
  https://lists.debian.org/debian-devel/2003/01/msg01644.html

Cheers & take care
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrY7fwACgkQBcgs9XrR2kZa5ACcD+nvKLVnnfRI+x/y0EgzVMx8
/7kAn1nNUQSUNBK7QLYSKbSdsULhS1J4
=QQ5P
-----END PGP SIGNATURE-----

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

#194889 — Re: Pinning (was Re: Error while upgrading from Wheezy to Stretch)

On Thursday 19 April 2018 14:59:04 Greg Wooledge wrote:

> On Thu, Apr 19, 2018 at 02:47:05PM -0400, Gene Heskett wrote:
> > Hijacking a thread here, but it reads like I might be reading an
> > expert.
> >
> > "Pinning" is an interesting subject Roberto, interesting because the
> > info on how to do it is generally skipped over, or only mentioned in
> > passing, with NO examples of how to do it in the man pages
> > available.
>
> For backports, the <https://backports.debian.org/Instructions/>
> say:
>
>   All backports are deactivated by default (i.e. the packages are
> pinned to 100 by using ButAutomaticUpgrades: yes in the Release files.
>
> Beyond that, pinning is strongly discouraged in the IRC channel.  The
> channel's bot says:
>
>   Bugs are explained at
>  
> https://web.archive.org/web/20121017070250/http://carlo17.home.xs4all.
>nl/howto/debian.html#errata
>
> I don't know why the page was removed, forcing the archive retrieval.
> But there you have it.
>
> Usually a user's attempt to do pinning is one of the steps leading to
> what we call a "frankendebian" system, which is completely broken and
> unfixable.  Hence, the strong discouragement against using it.

I realize that Greg, but debian's support for armhf for unusual 
applications that require a realtime environment, is at its finest, an 
afterthought and discarded. We linuxcnc runners are used to it.  So we 
build our own kernels and pin them.

And so far, jessies apt has not issued a complaint other than advising me 
when a kernel update has been skipped.

Stretch on armhf, or arm64 (pine64/rock64) from the pine sites offerings 
is a disaster with sub 24 hour uptimes, so I am stuck on jessie, whose 
uptimes running this particular machine are from power bump to power 
bump. With a battery backup, which it doesn't have, uptimes would be 
essentially for the life of the battery. A superCap might even do it as 
I have a 20 kw auto starting standby here, power outages are about 5 
seconds.

Funny part is that I have built, on the rock64 using its own arm64 
compiler tools, one of the latest linux-rt kernels from that linux-rt 
mailing list, on the rock64, takes around an hour, but I can't get the 
pine people to tell me how to install it. I'd give you its version, but 
the rock64 is currently not online. Its running I think, but no one is 
logged in from its own keyboard. Some security minded person, in his 
infinite wisdom, has decreed that the networking will not be started 
until a user is logged in from its own keyboard. But howinhell can an 
ssh login be done over the cable when the networking has to be started 
by that same user which starts x too, me, going out and convincing the 
monitor to stay on the rocks cable long enough so I can login from its 
own keyboard. Classic chicken v egg no one gave any consideration to.  

How do I fix that for starters?

-- 
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]

#194891 — Re: Pinning (was Re: Error while upgrading from Wheezy to Stretch)

On Thu, Apr 19, 2018 at 03:46:17PM -0400, Gene Heskett wrote:
> I realize that Greg, but debian's support for armhf for unusual 
> applications that require a realtime environment, is at its finest, an 
> afterthought and discarded. We linuxcnc runners are used to it.  So we 
> build our own kernels and pin them.

Kernels are among the safest packages you can bring in from a foreign
release.  They have almost no dependencies at all.  Just a magic hamster
that makes the system go.

Of course, you're still on your own if the hamster falls out of the cage.

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

#194887

On Thu, Apr 19, 2018 at 02:47:05PM -0400, Gene Heskett wrote:
> On Thursday 19 April 2018 11:32:28 Roberto C. Sánchez wrote:
> 
> > The only thing I would say is use apt "pinning" to prioritize the
> > backports repository lower than the other repositories so you don't
> > accidentally get backports for *everything* that has a backport
> > available.
> >
> 
> Hijacking a thread here, but it reads like I might be reading an expert.
> 
> "Pinning" is an interesting subject Roberto, interesting because the info 
> on how to do it is generally skipped over, or only mentioned in passing, 
> with NO examples of how to do it in the man pages available. I have it 
> working on one machine, but it was a heck of a trip getting there, and I 
> still have had no confirmation that I actually did it correctly. That 
> machine is a raspi-3b running jessie. But with an rt-preempt kernel 
> because its main reason-de-terre is LinuxCNC.  Its running a 3/4 ton 
> metal working lathe.
> 
> In /etc/apt/preferences.d/kernel.pref:
> pi@picnc:/etc/apt/preferences.d $ cat kernel.pref
> Package:linux-kernel
> pin: version 4.4.4-rt9-v7+
> Pin-Priority: 1001
> 
> Package: linux-headers
> Pin: version 4.4.4-rt9-v7+
> Pin-Priority: 1001
> 
> Package: raspberrypi-bootloader
> Pin: version 1.20170427-1
> Pin-Priority: 1001
> 
> Package: raspberrypi-kernel
> Pin: version 1.20170427-1
> Pin-Priority: 1001
> 
> Is this the approved method? All I know is that for me, its working, and 
> anything related to a kernel update is skipped.

Indiscriminate pinning is terrible. That's because it's a
powerful tool. 1001 is almost certainly not what you really
want to do here if you are regularly updating your system. And
if you are not updating your system at all, you don't need 
to apt-pin.

Here's a quick guide that I wrote some time ago:

---

Let us suppose that you are running Debian stable, but there are
some packages that you would like from the backports archive.
However, you don’t want all backports replacements to be brought
in.

In etc/apt/sources.list.d/backposts.list add the backports repo.
As I write this, Jessie is stable, so:

deb http://http.debian.net/debian jessie-backports main contrib
non-free

Note that the source lists must end with .list or they will be
ignored.

In etc/apt/preferences.d/priorities:

Package: *
Pin: release a=jessie
Pin-Priority: 900

Package: *
Pin: release a=jessie-backports
Pin-Priority: 50

and run apt-get update

There are magic levels for the numbers in the priority field.
They are explained, at length, in man apt_preferences. The
highlights:

    P >= 1000 causes a version to be installed even if this
constitutes a downgrade of the package

    990 <= P < 1000 causes a version to be installed even if it
does not come from the target release, unless the installed
version is more recent

    500 <= P < 990 causes a version to be installed unless there
is a version available belonging to the target release or the
installed version is more recent

    100 <= P < 500 causes a version to be installed unless there
is a version available belonging to some other distribution or
the installed version is more recent

    0 < P < 100 causes a version to be installed only if there
is no installed version of the package

    P < 0 prevents the version from being installed

Now, to install a single backported package, apt-get install
packagename/jessie-backports, and to install a backported
package plus any dependencies which are also backported, use
apt-get -t jessie-backports packagename

If jessie gets an update more recent than the backports version
you installed, it will be installed.

When you upgrade to the next stable version, remove the pinning
before the dist-upgrade, and consider if you need to reinstate
it.

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

#194892

On Thursday 19 April 2018 15:23:16 Dan Ritter wrote:

> On Thu, Apr 19, 2018 at 02:47:05PM -0400, Gene Heskett wrote:
> > On Thursday 19 April 2018 11:32:28 Roberto C. Sánchez wrote:
> > > The only thing I would say is use apt "pinning" to prioritize the
> > > backports repository lower than the other repositories so you
> > > don't accidentally get backports for *everything* that has a
> > > backport available.
> >
> > Hijacking a thread here, but it reads like I might be reading an
> > expert.
> >
> > "Pinning" is an interesting subject Roberto, interesting because the
> > info on how to do it is generally skipped over, or only mentioned in
> > passing, with NO examples of how to do it in the man pages
> > available. I have it working on one machine, but it was a heck of a
> > trip getting there, and I still have had no confirmation that I
> > actually did it correctly. That machine is a raspi-3b running
> > jessie. But with an rt-preempt kernel because its main
> > reason-de-terre is LinuxCNC.  Its running a 3/4 ton metal working
> > lathe.
> >
> > In /etc/apt/preferences.d/kernel.pref:
> > pi@picnc:/etc/apt/preferences.d $ cat kernel.pref
> > Package:linux-kernel
> > pin: version 4.4.4-rt9-v7+
> > Pin-Priority: 1001
> >
> > Package: linux-headers
> > Pin: version 4.4.4-rt9-v7+
> > Pin-Priority: 1001
> >
> > Package: raspberrypi-bootloader
> > Pin: version 1.20170427-1
> > Pin-Priority: 1001
> >
> > Package: raspberrypi-kernel
> > Pin: version 1.20170427-1
> > Pin-Priority: 1001
> >
> > Is this the approved method? All I know is that for me, its working,
> > and anything related to a kernel update is skipped.
>
> Indiscriminate pinning is terrible. That's because it's a
> powerful tool. 1001 is almost certainly not what you really
> want to do here if you are regularly updating your system. And
> if you are not updating your system at all, you don't need
> to apt-pin.
>
> Here's a quick guide that I wrote some time ago:
>
> ---
>
> Let us suppose that you are running Debian stable, but there are
> some packages that you would like from the backports archive.
> However, you don’t want all backports replacements to be brought
> in.
>
> In etc/apt/sources.list.d/backposts.list add the backports repo.
> As I write this, Jessie is stable, so:
>
> deb http://http.debian.net/debian jessie-backports main contrib
> non-free
>
> Note that the source lists must end with .list or they will be
> ignored.
>
> In etc/apt/preferences.d/priorities:
>
> Package: *
> Pin: release a=jessie
> Pin-Priority: 900
>
> Package: *
> Pin: release a=jessie-backports
> Pin-Priority: 50
>
> and run apt-get update
>
> There are magic levels for the numbers in the priority field.
> They are explained, at length, in man apt_preferences. The
> highlights:
>
>     P >= 1000 causes a version to be installed even if this
> constitutes a downgrade of the package
>
>     990 <= P < 1000 causes a version to be installed even if it
> does not come from the target release, unless the installed
> version is more recent
>
>     500 <= P < 990 causes a version to be installed unless there
> is a version available belonging to the target release or the
> installed version is more recent
>
>     100 <= P < 500 causes a version to be installed unless there
> is a version available belonging to some other distribution or
> the installed version is more recent
>
>     0 < P < 100 causes a version to be installed only if there
> is no installed version of the package
>
>     P < 0 prevents the version from being installed
>
> Now, to install a single backported package, apt-get install
> packagename/jessie-backports, and to install a backported
> package plus any dependencies which are also backported, use
> apt-get -t jessie-backports packagename
>
> If jessie gets an update more recent than the backports version
> you installed, it will be installed.
>
> When you upgrade to the next stable version, remove the pinning
> before the dist-upgrade, and consider if you need to reinstate
> it.

Upgradeing to the next stable on arm's in general will likely be done by 
installing the system on a u-sd card with dd, from an image built by the 
linuxcnc people, and will continue to be until such time as debian also 
supports the rt kernel flavors, which isn't even done for the *86 stuff. 
Building that image is a major project, which is why our *86 machines 
are still running wheezy. Might have 10 jessie installs, all but mine on 
*86 machines. Not debians fault, nor am I blaming debian, its a lack of 
manpower and interest for an app thats a niche with a few thousand 
machines/users. More if you count the machines each user has, 4 for me 
and I'm just a hobbiest. But its the goto software when folks get tired 
of mach, or the proprietary stuff dies and the vendor has disappeared 
but the machine is still mechanically good, so it controls get 
converted. And often surprises the people with how much faster the 
machine is. It (we think) is whats makeing the Toyota racing engine for 
instance. Or was, we think toy pulled down a youtube video of that some 
time back. Running a multi axis machining center worth around $250k.

-- 
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]

#194894

On Thu, Apr 19, 2018 at 02:47:05PM -0400, Gene Heskett wrote:
> 
> "Pinning" is an interesting subject Roberto, interesting because the info 
> on how to do it is generally skipped over, or only mentioned in passing, 
> with NO examples of how to do it in the man pages available. I have it 
> working on one machine, but it was a heck of a trip getting there, and I 
> still have had no confirmation that I actually did it correctly.

I apologize for not providing a reference. I recommend starting here:
https://wiki.debian.org/AptPreferences

Regards,

-Roberto

-- 
Roberto C. Sánchez

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web