Re: [gentoo-user] zfs emerge failure (solved)

[John Blinka]

Rich Freeman had the right clue.

Some time ago, after successfully installing zfs, I changed root's
umask to 0027.  This had the effect of changing the permissions on
/lib/modules/X.Y.Z-gentoo to drwxr-x--- on a subsequent kernel
upgrade.  This prevents emerge (once it switches to user:group
portage:portage) from being able to explore the contents of
/lib/modules/X.Y.Z-gentoo.  Unfortunately for me, spl's configure
script locates the current kernel source by following the
/lib/modules/X.Y.Z-gentoo/build soft link.  And it couldn't do that
with the overly restrictive umask.  The solution was simple: eliminate
the 0027 umask for root, and chmod o+rx /lib/modules/X.Y.Z-gentoo.

Thanks for all the suggestions.  They all helped.

John Blinka

Re: [gentoo-user] zfs emerge failure

[John Blinka]

On Tue, Aug 15, 2017 at 7:13 PM, John Blinka  wrote:
> On Tue, Aug 15, 2017 at 6:54 PM, John Covici  wrote:
>
>> What is your umask?   I had troubles like this when I had too
>> aggressive umask of I think 027 rather than 022.
>
> It is indeed 027, and I wondered whether that might have been what was
> behind the error, hence I tried chmod -R 777 the entire kernel tree.
> But maybe that mask is doing something nasty during the actual config
> step apart from the kernel tree.  I'll try backing off the umask.
> Thanks!
>
> John

Back at debugging the spl configuration failure after a hiatus.  Tried
a umask of 022.  No change in failed spl configuration.

John

Re: [gentoo-user] zfs emerge failure

[John Blinka]

On Tue, Aug 15, 2017 at 7:14 PM, John Blinka  wrote:
> On Tue, Aug 15, 2017 at 6:51 PM, Rich Freeman  wrote:
>>
>> Yes, and in fact it is in the output when emerge fails:
>>  /var/tmp/portage/sys-kernel/spl-0.7.1/work/spl-0.7.1/config.log
>

Digging into config.log after a hiatus to attend to other demands of
life.  Comparing config.log output to the code in the corresponding
"configure" script was a little enlightening - at least it was clear
what the configure script was trying to do when it failed.   In
anticipation of throwing some echo statements into a modified script
to help debug further, I tried to see if the configure script could be
invoked using the command line arguments documented in config.log.  To
my surprise, when invoking configure that way, the script proceeded to
completion without any problems.  There's a clue.  Executing on the
command line as user root and group root leads to success, and
executing through portage as portage:portage (judging from the
ownership of files in
/var/tmp/portage/sys-kernel/spl-0.7.1/work/spl-0.7.1) leads to
failure.

Thanks for the hint. back to debugging.

John

Re: [gentoo-user] zfs emerge failure

[John Blinka]

On Tue, Aug 15, 2017 at 6:51 PM, Rich Freeman  wrote:
>
> Yes, and in fact it is in the output when emerge fails:
>  /var/tmp/portage/sys-kernel/spl-0.7.1/work/spl-0.7.1/config.log


Ah-ha!  I see it now. That['s valuable, and I'll take a closer look.  Thanks!

John

Re: [gentoo-user] zfs emerge failure

[John Blinka]

On Tue, Aug 15, 2017 at 6:54 PM, John Covici  wrote:

> What is your umask?   I had troubles like this when I had too
> aggressive umask of I think 027 rather than 022.

It is indeed 027, and I wondered whether that might have been what was
behind the error, hence I tried chmod -R 777 the entire kernel tree.
But maybe that mask is doing something nasty during the actual config
step apart from the kernel tree.  I'll try backing off the umask.
Thanks!

John

Re: [gentoo-user] zfs emerge failure

[John Covici]

On Tue, 15 Aug 2017 18:46:59 -0400,
John Blinka wrote:
> 
> On Tue, Aug 15, 2017 at 6:04 PM, Rich Freeman  wrote:
> 
> First, I appreciate your thoughts and comments.
> 
> >
> > I suspect your sources have gotten messed up in some way.  I've run
> > into issues like this when I do something like build a kernel with an
> > odd umask so that the portage user can't read the files it needs to
> > build a module.  Your chmod should have fixed that but there could be
> > something else going on.  It might just be that you didn't prepare the
> > sources?
> 
> Same thought occurred to me, hence the chmod.  Not sure what "prepare
> the sources" is all about; not a step I've ever used with kernels.
> But see below.
> 
> >
> > I actually do all my kernel builds in a tmpfs under /var/tmp these
> > days which keeps my /usr/src/linux pristine.  (make O=/var/tmp/linux
> > modules_install and so on)  It does involve more building during
> > upgrades but I know everything is clean, and I prefer no-issues to
> > faster-builds.
> 
> I have the same preference.  Will have to take a look at following
> your example..
> 
> >
> > In theory that isn't essential, but I would definitely just wipe out
> > /usr/src/linux and unpack clean kernel sources.  If you're using the
> > gentoo-sources package you can just rm -rf the symlink and the actual
> > tree, and just re-emerge the package and it will set up both.  If
> > you're using git then I'd probably wipe it and re-pull as I'm not sure
> > if a clean/reset will actually take care of all the permissions.
> >
> > Then you need to run at least make oldconfig and make modules_prepare
> > before you can build a module against it.  Doing a full kernel build
> > is also fine.
> 
> I think I've done that (multiple times over the past 8 months).  When
> a new kernel shows up as stable in the tree, I do (as root)
> 
> emerge -DuNv gentoo-sources
> set up symlink
> cd into usr/src/linux
> zcat /proc/config.gz > .config
> make olddefconfig
> make menu_config (as a sanity check)
> make
> make modules_install
> make install
> 
> I don't know what could have messed up the kernel tree other than
> whatever magic happens behind the scenes in the various make commands.
> 
> Just now tried a make modules_prepare followed by an emerge -1 spl.  Same 
> error.
> 
> Started again from scratch.  Moved the kernel tree I've been working
> with (building kernel, modules, etc.) aside, then re-emerged
> gentoo-sources.  Kernel tree should be pristine now, right?  Then
> copied the config from my running kernel (same version 4.12.5) into
> /usr/src/linux.  Then did a make modules_prepare.  Finally did an
> emerge -1 spl.  Same error as always.  So, as attractive as the idea
> of a messed up kernel tree is to me, I don't think that's the source
> of the problem.
> 
> I think it would be informative if I could somehow see exactly what
> commands are being run when the error occurs.  Is there a way of doing
> that?

What is your umask?   I had troubles like this when I had too
aggressive umask of I think 027 rather than 022.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] zfs emerge failure

[Rich Freeman]

On Tue, Aug 15, 2017 at 3:46 PM, John Blinka  wrote:
>
> I think it would be informative if I could somehow see exactly what
> commands are being run when the error occurs.  Is there a way of doing
> that?
>

Yes, and in fact it is in the output when emerge fails:
 /var/tmp/portage/sys-kernel/spl-0.7.1/work/spl-0.7.1/config.log

-- 
Rich

Re: [gentoo-user] zfs emerge failure

[John Blinka]

On Tue, Aug 15, 2017 at 6:04 PM, Rich Freeman  wrote:

First, I appreciate your thoughts and comments.

>
> I suspect your sources have gotten messed up in some way.  I've run
> into issues like this when I do something like build a kernel with an
> odd umask so that the portage user can't read the files it needs to
> build a module.  Your chmod should have fixed that but there could be
> something else going on.  It might just be that you didn't prepare the
> sources?

Same thought occurred to me, hence the chmod.  Not sure what "prepare
the sources" is all about; not a step I've ever used with kernels.
But see below.

>
> I actually do all my kernel builds in a tmpfs under /var/tmp these
> days which keeps my /usr/src/linux pristine.  (make O=/var/tmp/linux
> modules_install and so on)  It does involve more building during
> upgrades but I know everything is clean, and I prefer no-issues to
> faster-builds.

I have the same preference.  Will have to take a look at following
your example..

>
> In theory that isn't essential, but I would definitely just wipe out
> /usr/src/linux and unpack clean kernel sources.  If you're using the
> gentoo-sources package you can just rm -rf the symlink and the actual
> tree, and just re-emerge the package and it will set up both.  If
> you're using git then I'd probably wipe it and re-pull as I'm not sure
> if a clean/reset will actually take care of all the permissions.
>
> Then you need to run at least make oldconfig and make modules_prepare
> before you can build a module against it.  Doing a full kernel build
> is also fine.

I think I've done that (multiple times over the past 8 months).  When
a new kernel shows up as stable in the tree, I do (as root)

emerge -DuNv gentoo-sources
set up symlink
cd into usr/src/linux
zcat /proc/config.gz > .config
make olddefconfig
make menu_config (as a sanity check)
make
make modules_install
make install

I don't know what could have messed up the kernel tree other than
whatever magic happens behind the scenes in the various make commands.

Just now tried a make modules_prepare followed by an emerge -1 spl.  Same error.

Started again from scratch.  Moved the kernel tree I've been working
with (building kernel, modules, etc.) aside, then re-emerged
gentoo-sources.  Kernel tree should be pristine now, right?  Then
copied the config from my running kernel (same version 4.12.5) into
/usr/src/linux.  Then did a make modules_prepare.  Finally did an
emerge -1 spl.  Same error as always.  So, as attractive as the idea
of a messed up kernel tree is to me, I don't think that's the source
of the problem.

