search

projectatomic / atomic

Atomic Run Tool for installing/running/managing container images.
Other
527 stars 139 forks source link

atomic mount symbol lookup error #1018

Closed wdhif closed 7 years ago

wdhif commented 7 years ago

Hi,

After installing atomic from centos-extras, trying to do an atomic mount give this result.

# atomic mount busybox /root/busybox
/usr/bin/python2: symbol lookup error: /lib64/libostree-1.so.1: undefined symbol: g_file_enumerator_iterate
# rpm -q atomic skopeo docker
atomic-1.17.2-4.git2760e30.el7.x86_64
skopeo-0.1.19-1.el7.x86_64
docker-1.12.6-16.el7.centos.x86_64

Any idea on what is causing this ?

yuqi-zhang commented 7 years ago

So a couple of things:

  1. The correct usage of atomic mount requires a mountpoint (atomic mount $IMAGE $MOUNTPOINT)
  2. Is busybox a local image on your machine? For atomic mount to work the image must be local
  3. Is ostree on your machine? The error seems to be ostree related, which (assuming you're not using centos atomic host) could not be on your host.

Could you also add the debug flag and show me the output for atomic --debug mount ...

Thanks

wdhif commented 7 years ago

Thanks for the quick response

  1. Actually I was using a mountpoint, I just missed it in the issue description, my bad, I've edited it.
  2. The image is on my local machine.
  3. I'm not using CentOS Atomic Host but it seems that I do have ostree. 
    # rpm -q ostree
ostree-2017.5-1.el7.x86_64

    With the debug flag the output is the same.

    # atomic --debug mount busybox /root/test
/usr/bin/python2: symbol lookup error: /lib64/libostree-1.so.1: undefined symbol: g_file_enumerator_iterate

Thanks again for taking the time to check this.

yuqi-zhang commented 7 years ago

Essentially its a glib2 issue: https://bugzilla.redhat.com/show_bug.cgi?id=1371704

For now, if you don't need to use ostree related functionality, you can just remove the ostree package and atomic will just use the docker backend.

jlebon commented 7 years ago

The ostree package you're using is compiled with a newer glib2. We do need to more explicitly reference glib2 requirements in the package to make this fail at package install time (or e.g. pull in an updated glib2), which is what the RHBZ is tracking. You should be able to just yum update glib2.

wdhif commented 7 years ago

The yum update glib2 did the trick.

Good job and Thank you :)