DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Location: East Coast, USA (in "the great northeast")
Distribution: Custom / from source; Fedora, Debian, CentOS, Scientific; LFS.
Posts: 94
Rep:
apt: keeping custom kernel: equivs? pin?
Hi, all -
My Debian system is humming along nicely, thanks to everyone who helped me migrate from RedHat to etch.
One little problem. I'm using a custom kernel. From what I can gather the system thinks the name of the kernel image and kernel headers are "linux-image-2.6-amd64" and "linux-headers-2.6-amd64", respectively, in my case. When I built my kernel, though, I used - per the advice in pretty much every kernel howto I read - a slightly different name && version string. So, I can't keep my kernel headers and image with pinning, since I don't have a name <-> name match between the "official" packages and my packages (right?) I tried:
Code:
Package: linux-image-2.6.22-ck1.04082007
Pin: version *
Pin-Priority: 1001
Package: linux-headers-2.6.22-ck1.04082007
Pin: version *
Pin-Priority: 1001
but apt still wants to install linux-image-2.6-amd64 v 2.6.18+6etch1 and its corresponding headers package.
From the documentation, it looked like "equivs" is more along the lines of what I'm after; I have no idea, though, how to build a kernel using "equivs-build" or if that's even one of the intended purposes of "equivs".
For now, I guess I can just clear the check-boxes next to the linux-image-2.6-amd64 and linux-headers-2.6-amd64 packages in update-manager; hopefully, someone can tell me how to keep them from appearing there in the first place. Because, sooner or later, I can guarantee that I'll screw up and accidentally install an older version of the kernel - or the headers - ...
To put a package on hold: echo "linux-image-2.6-amd64 hold"|dpkg --set-selections
To put it off hold: echo "linux-image-2.6-amd64 install"|dpkg --set-selections
Post the commands you used to build and install the kernel image.
Location: East Coast, USA (in "the great northeast")
Distribution: Custom / from source; Fedora, Debian, CentOS, Scientific; LFS.
Posts: 94
Original Poster
Rep:
Quote:
Originally Posted by makuyl
To put a package on hold: echo "linux-image-2.6-amd64 hold"|dpkg --set-selections
To put it off hold: echo "linux-image-2.6-amd64 install"|dpkg --set-selections
Wow. Thanks. It would've been a while before I figured that out.
Quote:
Post the commands you used to build and install the kernel image.
After the usual tar xvjf, patch, make config, etc., I did:
The second command is incorrect; there's no package by that name - I must've gotten confused earlier and figured that the names of the image and the headers matched. I issued the following command to try and fix that:
$ dpkg --list linux-headers-2.6-amd64
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-=================-=================-==================================================
in linux-headers-2.6 <none> (no description available)
I'm not sure if that's even a problem. What is, is that the software updater now wants to install two older versions of the kernel; it has both "linux-image-2.6-amd64-generic" and "linux-2.6.18-5-amd64" checked && in the updates list.
And, when I first start it (software updater), I get an error message to the effect:
"Cannot install all available updates Some updates require the removal of further software. Use the function "Mark All Upgrades" of the package manager "Synaptic" ... The following updates will be skipped: linux-image-2.6-amd64"
So, it's apparently skipping one, but trying to install two older ones...
I'm not sure what I'm doing wrong here but apparently I've got something messed up.
Last edited by HowDoIProgramIt; 08-19-2007 at 08:02 PM.
My Debian system is humming along nicely, thanks to everyone who helped me migrate from RedHat to etch.
One little problem. I'm using a custom kernel. From what I can gather the system thinks the name of the kernel image and kernel headers are "linux-image-2.6-amd64" and "linux-headers-2.6-amd64", respectively, in my case. When I built my kernel, though, I used - per the advice in pretty much every kernel howto I read - a slightly different name && version string. So, I can't keep my kernel headers and image with pinning, since I don't have a name <-> name match between the "official" packages and my packages (right?) I tried:
Code:
Package: linux-image-2.6.22-ck1.04082007
Pin: version *
Pin-Priority: 1001
Package: linux-headers-2.6.22-ck1.04082007
Pin: version *
Pin-Priority: 1001
but apt still wants to install linux-image-2.6-amd64 v 2.6.18+6etch1 and its corresponding headers package.
From the documentation, it looked like "equivs" is more along the lines of what I'm after; I have no idea, though, how to build a kernel using "equivs-build" or if that's even one of the intended purposes of "equivs".
For now, I guess I can just clear the check-boxes next to the linux-image-2.6-amd64 and linux-headers-2.6-amd64 packages in update-manager; hopefully, someone can tell me how to keep them from appearing there in the first place. Because, sooner or later, I can guarantee that I'll screw up and accidentally install an older version of the kernel - or the headers - ...
Thanks,
Larry
There should be no need for any of what you are doing here you can just uninstall the linux-image-2.6-amd64 and linux-headers-2.6-amd64 packages they are what is called a meta package. These meta packages are a place holder of sorts that ensures that the latest version of the software that depends on them are installed so can be safely removed. Also you can do nothing and let the packages be upgraded it will not affect your running kernel it will still stay installed and you will have the option to boot into it from the grub menu.
Location: East Coast, USA (in "the great northeast")
Distribution: Custom / from source; Fedora, Debian, CentOS, Scientific; LFS.
Posts: 94
Original Poster
Rep:
Quote:
Originally Posted by HappyTux
There should be no need for any of what you are doing here you can just uninstall the linux-image-2.6-amd64 and linux-headers-2.6-amd64 packages they are what is called a meta package. These meta packages are a place holder of sorts that ensures that the latest version of the software that depends on them are installed so can be safely removed. Also you can do nothing and let the packages be upgraded it will not affect your running kernel it will still stay installed and you will have the option to boot into it from the grub menu.
That's a lot better, thanks. At first I tried:
Code:
$ dpkg -r linux-image-2.6-amd64
dpkg: dependency problems prevent removal of linux-image-2.6-amd64:
linux-image-2.6-amd64-generic depends on linux-image-2.6-amd64.
dpkg: error processing linux-image-2.6-amd64 (--remove):
dependency problems - not removing
Errors were encountered while processing:
linux-image-2.6-amd64
Since that abended, I tried:
Code:
$ dpkg -r linux-image-2.6-amd64 linux-image-2.6-amd64-generic
(Reading database ... 194540 files and directories currently installed.)
Removing linux-image-2.6-amd64-generic ...
Removing linux-image-2.6-amd64 ...
I wasn't sure exactly what "purge" would remove, so I stuck with "remove" . Which apparently worked; software-updater is happy now and not prompting me to install new kernel && kernel headers.
So the trick is to remove the "official" kernel meta-package from the update list, then; thanks.
$ dpkg -r linux-image-2.6-amd64
dpkg: dependency problems prevent removal of linux-image-2.6-amd64:
linux-image-2.6-amd64-generic depends on linux-image-2.6-amd64.
dpkg: error processing linux-image-2.6-amd64 (--remove):
dependency problems - not removing
Errors were encountered while processing:
linux-image-2.6-amd64
Since that abended, I tried:
Code:
$ dpkg -r linux-image-2.6-amd64 linux-image-2.6-amd64-generic
(Reading database ... 194540 files and directories currently installed.)
Removing linux-image-2.6-amd64-generic ...
Removing linux-image-2.6-amd64 ...
I wasn't sure exactly what "purge" would remove, so I stuck with "remove" . Which apparently worked; software-updater is happy now and not prompting me to install new kernel && kernel headers.
So the trick is to remove the "official" kernel meta-package from the update list, then; thanks.
- Larry
Yes essentially correct but it still would have made no difference if you had let it update them you would still have had your kernel available to boot with, all it would have done was upgrade your non-running kernel still installed on the system.
Location: East Coast, USA (in "the great northeast")
Distribution: Custom / from source; Fedora, Debian, CentOS, Scientific; LFS.
Posts: 94
Original Poster
Rep:
Quote:
Originally Posted by HappyTux
Yes essentially correct but it still would have made no difference if you had let it update them you would still have had your kernel available to boot with, all it would have done was upgrade your non-running kernel still installed on the system.
That makes sense; in this case, the system boots from a volume that's separate from the Debian installation; I have to alter grub.conf manually whenever I want to add or remove an image from grub's boot menu, anyway.
What I'm still not understanding though is what effect, if any, the linux-headers package which corresponds to the kernel that software-updater was looking to install would have had on this sytem. It's not appearing in the The linux-headers package only appears in the list-of-packages-to-be-updated now; the pkg mgmt system was smart enough to take it out of there when the kernel meta-package was taken out of there. But when the meta-package installed, the linux-headers package kept getting tagged as "to be updated" whenever the pkg mgmt system wanted to install a new kernel.
Wouldn't the headers I have installed now end up getting overwritten? When I compiled the kernel && installed it, that's exactly what happened; the linux-headers package that I installed overwrote the one that was installed before it. Or am I missing / misunderstanding something about the way apt / dpkg / etc. work (which is distinct possibility) ...
That makes sense; in this case, the system boots from a volume that's separate from the Debian installation; I have to alter grub.conf manually whenever I want to add or remove an image from grub's boot menu, anyway.
What I'm still not understanding though is what effect, if any, the linux-headers package which corresponds to the kernel that software-updater was looking to install would have had on this sytem. It's not appearing in the The linux-headers package only appears in the list-of-packages-to-be-updated now; the pkg mgmt system was smart enough to take it out of there when the kernel meta-package was taken out of there. But when the meta-package installed, the linux-headers package kept getting tagged as "to be updated" whenever the pkg mgmt system wanted to install a new kernel.
Wouldn't the headers I have installed now end up getting overwritten? When I compiled the kernel && installed it, that's exactly what happened; the linux-headers package that I installed overwrote the one that was installed before it. Or am I missing / misunderstanding something about the way apt / dpkg / etc. work (which is distinct possibility) ...
Well if using the kernel-package program to create a .deb that gets installed then nothing at all should happen to the linux-headers package that gets installed unless you did not make sure that you had the kernels named differently with the --append-to-version=???? option then they would install over the existing kernel/header directories. The headers should be installed into their own directory in your /usr/src directory like below named differently.
For the package management to be updated question it was doing what it was supposed to do when the kernel gets updated it has a different revision therefore you need to update the headers as well otherwise anything you may need to compile against your running kernel will tell you that there is a mismatch between the kernel and headers.
Location: East Coast, USA (in "the great northeast")
Distribution: Custom / from source; Fedora, Debian, CentOS, Scientific; LFS.
Posts: 94
Original Poster
Rep:
Quote:
Originally Posted by HappyTux
Well if using the kernel-package program to create a .deb that gets installed then nothing at all should happen to the linux-headers package that gets installed ...
I think I thought about this whole thing for way too long and ended up turning it into a lot more than it actually was. Somehow, I ended up forgetting that each kernel that's installed on any given machine has its own source and header dir in /lib/modules/$(uname -r)/source/include, and also lives wherever else I may have put it. Thanks for that...
Have you found there to be much of a use for "equivs" or no? I was planning on installing a non-BIND nameserver; is it worth screwing with equivs or not in that case (I doubt there would be anything else that I would want to install that depended upon my having a working nameserver). I'm going to be installing qmail, too, though, and MTAs were the specific example they used w resepect to when you should use "equivs".
The package manager sure is potent. But, like any other reasonably complex piece of software, it's taking me a while to get used to it. I've gotten some of my own apps into .deb packages; it's a nice setup. I've been using dpkg-buildpackage, from what I've been able to tell, there's no disadvantage to using that over dpkg-deb (right?)
Thanks to all for your time and consideration; I really appreciate it.
Have you found there to be much of a use for "equivs" or no? I was planning on installing a non-BIND nameserver; is it worth screwing with equivs or not in that case (I doubt there would be anything else that I would want to install that depended upon my having a working nameserver). I'm going to be installing qmail, too, though, and MTAs were the specific example they used w resepect to when you should use "equivs".
The package manager sure is potent. But, like any other reasonably complex piece of software, it's taking me a while to get used to it. I've gotten some of my own apps into .deb packages; it's a nice setup. I've been using dpkg-buildpackage, from what I've been able to tell, there's no disadvantage to using that over dpkg-deb (right?)
Thanks to all for your time and consideration; I really appreciate it.
- Larry
I don't think I can help much with these never used the equivs package for anything and any source that I build I use checkinstall to get a .deb to install and on the on occasion used the dpkg-buildpackage to rebuild Debian sources only so can't tell you much about it. You might want to try the debian-user, debian-devel or debian-mentors mailing lists these can be located/searched at http://lists.debian.org.
Location: East Coast, USA (in "the great northeast")
Distribution: Custom / from source; Fedora, Debian, CentOS, Scientific; LFS.
Posts: 94
Original Poster
Rep:
Quote:
Originally Posted by HappyTux
... any source that I build I use checkinstall to get a .deb to install ...
I just googled "checkinstall" and from what I'm seeing it looks like its a lot less overkill than dpkg-buildpackage is for a lot of things (specifically, I was reading http://www.debian-administration.org/articles/147 ; if you have any other favorite resources with respect to checkinstall, and wouldn't mind posting them, I'd really appreciate it.
So, when I have a package that I don't ever want the package mgmt system to update, ever, I'm better off "putting it on hold" than mucking with pinning and the like, right?
Thanks again very much for your time and your help.
- Larry
Last edited by HowDoIProgramIt; 08-21-2007 at 01:31 PM.
I just googled "checkinstall" and from what I'm seeing it looks like its a lot less overkill than dpkg-buildpackage is for a lot of things (specifically, I was reading http://www.debian-administration.org/articles/147 ; if you have any other favorite resources with respect to checkinstall, and wouldn't mind posting them, I'd really appreciate it.
Thanks again very much for your time and your help.
- Larry
Not really much to do with it you simply use the normal ./configure, make and then instead of make install you would use a command like su -c 'checkinstall -D --pkgname=package --pkgversion=1.2.3 --maintainer="Your Name your@email.com"' it then build/installs the .deb file for you after you enter your root password and answer a couple of questions/provide a description for the package.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