I think it would be informative if I could somehow see exactly what
commands are being run when the error occurs.  Is there a way of doing
that?

John

Re: [gentoo-user] zfs emerge failure

[Rich Freeman]

On Tue, Aug 15, 2017 at 5:19 PM, John Blinka  wrote:
>
> Hope someone can shed some light on continuing emerge failures for zfs
> since gnetoo-sources-4.4.39 and zfs-0.6.5.8.  I was able to install
> that version of zfs with that kernel last November on one of my
> machines, but have been unable to upgrade zfs since then, or to
> install it in any newer kernel, or even to re-install the same version
> on the same kernel.

I've been running various zfs+4.4.y versions without issue on a stable
amd64 config (using upstream kernels).

Currently I'm on 0.7.1+4.4.82.

> checking kernel source version... Not found
> configure: error: *** Cannot find UTS_RELEASE definition.
>
...
>
> Googling around for the "Cannot find UTS_RELEASE" complaint reveals
> that a few people have encountered this problem over the years.  It
> appeared in those cases to be attributable to the user running the
> configuration script not having sufficient authority to read
> ./include/generated/utsrelease.h in the kernel tree.

I suspect your sources have gotten messed up in some way.  I've run
into issues like this when I do something like build a kernel with an
odd umask so that the portage user can't read the files it needs to
build a module.  Your chmod should have fixed that but there could be
something else going on.  It might just be that you didn't prepare the
sources?

I actually do all my kernel builds in a tmpfs under /var/tmp these
days which keeps my /usr/src/linux pristine.  (make O=/var/tmp/linux
modules_install and so on)  It does involve more building during
upgrades but I know everything is clean, and I prefer no-issues to
faster-builds.

In theory that isn't essential, but I would definitely just wipe out
/usr/src/linux and unpack clean kernel sources.  If you're using the
gentoo-sources package you can just rm -rf the symlink and the actual
tree, and just re-emerge the package and it will set up both.  If
you're using git then I'd probably wipe it and re-pull as I'm not sure
if a clean/reset will actually take care of all the permissions.

Then you need to run at least make oldconfig and make modules_prepare
before you can build a module against it.  Doing a full kernel build
is also fine.

-- 
Rich

[gentoo-user] zfs emerge failure

[John Blinka]

Hi, Gentoo,

Hope someone can shed some light on continuing emerge failures for zfs
since gnetoo-sources-4.4.39 and zfs-0.6.5.8.  I was able to install
that version of zfs with that kernel last November on one of my
machines, but have been unable to upgrade zfs since then, or to
install it in any newer kernel, or even to re-install the same version
on the same kernel.

Emerge fails consistently in the configuration phase for spl with the
following snippet in the log:

checking kernel source directory... /usr/src/linux
checking kernel build directory... /lib/modules/4.12.5-gentoo/build
checking kernel source version... Not found
configure: error: *** Cannot find UTS_RELEASE definition.

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/sys-kernel/spl-0.7.1/work/spl-0.7.1/config.log
 * ERROR: sys-kernel/spl-0.7.1::gentoo failed (configure phase):
 *   econf failed
 *
 * Call stack:
 *   ebuild.sh, line  115:  Called src_configure
 * environment, line 3831:  Called autotools-utils_src_configure
 * environment, line  614:  Called econf
'--docdir=/usr/share/doc/spl-0.7.1' '--bindir=/bin' '--sbindir=/sbin'
'--with-config=all' '--with-linux=/usr/src/linux'
'--with-linux-obj=/lib/modules/4.12.5-gentoo/build' '--disable-debug'
 *phase-helpers.sh, line  665:  Called __helpers_die 'econf failed'
 *   isolated-functions.sh, line  117:  Called die
 * The specific snippet of code:
 *   die "$@"

Googling around for the "Cannot find UTS_RELEASE" complaint reveals
that a few people have encountered this problem over the years.  It
appeared in those cases to be attributable to the user running the
configuration script not having sufficient authority to read
./include/generated/utsrelease.h in the kernel tree.   As far as I can
tell, I think I ought to have sufficient permission to read that file.
I've gone so far as to chmod 777 the entire kernel tree to ensure
sufficient access.  No luck with that "solution": same error.

I've tried strace on emerge to see if I could figure out what it's
doing when it's looking for UTS_RELEASE, but no luck  with that
either.  Nothing that I can find in Bugzilla, either, although that
could be due to inexperience in using it.

Any idea what could be going on, or how I could go about debugging it
more effectively?

Thanks,

John Blinka