1

I held the Kernel so while updating, the newer kernel version weren't marked for installation until yesterday. It is a security update so I know is recommended to do this update but the question is regarding Holding packages. Note: The Kernel has been on hold for some time now.

What could have caused the package to get out of hold? If it was holding the update why did it came out of hold?

This time I held everything with a version number and with the word generic.

linux-generic set on hold.
linux-headers-4.4.0-21 set on hold.
linux-headers-4.4.0-21-generic set on hold.
linux-headers-generic set on hold.
linux-image-4.4.0-21-generic set on hold.
linux-image-extra-4.4.0-21-generic set on hold.
linux-image-generic set on hold.
linux-tools-4.4.0-21 set on hold.
linux-tools-4.4.0-21-generic set on hold.
userDepth
  • 2,010
  • Which packages did you hold? – Pilot6 Mar 10 '16 at 12:42
  • I get what you are saying. That Meta-packages are transitional and that those don't hold the kernel versions. Is that it ? – userDepth Mar 10 '16 at 12:49
  • Meta packages point to the latest kernel image and headers and pull them by dependencies. – Pilot6 Mar 10 '16 at 12:50
  • I know that, still I haven't actually read documentation stating this. I went to "info dpkg" and it says that packages on hold are not handled by dpkg. – userDepth Mar 10 '16 at 12:56
  • 3
    Hold works very simply on all packages including meta. They just do not update. But each kernel image is a NEW package, not an upgrade of an old one. You probably can't get this. But metas ob upgrade point to a new packages. – Pilot6 Mar 10 '16 at 14:15
  • Ok as you state that holding meta-packages don't have any effect and apparently keep misreading my question or omitting what you can't answer I'll reinstall Ubuntu and in the fresh install apply an update with the Meta-Packages on hold. And Ubuntu will tell. I'll read the documentation myself and answer my question with the desired sources provided.

    "Meta packages point to the latest kernel image and headers and pull them by dependencies. – Pilot6"

     – userDepth Mar 10 '16 at 14:56
  • @Pilot6 Check out the finalized post – userDepth May 31 '16 at 14:31
  • You aren't holding the actual meta packages (linux-generic, linux-image-generic and linux-headers-generic). – muru Jun 05 '16 at 03:35

1 Answers1

2

If you need to stick to a specific kernel package version, you'll need to hold all of these:

linux-generic
linux-image-generic
linux-headers-generic
linux-image-X.Y.Z-W-generic
linux-image-extra-X.Y.Z-W-generic 
linux-headers-X.Y.Z-W-generic

for suitable X, Y, Z and W. Here, the actual versions of the packages would be like X.Y.Z-W.V (4.4.0-21.37, for example). Here, X.Y.Z is the upstream base kernel version, W is the ABI number, and V is the build number (see the Ubuntu Wiki).

If meta-packages aren't held and real ones are:

  • if W gets bumped, the actual package names will change to the new version. The meta-packages will be upgraded, installing the new kernel, since this operation doesn't involve the existing linux-{image,image-extra,headers}-X.Y.Z-W-generic packages.
  • if V gets bumped and W doesn't, the package names remain the same, so the existing linux-{image,image-extra,headers}-X.Y.Z-W-generic prevent the upgrade due to being held. Consequently, the meta-packages aren't upgraded either.

If meta-packages are held and real ones aren't:

  • if W gets bumped, no new kernel will be installed, since the metapackages' change in dependencies don't take effect due to being held.
  • if V gets bumped and W doesn't, new kernel packages will be installed, but they will be retain ABI compatibility to the old package.

You are holding the real packages and not the metapackages. In the last image, you can clearly see that W has increased from 21 to 22, and so the package names have changed, and the old holds no longer matter.

muru
  • 197,895
  • 55
  • 485
  • 740
  • So in the end is no, apt-get has no way of knowing if an update is indeed for my specific HW ? – userDepth Jul 16 '16 at 16:58
  • @userDepth eh, what do you mean? And I see your post has changed considerably from what it was, so I don't know if your problem is still the same or the information you provide is reliable – muru Jul 16 '16 at 17:01
  • The question is the same @muru maybe my question needs too much expertise. – userDepth Jul 16 '16 at 20:09
  • @muru - Thanks for the great reply. Do you know if the list you provide is still valid (i.e. comprehensive)? I found so many different versions and am kind of lost... Any help would be great – Matteo Jan 27 '18 at 22:28
  • @Matteo follow the chain of dependencies. If any of these packages depend on additional linux-*-generic packages, hold them as well. – muru Jan 28 '18 at 00:57