From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: David Howells <dhowells@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
keyrings@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 'make O=' indigestion with module signing
Date: Thu, 11 Mar 2021 04:51:49 -0500 [thread overview]
Message-ID: <102790.1615456309@turing-police> (raw)
In-Reply-To: <860945.1615455241@warthog.procyon.org.uk>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1602 bytes --]
On Thu, 11 Mar 2021 09:34:01 +0000, David Howells said:
> Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
>
> > What i *expected* was that multiple builds with different O= would each
> > generate themselves a unique signing key and put it in their own O= directory
> > and stay out of each other's way.
>
> Hmmm... Works for me. I use separate build dirs all the time.
>
> What version of the kernel are you using and what's the build command line -
> in particular the full O= option?
This is linux-next as of yesterday. For testing, I've been using:
LANG=C make O=/tmp/arm64 V=1 ARCH=arm64 ASFLAGS='-mcpu=all' CROSS_COMPILE=/opt/aarch64/bin/aarch64-linux-gnu- certs/
and it insists on trying to make the certs in /usr/src/linux-next rather than /tmp/arm64:
make -f /usr/src/linux-next/scripts/Makefile.build obj=certs \
single-build= \
need-builtin=1 need-modorder=1
scripts/extract-cert /usr/src/linux-next/"certs/signing_key.pem" certs/signing_key.x509
At main.c:142:
- SSL error:0200100D:system library:fopen:Permission denied: ../crypto/bio/bss_file.c:69
- SSL error:2006D002:BIO routines:BIO_new_file:system lib: ../crypto/bio/bss_file.c:78
extract-cert: /usr/src/linux-next/certs/signing_key.pem: Permission denied
make[2]: *** [/usr/src/linux-next/certs/Makefile:106: certs/signing_key.x509] Error 1
make[1]: *** [/usr/src/linux-next/Makefile:1847: certs] Error 2
make[1]: Leaving directory '/tmp/arm64'
make: *** [Makefile:215: __sub-make] Error 2
Is it possible that it works for you because although you have
separate build dirs, it's still able to write to the source tree?
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2021-03-11 9:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 6:32 'make O=' indigestion with module signing Valdis Klētnieks
2021-03-11 9:34 ` David Howells
2021-03-11 9:51 ` Valdis Klētnieks [this message]
2021-03-11 10:49 ` David Howells
2021-03-11 11:44 ` Valdis Klētnieks
2021-03-11 12:04 ` David Howells
2021-03-12 0:55 ` Valdis Klētnieks
2021-03-12 9:01 ` David Howells
2021-03-12 9:06 ` Valdis Klētnieks
2021-03-12 11:19 ` [PATCH] certs: Clean up signing_key.pem and x509.genkey on make mrproper David Howells
2021-05-09 15:11 ` 'make O=' indigestion with module signing Ingo Molnar
2021-05-09 15:15 ` Ingo Molnar
2021-05-09 16:19 ` Ingo Molnar
2021-05-10 12:41 ` Ingo Molnar
2021-03-11 13:31 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=102790.1615456309@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.