| 1 |
On Tue, Aug 15, 2017 at 5:19 PM, John Blinka <john.blinka@×××××.com> wrote: |
| 2 |
> |
| 3 |
> Hope someone can shed some light on continuing emerge failures for zfs |
| 4 |
> since gnetoo-sources-4.4.39 and zfs-0.6.5.8. I was able to install |
| 5 |
> that version of zfs with that kernel last November on one of my |
| 6 |
> machines, but have been unable to upgrade zfs since then, or to |
| 7 |
> install it in any newer kernel, or even to re-install the same version |
| 8 |
> on the same kernel. |
| 9 |
|
| 10 |
I've been running various zfs+4.4.y versions without issue on a stable |
| 11 |
amd64 config (using upstream kernels). |
| 12 |
|
| 13 |
Currently I'm on 0.7.1+4.4.82. |
| 14 |
|
| 15 |
> checking kernel source version... Not found |
| 16 |
> configure: error: *** Cannot find UTS_RELEASE definition. |
| 17 |
> |
| 18 |
... |
| 19 |
> |
| 20 |
> Googling around for the "Cannot find UTS_RELEASE" complaint reveals |
| 21 |
> that a few people have encountered this problem over the years. It |
| 22 |
> appeared in those cases to be attributable to the user running the |
| 23 |
> configuration script not having sufficient authority to read |
| 24 |
> ./include/generated/utsrelease.h in the kernel tree. |
| 25 |
|
| 26 |
I suspect your sources have gotten messed up in some way. I've run |
| 27 |
into issues like this when I do something like build a kernel with an |
| 28 |
odd umask so that the portage user can't read the files it needs to |
| 29 |
build a module. Your chmod should have fixed that but there could be |
| 30 |
something else going on. It might just be that you didn't prepare the |
| 31 |
sources? |
| 32 |
|
| 33 |
I actually do all my kernel builds in a tmpfs under /var/tmp these |
| 34 |
days which keeps my /usr/src/linux pristine. (make O=/var/tmp/linux |
| 35 |
modules_install and so on) It does involve more building during |
| 36 |
upgrades but I know everything is clean, and I prefer no-issues to |
| 37 |
faster-builds. |
| 38 |
|
| 39 |
In theory that isn't essential, but I would definitely just wipe out |
| 40 |
/usr/src/linux and unpack clean kernel sources. If you're using the |
| 41 |
gentoo-sources package you can just rm -rf the symlink and the actual |
| 42 |
tree, and just re-emerge the package and it will set up both. If |
| 43 |
you're using git then I'd probably wipe it and re-pull as I'm not sure |
| 44 |
if a clean/reset will actually take care of all the permissions. |
| 45 |
|
| 46 |
Then you need to run at least make oldconfig and make modules_prepare |
| 47 |
before you can build a module against it. Doing a full kernel build |
| 48 |
is also fine. |
| 49 |
|
| 50 |
-- |
| 51 |
Rich |
Archives