Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error while composing atomic tree from centos container #599

Closed
jasonbrooks opened this issue Jan 30, 2017 · 6 comments
Closed

error while composing atomic tree from centos container #599

jasonbrooks opened this issue Jan 30, 2017 · 6 comments
Labels

Comments

@jasonbrooks
Copy link
Contributor

I hit an issue composing a centos atomic tree from a centos-based container. The compose errors out with:

error: gpgme_op_import() error: Inappropriate ioctl for device

See also: http://ask.projectatomic.io/en/question/3871/error-gpgme_op_import-error-inappropriate-ioctl-for-device-when-building-on-centos-7/

I tried upgrading to rpm-ostree-2017.1.8-1b7e35abecb7e8b49d552428b0204a2824ba6e8f.f4d2fc43cd0bf3e9b4455d88afb9f04983396013.el7.centos.x86_64 from centos continuous, and hit the same issue. The latest version of rpm-ostree w/o this issue is rpm-ostree.x86_64 0:2016.5-1.atomic.el7.

Composing from a centos VM works as expected.

@cgwalters cgwalters added the bug label Jan 31, 2017
@cgwalters
Copy link
Member

So it's libdnf's dnf_repo_download_import_public_key() calling into librepo code for this. Hmm..can you try deleting your --cachedir? I wonder if you had a corrupted/half downloaded gpg key. Offhand, it doesn't look like the code is robust against that.

@jasonbrooks
Copy link
Contributor Author

Ah, the CentOS-CR repo has gpgcheck=1, and changing that to 0 addresses the issue. I'll send a pr for that.

jasonbrooks added a commit to jasonbrooks/sig-atomic-buildscripts that referenced this issue Jan 31, 2017
@jasonbrooks
Copy link
Contributor Author

Maybe a better error message is in order, though.

@dustymabe
Copy link
Member

is there a reason why gpgcheck=1 shouldn't work? from the repo file it looks like you specify where the keyfile is so why would you not want to check?

@jasonbrooks
Copy link
Contributor Author

It's disabled in the rest of the .repo files already -- I don't think this has ever worked?

cgwalters pushed a commit to CentOS/sig-atomic-buildscripts that referenced this issue Feb 23, 2017
@cgwalters
Copy link
Member

This is a dup of rpm-software-management/libdnf#43

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants