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

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

Need to upgrade to jessie need help

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

Contents

  Need to upgrade to jessie need help VigneshDhanraj G <vigneshdhanraj.g@gmail.com> - 2017-07-25 08:40 +0200
    Re: Need to upgrade to jessie need help Dejan Jocic <jodejka@gmail.com> - 2017-07-25 09:50 +0200
      Re: Need to upgrade to jessie need help VigneshDhanraj G <vigneshdhanraj.g@gmail.com> - 2017-07-25 09:50 +0200
      Re: Need to upgrade to jessie need help Greg Wooledge <wooledg@eeg.ccf.org> - 2017-07-25 14:00 +0200
        Re: Need to upgrade to jessie need help Dejan Jocic <jodejka@gmail.com> - 2017-07-25 15:00 +0200
          Re: Need to upgrade to jessie need help Cindy-Sue Causey <butterflybytes@gmail.com> - 2017-07-25 15:30 +0200
            Re: Need to upgrade to jessie need help Dejan Jocic <jodejka@gmail.com> - 2017-07-25 15:40 +0200
              Re: Need to upgrade to jessie need help Cindy-Sue Causey <butterflybytes@gmail.com> - 2017-07-25 16:00 +0200
                Re: Need to upgrade to jessie need help Dejan Jocic <jodejka@gmail.com> - 2017-07-25 16:10 +0200
                Re: Need to upgrade to jessie need help Greg Wooledge <wooledg@eeg.ccf.org> - 2017-07-25 16:10 +0200
                  Re: Need to upgrade to jessie need help Dejan Jocic <jodejka@gmail.com> - 2017-07-25 16:20 +0200
                    Re: Need to upgrade to jessie need help David Wright <deblis@lionunicorn.co.uk> - 2017-07-27 17:50 +0200
                      Re: Need to upgrade to jessie need help Dejan Jocic <jodejka@gmail.com> - 2017-07-28 17:50 +0200
                        Re: Need to upgrade to jessie need help Greg Wooledge <wooledg@eeg.ccf.org> - 2017-07-28 18:10 +0200
                          Re: Need to upgrade to jessie need help Dejan Jocic <jodejka@gmail.com> - 2017-07-28 18:20 +0200
                          Re: Need to upgrade to jessie need help Mark Fletcher <mark27q1@gmail.com> - 2017-07-29 17:30 +0200
                  Re: Need to upgrade to jessie need help Brian <ad44@cityscape.co.uk> - 2017-07-25 20:50 +0200
                    Re: Need to upgrade to jessie need help Greg Wooledge <wooledg@eeg.ccf.org> - 2017-07-25 21:00 +0200
                  Re: Need to upgrade to jessie need help Gene Heskett <gheskett@shentel.net> - 2017-07-26 02:40 +0200
    Re: Need to upgrade to jessie need help Georgi Naplatanov <gosho@oles.biz> - 2017-07-25 10:30 +0200
    Re: Need to upgrade to jessie need help Patrick Bartek <nemommxiv@gmail.com> - 2017-07-25 16:10 +0200
      Re: Need to upgrade to jessie need help Brian <ad44@cityscape.co.uk> - 2017-07-25 21:10 +0200
        Re: Need to upgrade to jessie need help Patrick Bartek <nemommxiv@gmail.com> - 2017-07-26 01:20 +0200
          Re: Need to upgrade to jessie need help Brian <ad44@cityscape.co.uk> - 2017-07-26 01:30 +0200
            Re: Need to upgrade to jessie need help Patrick Bartek <nemommxiv@gmail.com> - 2017-07-26 06:00 +0200
              Re: Need to upgrade to jessie need help David Wright <deblis@lionunicorn.co.uk> - 2017-07-27 18:50 +0200
            Re: Need to upgrade to jessie need help Greg Wooledge <wooledg@eeg.ccf.org> - 2017-07-26 14:30 +0200
              Re: Need to upgrade to jessie need help Brian <ad44@cityscape.co.uk> - 2017-07-26 15:10 +0200
    Re: Need to upgrade to jessie need help David Christensen <dpchrist@holgerdanske.com> - 2017-07-26 02:30 +0200

Page 1 of 2  [1] 2  Next page →

#184197 — Need to upgrade to jessie need help

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

Hi Team,

I am using kernel 3.2.x, i know that support from wheezy will be stopped
soon. can i upgrade to jessie with same kernel version.

Is that correct way of handling?

Regards,
VigneshDhanraj G

[toc] | [next] | [standalone]

#184199

On 25-07-17, VigneshDhanraj G wrote:
> Hi Team,
> 
> I am using kernel 3.2.x, i know that support from wheezy will be stopped
> soon. can i upgrade to jessie with same kernel version.
> 
> Is that correct way of handling?
> 
> Regards,
> VigneshDhanraj G

When you upgrade to Jessie, it will install new kernel automatically.
However, it should not remove your Wheezy kernel, because upgrading
kernels always leaves one old one there, in case that you can not boot
into your new kernel for some reason. You can then mark that kernel via
grub options as one you would like to boot in. You can do it during boot
in grub, or by setting it as default in /etc/default/grub. You will also
have to use apt-mark to put that kernel on hold, to prevent removing it
on future updates, or to do some apt pinning. But, since Wheezy will be
out of support soon, doubt that you will be able to expect security
updates for that kernel. It would be wise to check if newer kernel works
for you, and if it does to move to it completely and forget about Wheezy
kernel.

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

#184200

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

Thanks Dejan Jocic. Let me try and get back to you.

On Tue, Jul 25, 2017 at 1:11 PM, Dejan Jocic <jodejka@gmail.com> wrote:

> On 25-07-17, VigneshDhanraj G wrote:
> > Hi Team,
> >
> > I am using kernel 3.2.x, i know that support from wheezy will be stopped
> > soon. can i upgrade to jessie with same kernel version.
> >
> > Is that correct way of handling?
> >
> > Regards,
> > VigneshDhanraj G
>
> When you upgrade to Jessie, it will install new kernel automatically.
> However, it should not remove your Wheezy kernel, because upgrading
> kernels always leaves one old one there, in case that you can not boot
> into your new kernel for some reason. You can then mark that kernel via
> grub options as one you would like to boot in. You can do it during boot
> in grub, or by setting it as default in /etc/default/grub. You will also
> have to use apt-mark to put that kernel on hold, to prevent removing it
> on future updates, or to do some apt pinning. But, since Wheezy will be
> out of support soon, doubt that you will be able to expect security
> updates for that kernel. It would be wise to check if newer kernel works
> for you, and if it does to move to it completely and forget about Wheezy
> kernel.
>
>
>
>

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

#184209

On Tue, Jul 25, 2017 at 09:41:24AM +0200, Dejan Jocic wrote:
> When you upgrade to Jessie, it will install new kernel automatically.
> However, it should not remove your Wheezy kernel, because upgrading
> kernels always leaves one old one there, in case that you can not boot
> into your new kernel for some reason. You can then mark that kernel via
> grub options as one you would like to boot in. You can do it during boot
> in grub, or by setting it as default in /etc/default/grub.

All true.

> You will also
> have to use apt-mark to put that kernel on hold, to prevent removing it
> on future updates, or to do some apt pinning.

False.  The kernel will simply sit there forever, unless you take some
explicit action to remove it.  No holds or pinning or other wrestling
required.

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

#184211

On 25-07-17, Greg Wooledge wrote:
> On Tue, Jul 25, 2017 at 09:41:24AM +0200, Dejan Jocic wrote:
> > When you upgrade to Jessie, it will install new kernel automatically.
> > However, it should not remove your Wheezy kernel, because upgrading
> > kernels always leaves one old one there, in case that you can not boot
> > into your new kernel for some reason. You can then mark that kernel via
> > grub options as one you would like to boot in. You can do it during boot
> > in grub, or by setting it as default in /etc/default/grub.
> 
> All true.
> 
> > You will also
> > have to use apt-mark to put that kernel on hold, to prevent removing it
> > on future updates, or to do some apt pinning.
> 
> False.  The kernel will simply sit there forever, unless you take some
> explicit action to remove it.  No holds or pinning or other wrestling
> required.
> 

That is not true, if you use autoremove. Only 2 last kernels will be
kept. This is upgrade from Jessie here. I have 4.9.0.2 and 4.9.0.3
kernels. Jessie kernel is long gone with autoremove.

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

