Stretch initvm build fails on buster #233
Comments
|
I cannot reproduce the issue. The public key is referenced in the file and the packages are signed. Please try again. Maybe it was just a connection issue on your side. |
|
I tried three times and build fails always with the same error. I'm expecting default configuration to work and the problem is probably on my side. Exact version used for build: Keyring is available on file system of installer: In installer syslog I see following messages: |
|
You have a "stretey" (not stretch) repo defined. Maybe this causes the issue. |
|
Ah, I see. There are just some characters missing, right? |
|
I'm using default configuration without any changes at all. These are artifact because of copying from installer console. I've checked syslog with nano extra for this. Messages contains 'stretch', not 'stretey'. Do you know any way to copy logs from installer? |
|
I've checked contents of elbe-keyring.gpg in initrd for missing key (36AA35FF22BB8F84). Nothing is found. In my system it's available on trusted keyring. |
|
What is your host system? Maybe, if it is too old it does not support the hashing/signing algorithms that are used. |
|
Host system is debian Buster. I'm still investigating why elbe-keyring doesn't contain any actual ELBE keys. |
AndreySV
added a commit
to AndreySV/elbe
that referenced
this issue
Aug 21, 2019
if user's gnupg configuration file contained options to include other keyrings, then 'elbe-keyring' wasn't created at all gpg error message if gnupg conf has keyring option: gpg: keyblock resource '.../elbe/initvm/.elbe-in/elbe-keyring': No such file or directory gpg: key 0x36AA35FF22BB8F84: 1 signature not checked due to a missing key gpg: no writable keyring found: Not found gpg: error reading '[stdin]': General error gpg: import from '[stdin]' failed: General error gpg: Total number processed: 0 Because of that resulting 'elbe-keyring.gpg' didn't had any PGP keys specified in initvm.xml file. Another problem is that without '--no-options' keys from other user-defined keyrings leaked into resulting elbe-keyring.gpg installed into build vm. Closes Linutronix#233 Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
|
Okay, I can reproduce the issue now. Thanks for the patch! |
|
Thanks for merging. |
torbenh3
pushed a commit
that referenced
this issue
Aug 27, 2019
if user's gnupg configuration file contained options to include other keyrings, then 'elbe-keyring' wasn't created at all gpg error message if gnupg conf has keyring option: gpg: keyblock resource '.../elbe/initvm/.elbe-in/elbe-keyring': No such file or directory gpg: key 0x36AA35FF22BB8F84: 1 signature not checked due to a missing key gpg: no writable keyring found: Not found gpg: error reading '[stdin]': General error gpg: import from '[stdin]' failed: General error gpg: Total number processed: 0 Because of that resulting 'elbe-keyring.gpg' didn't had any PGP keys specified in initvm.xml file. Another problem is that without '--no-options' keys from other user-defined keyrings leaked into resulting elbe-keyring.gpg installed into build vm. Closes #233 Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by: Bastian Germann <bage@linutronix.de> Reviewed-by: Torben Hohn <torben.hohn@linutronix.de>
torbenh3
added a commit
that referenced
this issue
Aug 27, 2019
* move <src-opts> into <src-cdrom> node * Update Debian codenames (buster is stable now) * command init: don't use user's gnupg configuration file (Fixes: #233) * grubinstaller: enable UEFI (secure) boot with shim * fix grubinstall, when /var is separate partition (Fixes: #230) Signed-off-by: Torben Hohn <torben.hohn@linutronix.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
command
elbe initvm create elbe-init-big-machine.xmlfails at step 14 'Select and install software'. According to syslog d-i complains that elbe-* packages are unauthenticated, because of missing public key for elbe repositories.Host system:
Debian Buster (amd64),
ELBE 10 (from linuxtronix debian repo)
I've used
<noauth>tag as a workaround for this problem.The text was updated successfully, but these errors were encountered: