1 |
Apparently, though unproven, at 15:20 on Monday 16 May 2011, felix@×××××××.com |
2 |
did opine thusly: |
3 |
|
4 |
> I have an ancient emerge script which does this: |
5 |
> |
6 |
> rm -rf /var/lib/module-rebuild |
7 |
> module-rebuild -C list |
8 |
> |
9 |
> and I do not know why -- did I dream this up myself, or did I inherit |
10 |
> it from somewhere? I do not know. |
11 |
> |
12 |
> At any rate, it seems kind of odd. What is the proper way of using |
13 |
> module_rebuild? It seems to me there are two cases, and maybe that |
14 |
> is why this script has this odd code. If you have just built a brand |
15 |
> new kernel, you might want to rebuild the module list from scratch. |
16 |
> But once you have done that, future emerges only need to keep the |
17 |
> module list up to date. |
18 |
> |
19 |
> And then I realized I don't even know what the module list actually |
20 |
> is. |
21 |
> |
22 |
> Please enlighten me :-O |
23 |
|
24 |
Looks like something you dreamed up. |
25 |
|
26 |
/var/lib/module-rebuild contains a list of installed out-of-tree modules. You |
27 |
delete the entire directory then list it (to prove that it is empty?) |
28 |
|
29 |
I have no idea why you might have wanted to do that back in the day. |
30 |
|
31 |
The correct way to use module-rebuild is to run once: |
32 |
|
33 |
module-rebuild populate |
34 |
|
35 |
This will search the tree to find out-of-kernel-tree module ebuilds you are |
36 |
using and put them in a db or later use. |
37 |
|
38 |
Every time you emerge and build a new kernel, run: |
39 |
|
40 |
module-rebuild rebuild |
41 |
|
42 |
This will build the missing modules for the kernel you just built. |
43 |
|
44 |
module-rebuild add|del lets you maintain the list as you add and delete stuff |
45 |
|
46 |
|
47 |
-- |
48 |
alan dot mckinnon at gmail dot com |