Re: How to safely hold kernel packages ?
- Date: Thu, 8 Feb 2018 09:51:25 -0800
- From: Jimmy Johnson <field.engineer@xxxxxxxxx>
- Subject: Re: How to safely hold kernel packages ?
On 02/07/2018 12:27 AM, Stéphane Rivière wrote:
Thanks Jimmy for your help,
It appears that apt-mark hold and aptitude hold have same effects, you
could obtain the same with some tricks with dpkg.
I would use 'apt-mark'. # apt-mark hold 'package-name'
and # apt-mark unhold 'package-name'
If I used apt-get, it should be wise to use apt-mark. When using only
aptitude (my choice), it seems I must use aptitude hold to remain
consistent (using apt-get or aptitude is an old, and perhaps unclear,
I love using all the Debian Tools, while using Synaptic to install the
meta-package nvidia-driver in Wheezy I found the nvidia-driver package
is broken and Synaptic does not give much info on broken packages so I
ran # aptitude install nvidia-driver and found that nvidia-settings was
not installable and knowing that nvidia-settings is not needed I was
able to install the nvidia-driver with no further problem.
Thanks to your post I found a new tool> Debian package "dlocate" and now
I can run:
# dpkg-hold 'package-name' and dpkg-unhold, dpkg-remove, dpkg-purge.
Pretty powerful tool don't you think.
By the way I've found what is the kaiser patch (inducing performance
loss between 5% -mean use- and 30% -a heavy network load-) and why (in
my context only, see previous message) I should use nokaiser option
(https://lwn.net/Articles/737940) and, thanks to fine people here, the
nopti option.network link
Well thanks to all the noise about spectre and meltdown some people are
now trying to exploit it, now saying that, these problems have been in
hardware for more than 5 years(and Intel kept on making them and that
seems criminal to me) and with no reports of any exploit, so I let the
experts work on the problem and keep my many systems(Ubuntu 14.04,
16.04, 18.04 and Debian Wheezy, Jessie, Stretch, Buster and Sid
installed on two desktops and 5 laptops) updated and I feel as the
experts do and that is these affected cpu's should be recalled and
replaced, Intel trying to fix a hardware problem with software is not
On an almost idle workstation the effects of using theses options are
not really visible (tested). But on a huge Xeon 64Go ram 2x2To
raid1/lvm/debian 8/Xen 4 with 1 Gbps network and more than twenty VM,
definitly not the same story (some friends has done some tests on their
less loaded than mine dedicated servers and the performance loss is
really huge). I have some low cost spare dedicated servers and will
proceed to some tests too.
Sounds like a nice computer, but without the model number, cores, bus
speed it's hard to tell just how fast it can work or move a Tb or two of
All the best from Oleron island,
Cool! And blessings to you from sunny California!--
Debian Jessie - KDE 4.14.2 - AMD A8-7600 - EXT4 at sda5
Registered Linux User #380263