1 |
On Monday 04 May 2009 14:11:02 Matt Causey wrote: |
2 |
> > Out of tree kernel modules are a maintenance pain in the ass, and cause |
3 |
> > severely non-obvious problems like this. Every time you upgrade your |
4 |
> > kernel, you must rebuild the out-of-tree modules, and you do that by |
5 |
> > re-running "emerge madwifi-ng". This builds a new modules that matches |
6 |
> > the currently configured kernel (/usr/src/linux/) and puts the module in |
7 |
> > /lib/modules/<version> |
8 |
> > |
9 |
> > Upgrade your kernel a few times and you have various versions of modules |
10 |
> > floating around. Portage remembers the modules installed by the most |
11 |
> > recent emerge, but AFAIK forgets all the previous ones. This is expected |
12 |
> > of course - when you upgrade firefox-2 to firefox-3 you would not expect |
13 |
> > the system to remember the firefox-2 files (as they are supposed to not |
14 |
> > be there anymore) |
15 |
> |
16 |
> Your explanation is extremely helpful here. Thanks! As long as I |
17 |
> know the expectation, I can plan for it when troubleshooting. I can |
18 |
> certainly see the 'pain in the ass' factor there. :-) I was |
19 |
> originally chasing a panic caused by ath_pci - but now that I've |
20 |
> looked more closely at the issue that you describe here, I see that I |
21 |
> did manage to get 2 incompatible interdependent modules installed in |
22 |
> the system...grrr. |
23 |
|
24 |
Love gotta love gentoo - break it, you get to keep both pieces :-) |
25 |
|
26 |
> I'll be doing some more-than-casual tinkering with |
27 |
> ath_pci vs ath5k in the coming weeks, so I'll probably just plan not |
28 |
> to use that ebuild for the present moment. :-) Although....would it |
29 |
> be non-trivial for me to try and extend the ebuild to make it clean up |
30 |
> after itself on unmerge? |
31 |
" |
32 |
Portage keeps it's house-keeping in /var/db/pkg with subdirectories in the |
33 |
form <category>/<package>-<version>. There's interesting stuff in there, like |
34 |
a file called CONTENTS. It has the files installed by the ebuild, plus their |
35 |
md5sums, and that's how portage knows what to rm when you unmerge. |
36 |
|
37 |
"man ebuild" lists the functions you can override in ebuilds, including |
38 |
unmerge. It calls pkg_postrm (a simple bash function) so you could in theory |
39 |
insert a call to "find /lib/modules" to find all the modules in question and |
40 |
delete them. You'd have to think this through carefully though as the |
41 |
potential for destruction is vast... |
42 |
|
43 |
> Along the same lines, how does the ebuild know what to remove on |
44 |
> --unmerge? For example I'm wandering around and looking at ebuilds: |
45 |
> |
46 |
> prometheus ethtool # pwd |
47 |
> /usr/portage/sys-apps/ethtool |
48 |
> prometheus ethtool # ls |
49 |
> ChangeLog Manifest ethtool-6.ebuild metadata.xml |
50 |
> prometheus ethtool # |
51 |
> |
52 |
> I see nothing in that ebuild which describes the files that ethtool |
53 |
> put on the system. Yet an --unmerge removes the binaries and |
54 |
> source....interesting. |
55 |
|
56 |
Portage runs the ebuild in a restricted directory - |
57 |
/var/tmp/portage/<category>/<package>/<work>/ and all the built files end up |
58 |
there, in a directory structure that mirrors the root filesystem layout. |
59 |
|
60 |
"man ebuild" has all the gory details. Try this: run |
61 |
"ebuild /usr/portage/sys-apps/ethtool-6.ebuild install" |
62 |
and examine /var/tmp/portage/sys-apps/ethtool/work. |
63 |
|
64 |
Note that you emerge a *package name* but ebuild an ebuild *file* (much the |
65 |
same way yum install and rpm -ivh do it). That command will run all the ebuild |
66 |
steps up to and including install, but the files are not yet on the lie |
67 |
filesystem. "ebuild <file> merge" does that, skipping all steps already |
68 |
completed. It then locates every file in the tmp directory and moves them onto |
69 |
the live filesystem, recording what it finds. This list is what goes in |
70 |
CONTENTS. |
71 |
|
72 |
Simple, hey? |
73 |
|
74 |
Virtually every tool out there which gives you information on installed |
75 |
packages (except eix, that also uses huge chunks of voodoo), looks in |
76 |
/var/db/pkg/, which explains why it's so slow - 1462 directories and 35847 |
77 |
files on this box is a lot of stuff to stat and read |
78 |
|
79 |
-- |
80 |
alan dot mckinnon at gmail dot com |