1 |
On Saturday, 8 June 2019 19:01:30 BST Grant Taylor wrote: |
2 |
> I'm having problems with newly compiled modules (zfs (et al.) and vbox |
3 |
> (et al.)) and kernel after doing two "emerge -DuNe @world"s. |
4 |
> |
5 |
> Everything worked fine after rebooting after the first "emerge -DuNe |
6 |
> @world". So, I did another "emerge -DuNe @world". (This harks back to |
7 |
> the old stage 1 -> stage 2 -> stage 3 methodology that I cut my teeth |
8 |
> on. Create the new tool, use said tool to recreate the tool.) |
9 |
> |
10 |
> After the reboot after this second "emerge -DuNe @world" is when my ZFS |
11 |
> pool became inaccessible. |
12 |
> |
13 |
> Aside: I migrated from ZFS 0.7.999 to 0.8 as part of the first emerge. |
14 |
> This worked fine. |
15 |
> |
16 |
> I have since found out that I can't load vbox* modules, nor can I boot a |
17 |
> kernel that I can successfully build. |
18 |
> |
19 |
> The modules fail with the following error: |
20 |
> |
21 |
> modprobe: ERROR: could not insert '<module name>': Exec format error. |
22 |
> |
23 |
> Dmesg reports the following associated error: |
24 |
> |
25 |
> [ <seconds since boot>] module: <module name>: Unknown rela |
26 |
> relocation: 4 |
27 |
> |
28 |
> My searches online have made me think that this /might/ be a problem |
29 |
> with newer binutils. But I'm not sure. |
30 |
> |
31 |
> So, I figured that I'd ask for some help / input before I do something |
32 |
> drastic that I might regret, like making things worse, or painting |
33 |
> myself into a corner that I can't back out of. |
34 |
> |
35 |
> Aside: I have regained access to my ZFS pool by restoring the ZFS |
36 |
> contents of the /lib/modules/<version>/extra directory. |
37 |
|
38 |
Were these contents not there, or is it that the new version of modules do not |
39 |
work? If the former, then could this be related to the migration over to |
40 |
profile 17.1? |
41 |
-- |
42 |
Regards, |
43 |
Mick |