#184213

On 7/25/17, Dejan Jocic <jodejka@gmail.com> wrote:
> On 25-07-17, Greg Wooledge wrote:
>> On Tue, Jul 25, 2017 at 09:41:24AM +0200, Dejan Jocic wrote:
>> > When you upgrade to Jessie, it will install new kernel automatically.
>> > However, it should not remove your Wheezy kernel, because upgrading
>> > kernels always leaves one old one there, in case that you can not boot
>> > into your new kernel for some reason. You can then mark that kernel via
>> > grub options as one you would like to boot in. You can do it during
>> > boot
>> > in grub, or by setting it as default in /etc/default/grub.
>>
>> All true.
>>
>> > You will also
>> > have to use apt-mark to put that kernel on hold, to prevent removing it
>> > on future updates, or to do some apt pinning.
>>
>> False.  The kernel will simply sit there forever, unless you take some
>> explicit action to remove it.  No holds or pinning or other wrestling
>> required.
>>
>
> That is not true, if you use autoremove. Only 2 last kernels will be
> kept. This is upgrade from Jessie here. I have 4.9.0.2 and 4.9.0.3
> kernels. Jessie kernel is long gone with autoremove.


Well, that's a little... scary. *frown*

Except that... I just deleted the rest of what I first wrote because
it hit me. Autoremove is what apt-get tells me to use to remove
packages..... that are no longer needed.... that are no longer
"dependencies". What it actually tells *me* is something like "apt
autoremove" (not "apt-get autoremove").

Aaaahhhh... So in autoremove's mind... It might touch on that previous
kernel and say... hm, nothing's using it now, nothing needs it to
function properly, so trash it........

Or something like that.... there...... :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

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

#184216

On 25-07-17, Cindy-Sue Causey wrote:
> On 7/25/17, Dejan Jocic <jodejka@gmail.com> wrote:
> > On 25-07-17, Greg Wooledge wrote:
> >> On Tue, Jul 25, 2017 at 09:41:24AM +0200, Dejan Jocic wrote:
> >> > When you upgrade to Jessie, it will install new kernel automatically.
> >> > However, it should not remove your Wheezy kernel, because upgrading
> >> > kernels always leaves one old one there, in case that you can not boot
> >> > into your new kernel for some reason. You can then mark that kernel via
> >> > grub options as one you would like to boot in. You can do it during
> >> > boot
> >> > in grub, or by setting it as default in /etc/default/grub.
> >>
> >> All true.
> >>
> >> > You will also
> >> > have to use apt-mark to put that kernel on hold, to prevent removing it
> >> > on future updates, or to do some apt pinning.
> >>
> >> False.  The kernel will simply sit there forever, unless you take some
> >> explicit action to remove it.  No holds or pinning or other wrestling
> >> required.
> >>
> >
> > That is not true, if you use autoremove. Only 2 last kernels will be
> > kept. This is upgrade from Jessie here. I have 4.9.0.2 and 4.9.0.3
> > kernels. Jessie kernel is long gone with autoremove.
> 
> 
> Well, that's a little... scary. *frown*
> 
> Except that... I just deleted the rest of what I first wrote because
> it hit me. Autoremove is what apt-get tells me to use to remove
> packages..... that are no longer needed.... that are no longer
> "dependencies". What it actually tells *me* is something like "apt
> autoremove" (not "apt-get autoremove").
> 
> Aaaahhhh... So in autoremove's mind... It might touch on that previous
> kernel and say... hm, nothing's using it now, nothing needs it to
> function properly, so trash it........
> 
> Or something like that.... there...... :)
> 
> Cindy :)
> -- 
> Cindy-Sue Causey
> Talking Rock, Pickens County, Georgia, USA
> 
> * runs with duct tape *
> 

What it touch is /etc/kernel/postinst.d/apt-auto-removal that generates
/etc/apt/apt.conf.d/01autoremove-kernels file. Those decide what kernels
to keep. And, in case of /etc/kernel/postinst.d/apt-auto-removal it is
clearly stated:

# Mark as not-for-autoremoval those kernel packages that are: - the
# currently booted version - the kernel version we've been called for -
# the latest kernel version (as determined by debian version number) -
# the second-latest kernel version
#
# In the common case this results in two kernels saved (booted into the
# second-latest kernel, we install the latest kernel in an upgrade), but
# can save up to four. Kernel refers here to a distinct release, which
# can potentially be installed in multiple flavours counting as one
# kernel.

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

#184217

On 7/25/17, Dejan Jocic <jodejka@gmail.com> wrote:
> On 25-07-17, Cindy-Sue Causey wrote:
>> On 7/25/17, Dejan Jocic <jodejka@gmail.com> wrote:
>> > On 25-07-17, Greg Wooledge wrote:
>> >> On Tue, Jul 25, 2017 at 09:41:24AM +0200, Dejan Jocic wrote:
>> >> > When you upgrade to Jessie, it will install new kernel
>> >> > automatically.
>> >> > However, it should not remove your Wheezy kernel, because upgrading
>> >> > kernels always leaves one old one there, in case that you can not
>> >> > boot
>> >> > into your new kernel for some reason. You can then mark that kernel
>> >> > via
>> >> > grub options as one you would like to boot in. You can do it during
>> >> > boot
>> >> > in grub, or by setting it as default in /etc/default/grub.
>> >>
>> >> All true.
>> >>
>> >> > You will also
>> >> > have to use apt-mark to put that kernel on hold, to prevent removing
>> >> > it
>> >> > on future updates, or to do some apt pinning.
>> >>
>> >> False.  The kernel will simply sit there forever, unless you take some
>> >> explicit action to remove it.  No holds or pinning or other wrestling
>> >> required.
>> >>
>> >
>> > That is not true, if you use autoremove. Only 2 last kernels will be
>> > kept. This is upgrade from Jessie here. I have 4.9.0.2 and 4.9.0.3
>> > kernels. Jessie kernel is long gone with autoremove.
>>
>>
>> Well, that's a little... scary. *frown*
>>
>> Except that... I just deleted the rest of what I first wrote because
>> it hit me. Autoremove is what apt-get tells me to use to remove
>> packages..... that are no longer needed.... that are no longer
>> "dependencies". What it actually tells *me* is something like "apt
>> autoremove" (not "apt-get autoremove").
>>
>> Aaaahhhh... So in autoremove's mind... It might touch on that previous
>> kernel and say... hm, nothing's using it now, nothing needs it to
>> function properly, so trash it........
>>
>> Or something like that.... there...... :)
>>
>> Cindy :)
>> --
>> Cindy-Sue Causey
>> Talking Rock, Pickens County, Georgia, USA
>>
>> * runs with duct tape *
>>
>
> What it touch is /etc/kernel/postinst.d/apt-auto-removal that generates
> /etc/apt/apt.conf.d/01autoremove-kernels file. Those decide what kernels
> to keep. And, in case of /etc/kernel/postinst.d/apt-auto-removal it is
> clearly stated:
>
> # Mark as not-for-autoremoval those kernel packages that are: - the
> # currently booted version - the kernel version we've been called for -
> # the latest kernel version (as determined by debian version number) -
> # the second-latest kernel version
> #
> # In the common case this results in two kernels saved (booted into the
> # second-latest kernel, we install the latest kernel in an upgrade), but
> # can save up to four. Kernel refers here to a distinct release, which
> # can potentially be installed in multiple flavours counting as one
> # kernel.


Ok, so this is where the OP, VigneshDhanraj, could pin their kernel if
they know the release number....... That's a-suming one can pin out of
numerical sequence...

The "deal" about it, the rationale that the toggle is buried there
would be that pinning, not pinning kernels versus "just" other
software would most likely matter most to someone who is tech savvy
enough to have that need. That person would know they need to go
digging for the toggle that helps preserve their tear stained kernel.
:)

Interesting to know. I JUST yesterday downloaded the .xz tar for
4.12.3 for purposes of self-education. The new tip learned from this
thread is perfectly timed and priceless. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

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

#184218

On 25-07-17, Cindy-Sue Causey wrote:
> 
> 
> Ok, so this is where the OP, VigneshDhanraj, could pin their kernel if
> they know the release number....... That's a-suming one can pin out of
> numerical sequence...

No, that script is for automatically marking for autoremoval no longer
needed kernels and keeping at least last 2. If he wants to pin it, it is
done as always at /etc/apt/preferences, or even better under some file
under /etc/apt/preferences.d/. Or he can simply use apt-mark to put it
on hold. If that is what he really want. In my opinion, it is better
just to give a shot to new kernel and keep old one just as long as he
needs to be sure that new one works. Besides, if he does not clean apt
archives in /var/cache/apt/archives, he will have there older kernels
that can be installed with dpkg.
> 
> The "deal" about it, the rationale that the toggle is buried there
> would be that pinning, not pinning kernels versus "just" other
> software would most likely matter most to someone who is tech savvy
> enough to have that need. That person would know they need to go
> digging for the toggle that helps preserve their tear stained kernel.
> :)
> 
> Interesting to know. I JUST yesterday downloaded the .xz tar for
> 4.12.3 for purposes of self-education. The new tip learned from this
> thread is perfectly timed and priceless. :)
> 
> Cindy :)
> -- 
> Cindy-Sue Causey
> Talking Rock, Pickens County, Georgia, USA
> 
> * runs with duct tape *
> 

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

#184220

Is there any way to permanently neuter apt-get autoremove, so that even
if something invokes it against my will, it will *never* remove anything?

And more, is there a way to get apt and apt-get to *stop* prompting me
to run it, and *stop* spamming me with a list of packages that it would
like me to remove?  (Maybe that's the same as the first question, maybe
not.)

My strategy so far has been "ignore the spam, and never willingly run
autoremove".  This mostly works, but I recently learned that tasksel
will apparently run an autoremove, without warning, whether I want it
to or not (<http://bugs.debian.org/868892>).

If autoremove will also remove *kernels*, which this thread seems to
indicate is the case, then my concerns just went up another notch.

I suppose one could manually mark each and every single installed
package as "manually installed", but you'd have to remember to repeat
this periodically, and it seems clumsy and inelegant compared to some
sort of master switch that can just tell autoremove to go die in a fire.

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

#184221

On 25-07-17, Greg Wooledge wrote:
> Is there any way to permanently neuter apt-get autoremove, so that even
> if something invokes it against my will, it will *never* remove anything?
> 
> And more, is there a way to get apt and apt-get to *stop* prompting me
> to run it, and *stop* spamming me with a list of packages that it would
> like me to remove?  (Maybe that's the same as the first question, maybe
> not.)
> 
> My strategy so far has been "ignore the spam, and never willingly run
> autoremove".  This mostly works, but I recently learned that tasksel
> will apparently run an autoremove, without warning, whether I want it
> to or not (<http://bugs.debian.org/868892>).
> 
> If autoremove will also remove *kernels*, which this thread seems to
> indicate is the case, then my concerns just went up another notch.
> 
> I suppose one could manually mark each and every single installed
> package as "manually installed", but you'd have to remember to repeat
> this periodically, and it seems clumsy and inelegant compared to some
> sort of master switch that can just tell autoremove to go die in a fire.
> 

Your fear from autoremove is silly. It will not remove anything you
really need and, if you stick to default settings, will keep all
packages it replaced in /var/cache/apt/archives, as far as I know. And
if you have some package that you really, really want to keep, you can
always pin it, or put it on hold with apt-mark. It is not spam, it is
keeping your system clean.

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

#184312

On Tue 25 Jul 2017 at 16:16:44 (+0200), Dejan Jocic wrote:
> On 25-07-17, Greg Wooledge wrote:
> > Is there any way to permanently neuter apt-get autoremove, so that even
> > if something invokes it against my will, it will *never* remove anything?
> > 
> > And more, is there a way to get apt and apt-get to *stop* prompting me
> > to run it, and *stop* spamming me with a list of packages that it would
> > like me to remove?  (Maybe that's the same as the first question, maybe
> > not.)
> > 
> > My strategy so far has been "ignore the spam, and never willingly run
> > autoremove".  This mostly works, but I recently learned that tasksel
> > will apparently run an autoremove, without warning, whether I want it
> > to or not (<http://bugs.debian.org/868892>).
> > 
> > If autoremove will also remove *kernels*, which this thread seems to
> > indicate is the case, then my concerns just went up another notch.
> > 
> > I suppose one could manually mark each and every single installed
> > package as "manually installed", but you'd have to remember to repeat
> > this periodically, and it seems clumsy and inelegant compared to some
> > sort of master switch that can just tell autoremove to go die in a fire.
> > 
> 
> Your fear from autoremove is silly. It

Please note that "it" is "they", viz: apt and apt-get, …

> will not remove anything you
> really need and, if you stick to default settings, 

… and that they have different defaults. What's more, apt's behaviour
may change between versions, so unqualified statements like this
should really be confirmed before being relied on.

> will keep all
> packages it replaced in /var/cache/apt/archives, as far as I know. And
> if you have some package that you really, really want to keep, you can
> always pin it, or put it on hold with apt-mark. It is not spam, it is
> keeping your system clean.

Cheers,
David.

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

#184357

On 27-07-17, David Wright wrote:
> On Tue 25 Jul 2017 at 16:16:44 (+0200), Dejan Jocic wrote:
> > On 25-07-17, Greg Wooledge wrote:
> > > Is there any way to permanently neuter apt-get autoremove, so that even
> > > if something invokes it against my will, it will *never* remove anything?
> > > 
> > > And more, is there a way to get apt and apt-get to *stop* prompting me
> > > to run it, and *stop* spamming me with a list of packages that it would
> > > like me to remove?  (Maybe that's the same as the first question, maybe
> > > not.)
> > > 
> > > My strategy so far has been "ignore the spam, and never willingly run
> > > autoremove".  This mostly works, but I recently learned that tasksel
> > > will apparently run an autoremove, without warning, whether I want it
> > > to or not (<http://bugs.debian.org/868892>).
> > > 
> > > If autoremove will also remove *kernels*, which this thread seems to
> > > indicate is the case, then my concerns just went up another notch.
> > > 
> > > I suppose one could manually mark each and every single installed
> > > package as "manually installed", but you'd have to remember to repeat
> > > this periodically, and it seems clumsy and inelegant compared to some
> > > sort of master switch that can just tell autoremove to go die in a fire.
> > > 
> > 
> > Your fear from autoremove is silly. It
> 
> Please note that "it" is "they", viz: apt and apt-get, …
> 

Sure it is they. Did any of those they ever removed something that you
needed with autoremove? Or they always remove just things that you do not
need any more, packages that are just sitting there doing nothing,
former dependencies that are not needed for anything?

> > will not remove anything you
> > really need and, if you stick to default settings, 
> 
> … and that they have different defaults. What's more, apt's behaviour
> may change between versions, so unqualified statements like this
> should really be confirmed before being relied on.
> 

So, same question as above, did and of those they messed up? Are there
opened bugs that autoremove from any of used tools in debian removes
packages it should not? And qualifications for that statement are years
of use of both apt-get and aptitude with autoremove following
update/upgrade. Never had any trouble with it.

> > will keep all
> > packages it replaced in /var/cache/apt/archives, as far as I know. And
> > if you have some package that you really, really want to keep, you can
> > always pin it, or put it on hold with apt-mark. It is not spam, it is
> > keeping your system clean.
> 
> Cheers,
> David.
> 

All best,
Dejan

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

#184359

On Fri, Jul 28, 2017 at 05:39:39PM +0200, Dejan Jocic wrote:
> So, same question as above, did and of those they messed up? Are there
> opened bugs that autoremove from any of used tools in debian removes
> packages it should not? And qualifications for that statement are years
> of use of both apt-get and aptitude with autoremove following
> update/upgrade. Never had any trouble with it.

The concern is that you may have used some shared library to compile a
third-party program which is installed in /usr/local or /opt, or anywhere
else that's outside of Debian's knowledge.  Debian would not know that
the library is still being used, and therefore might autoremove it.

The impact of this is directly proportional to how many things you
compile yourself, and how important those things are to you.

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

#184360

On 28-07-17, Greg Wooledge wrote:
> On Fri, Jul 28, 2017 at 05:39:39PM +0200, Dejan Jocic wrote:
> > So, same question as above, did and of those they messed up? Are there
> > opened bugs that autoremove from any of used tools in debian removes
> > packages it should not? And qualifications for that statement are years
> > of use of both apt-get and aptitude with autoremove following
> > update/upgrade. Never had any trouble with it.
> 
> The concern is that you may have used some shared library to compile a
> third-party program which is installed in /usr/local or /opt, or anywhere
> else that's outside of Debian's knowledge.  Debian would not know that
> the library is still being used, and therefore might autoremove it.
> 
> The impact of this is directly proportional to how many things you
> compile yourself, and how important those things are to you.
> 

If you manually installed shared library, did autoremove removed
it/proposed to removed it? Or, it was installed as dependency of some
other package that you removed? If former, it is bug. If later, you
should have mark it as manually installed, if your compiled software
depends on it.

Also, if you compile third party programs, there are ways to make debian
packages out of them and keep yourself and your preferred debian package
tool happy. Just saying.

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

#184402

On Fri, Jul 28, 2017 at 12:04:54PM -0400, Greg Wooledge wrote:
> 
> The concern is that you may have used some shared library to compile a
> third-party program which is installed in /usr/local or /opt, or anywhere
> else that's outside of Debian's knowledge.  Debian would not know that
> the library is still being used, and therefore might autoremove it.
> 
> The impact of this is directly proportional to how many things you
> compile yourself, and how important those things are to you.
> 
If you compiled a program yourself, you probably know what its runtime 
dependencies are. Just create a dummy debian package with the right 
dependencies (this is a simple two-step task with the "equivs" package 
installed). Install that package using dpkg -i <package file name> and 
now Debian knows you don't want those libraries removed. And then you 
can safely use apt autoremove to keep your system clean.

I'd emphasise that using equivs is *NOT* a big ton of work -- you can 
very quickly throw together a dummy package even with a decent sized 
list of dependencies, and decent instructions are only a google away...

One thing you might trip over -- when you come to install the dummy 
package representing your self-built software, if any of the 
dependencies are not already installed, dpkg -i will fail. Use the -f 
option to force it to install anyway, then follow up with apt install 
--fix-broken or aptitude install or whatever to get it to fix the broken 
dependencies (by installing the missing dependencies, and recognising 
they are required for the dummy package you installed representing your 
self-built software).

Later, probably *much* later, you might get upgrade problems where the 
system wants to upgrade those libraries but can't because of the 
dependcies from your dummy package. The response to that should probably 
be to recognise that the self-built software may need re-building 
against the upgraded libraries, to do which you would remove the dummy 
package, let the upgrade happen, rebuild the self-built package, and 
then use equivs again to make a new dummy package. The kind of scenario 
I have in mind here is one where library upgrades change library package 
names -- I seem to recall fun a while back with with gnome libraries 
around the time of the upgrade from Gnome 2 to Gnome 3 (Wheezy to 
Jessie? Or was it earlier?) that had to do with this. The symptom was an 
attempt to upgrade wanting to remove half the system... At the time I 
wasn't much of a ninja with apt dependencies, but once I figured out the 
cause, the solution in that case was just marking libraries as 
auto-installed that were marked as non-auto and which nothing depended 
on. That is a different problem but produces a very similar effect to a 
dummy package depending on libraries whose package names change with an 
upgrade.

I suspect you, Greg, already know a lot of this, but nonetheless 
hopefully this will be useful for the archives.

Mark

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

#184232

On Tue 25 Jul 2017 at 10:02:50 -0400, Greg Wooledge wrote:

> Is there any way to permanently neuter apt-get autoremove, so that even
> if something invokes it against my will, it will *never* remove anything?
> 
> And more, is there a way to get apt and apt-get to *stop* prompting me
> to run it, and *stop* spamming me with a list of packages that it would
> like me to remove?  (Maybe that's the same as the first question, maybe
> not.)
> 
> My strategy so far has been "ignore the spam, and never willingly run
> autoremove".  This mostly works, but I recently learned that tasksel
> will apparently run an autoremove, without warning, whether I want it
> to or not (<http://bugs.debian.org/868892>).
> 
> If autoremove will also remove *kernels*, which this thread seems to
> indicate is the case, then my concerns just went up another notch.
> 
> I suppose one could manually mark each and every single installed
> package as "manually installed", but you'd have to remember to repeat
> this periodically, and it seems clumsy and inelegant compared to some
> sort of master switch that can just tell autoremove to go die in a fire.

/usr/share/doc/apt/examples/configure-index.gz has

     AutomaticRemove "false";       
     HideAutoRemove "false";

as configuration directives. I've never tried them but wouldn't mind
"true" being tested by someone and learning what happens.

-- 
Brian.

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

#184233

On Tue, Jul 25, 2017 at 07:40:17PM +0100, Brian wrote:
> /usr/share/doc/apt/examples/configure-index.gz has
> 
>      AutomaticRemove "false";       
>      HideAutoRemove "false";
> 
> as configuration directives. I've never tried them but wouldn't mind
> "true" being tested by someone and learning what happens.

Oh, that looks promising.

titan:~$ cat /etc/apt/apt.conf.d/99local
// APT::NeverAutoRemove ".";
titan:~$ sudo apt-get -u upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  docutils-common docutils-doc firebird2.5-common firebird2.5-common-doc
  firebird2.5-server-common firebird3.0-common firebird3.0-common-doc
  fvwm-icons imagemagick-common liba52-0.7.4 libalgorithm-c3-perl
  libarchive-extract-perl libasn1-8-heimdal libavcodec56 libavdevice55
  libavformat56 libavresample2 libavutil54 libb-hooks-endofscope-perl
  libbind9-90 libbluetooth3 libboost-system1.55.0 libc6-i686:i386
  libclamav-client-perl libclass-c3-perl libclass-c3-xs-perl
  libclass-method-modifiers-perl libclass-xsaccessor-perl libcolamd2.8.0
  libcpan-changes-perl libcpan-meta-perl libdata-perl-perl
  libdata-section-perl libdca0 libdevel-caller-perl
  libdevel-globaldestruction-perl libdevel-lexalias-perl libdirectfb-1.2-9
....

titan:~$ sudo vi /etc/apt/apt.conf.d/99local
titan:~$ cat /etc/apt/apt.conf.d/99local
APT::NeverAutoRemove ".";
titan:~$ sudo apt-get -u upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

That'll work!  Thanks.

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

#184254

On Tuesday 25 July 2017 10:02:50 Greg Wooledge wrote:

> Is there any way to permanently neuter apt-get autoremove, so that
> even if something invokes it against my will, it will *never* remove
> anything?
>
> And more, is there a way to get apt and apt-get to *stop* prompting me
> to run it, and *stop* spamming me with a list of packages that it
> would like me to remove?  (Maybe that's the same as the first
> question, maybe not.)
>
> My strategy so far has been "ignore the spam, and never willingly run
> autoremove".  This mostly works, but I recently learned that tasksel
> will apparently run an autoremove, without warning, whether I want it
> to or not (<http://bugs.debian.org/868892>).
>
> If autoremove will also remove *kernels*, which this thread seems to
> indicate is the case, then my concerns just went up another notch.
>
In that event, see man apt and find the "pin" instructions.

I recently had a rt kernel wiped on a raspi, which kills linuxcnc.

I pulled the sd card in here, and replaced the missing kernel, then 
following the pin instructions, and then watching the --upgradable 
listings, added 2 more stanza's to a file in /etc/apt/preferences.d, 
named kernel.pref, so it looks like this:
  
pi@picncsheldon:~/linuxcnc/configs/sheldon-lathe $ 
cat /etc/apt/preferences.d/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
============================
pi@picncsheldon:~/linuxcnc/configs/sheldon-lathe $ 

I know, that is an older rt kernel, but the performance of the newer ones 
is horrifying, missing keyboard events to the point of completely 
unusable.

> I suppose one could manually mark each and every single installed
> package as "manually installed", but you'd have to remember to repeat
> this periodically, and it seems clumsy and inelegant compared to some
> sort of master switch that can just tell autoremove to go die in a
> fire.


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]

#184202

On 07/25/2017 09:12 AM, VigneshDhanraj G wrote:
> Hi Team,
> 
> I am using kernel 3.2.x, i know that support from wheezy will be stopped
> soon. can i upgrade to jessie with same kernel version. 


Hi Vignesh,

why do you want to use Wheezy's kernel on Jessie, custom kernel space
drivers maybe? I'm just curious.

On the other hand Jessie's kernel (3.16) became kernel.org LTS release
and is well maintained.

Kind regards
Georgi

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web