Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1467299 - /proc is not available during chroot preparation in mock build
Summary: /proc is not available during chroot preparation in mock build
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1176888
TreeView+ depends on / blocked
 
Reported: 2017-07-03 10:47 UTC by Jens Petersen
Modified: 2018-01-09 16:17 UTC (History)
26 users (show)

Fixed In Version: mock-1.4.3-1.fc26 mock-1.4.3-1.fc25 mock-1.4.3-1.el7 mock-1.4.8-1.fc26 mock-1.4.8-1.fc27 mock-1.4.8-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-02 16:25:49 UTC


Attachments (Terms of Use)
script output from mock (deleted)
2017-07-21 14:02 UTC, David Shea
no flags Details

Description Jens Petersen 2017-07-03 10:47:13 UTC
Description of problem:
The new "mock --new-chroot" default in copr is causing problems for building Haskell packages in Copr, due to errors in root.log from the install scripts:

eg https://copr-be.cloud.fedoraproject.org/results/petersen/hlint/fedora-rawhide-x86_64/00571545-hlint/root.log.gz

:
:
DEBUG util.py:450:  warning: %post(libffi-devel-3.1-11.fc27.x86_64) scriptlet failed, exit status 1
DEBUG util.py:450:    Installing       : ghc-compiler-8.0.2-57.fc26.x86_64                   96/149 
DEBUG util.py:450:    Running scriptlet: ghc-compiler-8.0.2-57.fc26.x86_64                   96/149 
DEBUG util.py:450:    Installing       : ghc-base-devel-4.9.1.0-57.fc26.x86_64               97/149 
DEBUG util.py:450:    Running scriptlet: ghc-base-devel-4.9.1.0-57.fc26.x86_64               97/149 
DEBUG util.py:450:  /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory
DEBUG util.py:450:    Installing       : ghc-transformers-devel-0.5.2.0-57.fc26.x86_64       98/149 
DEBUG util.py:450:    Running scriptlet: ghc-transformers-devel-0.5.2.0-57.fc26.x86_64       98/149 
DEBUG util.py:450:  /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory
DEBUG util.py:450:    Installing       : ghc-array-devel-0.5.1.1-57.fc26.x86_64              99/149 
DEBUG util.py:450:    Running scriptlet: ghc-array-devel-0.5.1.1-57.fc26.x86_64              99/149 
DEBUG util.py:450:  /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory
DEBUG util.py:450:    Installing       : ghc-deepseq-devel-1.4.2.0-57.fc26.x86_64           100/149 
DEBUG util.py:450:    Running scriptlet: ghc-deepseq-devel-1.4.2.0-57.fc26.x86_64           100/149 
DEBUG util.py:450:  /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory
DEBUG util.py:450:    Installing       : ghc-bytestring-devel-0.10.8.1-57.fc26.x86_64       101/149 
DEBUG util.py:450:    Running scriptlet: ghc-bytestring-devel-0.10.8.1-57.fc26.x86_64       101/149 
:
:

Version-Release number of selected component (if applicable):
mock-1.4.2-1
mock-1.3.4-1

How reproducible:
100%

Steps to Reproduce:
1. mock --new-chroot -r fedora-rawhide-x86_64 hlint-2.0.9-1.src.rpm

Actual results:
See above

Expected results:
No errors

Additional info:
There is no problem with "mock --old-chroot".

Comment 1 Jens Petersen 2017-07-03 10:49:45 UTC
I opened a bug upstream too https://github.com/rpm-software-management/mock/issues/88

Comment 2 Miroslav Suchý 2017-07-03 12:45:45 UTC
The error is because of:
```
DEBUG util.py:450:    Running scriptlet: libffi-devel-3.1-11.fc27.x86_64                     95/149 
DEBUG util.py:450:  install-info: No such file or directory for /dev/null
DEBUG util.py:450:  warning: %post(libffi-devel-3.1-11.fc27.x86_64) scriptlet failed, exit status 1
```

So libffi-devel calls in %postun /sbin/install-info  but `info` is not listed as requires of that package.

So the fix is that libffi should add
  Requires(post): info

to its spec file.

Comment 3 Jens Petersen 2017-07-04 11:35:21 UTC
It lists:

Requires(post): /sbin/install-info

though.

Is that not sufficient?

Comment 4 Miroslav Suchý 2017-07-04 15:21:58 UTC
That should be enough. It is strange. Why dnf did not installed `info` in #0? I am puzzled.

Comment 5 Jens Petersen 2017-07-05 05:41:45 UTC
I just protected the install-info scriplets, but I don't think that is the root problem.

http://pkgs.fedoraproject.org/cgit/rpms/libffi.git/commit/?id=e3a78d20c9b8e60087522e235b181644bc05eb0c

Comment 6 Jens Petersen 2017-07-05 06:25:42 UTC
libffi-3.1-12.fc27 and libffi-3.1-12.fc26

Comment 7 Fedora Update System 2017-07-05 07:00:20 UTC
libffi-3.1-12.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-190ee628d4

Comment 8 Fedora Update System 2017-07-05 18:49:20 UTC
libffi-3.1-12.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-190ee628d4

Comment 9 Jens Petersen 2017-07-06 07:15:37 UTC
I tested with:

mock --new-chroot --enablerepo=local -r fedora-rawhide-x86_64 hlint-2.0.9-1.src.rpm 

and even with libffi-3.1-12.fc27 and still get the same libHSterminfo-0.4.0.2-ghc8.0.2.so errors.

Comment 10 Fedora Update System 2017-07-08 16:50:56 UTC
libffi-3.1-12.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 11 Daniel Mach 2017-07-10 11:28:18 UTC
Minimal reproducer is:
mock -r fedora-rawhide-x86_64 init
# first install works fine
mock -r fedora-rawhide-x86_64 install libffi-devel
mock -r fedora-rawhide-x86_64 clean
# second install fails with: install-info: No such file or directory for /dev/null
mock -r fedora-rawhide-x86_64 install libffi-devel


Relevant part of strace:

7414  execve("/sbin/install-info", ["/sbin/install-info", "--delete", "--info-dir=/usr/share/info", "/usr/share/info/libffi.info.gz"], 0x5648d76f2490 /* 24 vars */) = 0
7414  brk(NULL)                         = 0x55a49bacf000
7414  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb9cc9a7000
7414  access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
7414  openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
7414  fstat(3, {st_mode=S_IFREG|0644, st_size=13117, ...}) = 0
7414  mmap(NULL, 13117, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb9cc9a3000
7414  close(3)                          = 0
7414  openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
7414  read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\"\0\0\0\0\0\0"..., 832) = 832
7414  fstat(3, {st_mode=S_IFREG|0755, st_size=94104, ...}) = 0
7414  mmap(NULL, 2187272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb9cc56b000
7414  mprotect(0x7fb9cc581000, 2093056, PROT_NONE) = 0
7414  mmap(0x7fb9cc780000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7fb9cc780000
7414  mmap(0x7fb9cc781000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb9cc781000
7414  close(3)                          = 0
7414  openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
7414  read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\22\2\0\0\0\0\0"..., 832) = 832
7414  fstat(3, {st_mode=S_IFREG|0755, st_size=2261216, ...}) = 0
7414  mmap(NULL, 4090400, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb9cc184000
7414  mprotect(0x7fb9cc361000, 2097152, PROT_NONE) = 0
7414  mmap(0x7fb9cc561000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1dd000) = 0x7fb9cc561000
7414  mmap(0x7fb9cc567000, 14880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb9cc567000
7414  close(3)                          = 0
7414  mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb9cc9a0000
7414  arch_prctl(ARCH_SET_FS, 0x7fb9cc9a0700) = 0
7414  mprotect(0x7fb9cc561000, 16384, PROT_READ) = 0
7414  mprotect(0x7fb9cc780000, 4096, PROT_READ) = 0
7414  mprotect(0x55a499f76000, 4096, PROT_READ) = 0
7414  mprotect(0x7fb9cc9a9000, 4096, PROT_READ) = 0
7414  munmap(0x7fb9cc9a3000, 13117)     = 0
7414  brk(NULL)                         = 0x55a49bacf000
7414  brk(0x55a49baf0000)               = 0x55a49baf0000
7414  brk(NULL)                         = 0x55a49baf0000
7414  open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
7414  fstat(3, {st_mode=S_IFREG|0644, st_size=113015632, ...}) = 0
7414  mmap(NULL, 113015632, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb9c55bc000
7414  close(3)                          = 0
7414  openat(AT_FDCWD, "/dev/null", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  close(0)                          = 0
7414  open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 0
7414  fstat(0, {st_mode=S_IFREG|0644, st_size=2997, ...}) = 0
7414  read(0, "# Locale name alias data base.\n#"..., 4096) = 2997
7414  read(0, "", 4096)                 = 0
7414  close(0)                          = 0
7414  open("/usr/share/locale/cs_CZ.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs_CZ.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs_CZ/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs_CZ.UTF-8/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs_CZ.utf8/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs_CZ/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs.UTF-8/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs.utf8/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  open("/usr/share/locale/cs/LC_MESSAGES/texinfo.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
7414  write(2, "install-info: ", 14)    = 14
7414  write(2, "No such file or directory for /d"..., 39) = 39
7414  write(2, "\n", 1)                 = 1
7414  exit_group(1)                     = ?
7414  +++ exited with 1 +++

Comment 12 Miroslav Suchý 2017-07-10 12:54:13 UTC
Strange. While Dan was able to reproduce it (I was sitting beside him) I cannot reproduce it. It seems that neither systemd-nspawn nor selinux is the culprint (Dan tried both).
According the strace the /dev/null magically disappear for that scriptlet.

The strange part is that Dan was able to only reproduce it when running via mock. When he run that command by hand, then it worked flawlessly.

I suspect something in rpm. Can someone from rpm team investigate it?

Comment 13 Florian Festi 2017-07-12 09:09:06 UTC
I have a hard time believing that this is caused by rpm. The /dev/null we are talking here is the one from within the mock build root.

rpm -qf /dev/null 
file /dev/null is not owned by any package

So rpm should not even touch that file.

So to me it looks like mock fails to set up /dev properly in the build root.

Comment 14 Miroslav Suchý 2017-07-13 14:15:31 UTC
> So to me it looks like mock fails to set up /dev properly in the build root.

But if you run mock interactively, it exist.
Even if you run strace on mock it exists few lines above, but then suddenly disappear.

Comment 15 Elliott Sales de Andrade 2017-07-20 05:34:58 UTC
This /dev/null thing for install-info seems to affect more than just libffi-devel. If you run `mock --new-chroot -r fedora-26-x86_64 --scrub=all` first, then `mock --new-chroot -r fedora-26-x86_64 --init`, there are a few other cases:

   Installing  : readline-7.0-5.fc26.x86_64      31/164 
install-info: No such file or directory for /dev/null
install-info: No such file or directory for /dev/null

  Installing  : grep-3.1-1.fc26.x86_64           33/164 
install-info: No such file or directory for /dev/null

  Installing  : sed-4.4-1.fc26.x86_64            42/164 
install-info: No such file or directory for /dev/null

Comment 16 Igor Gnatenko 2017-07-21 09:59:41 UTC
I can't reproduce it at all =(

Can someone give me reliable reproducer?

Comment 17 David Shea 2017-07-21 14:02:54 UTC
Created attachment 1302424 [details]
script output from mock

Running mock with hlint or any other haskell package, like in the very first comment, still reproduces this bug. Attaching the output of building the current hlint package with mock-1.4.2-1.fc27.noarch and latest everything from rawhide.

Comment 18 Igor Gnatenko 2017-07-22 08:08:46 UTC
Well, /dev is empty when it is installing package. You should rbind it from host system.

Comment 19 Igor Gnatenko 2017-07-22 08:12:52 UTC
no idea how to debug it, but _setup_devices() is not called.

Comment 20 Igor Gnatenko 2017-07-22 08:14:06 UTC
well, sure:

        if not util.USE_NSPAWN:
            self._setup_devices()

Comment 21 Jens Petersen 2017-07-25 11:58:59 UTC
Is that sufficient to fix the issue in mock?


This issue is breaking all Haskell builds in copr! So it would be nice to have a fix or workaround soon. :)

Comment 22 Igor Gnatenko 2017-07-29 17:12:43 UTC
I have absolutely no idea, I'm not mock developer ;)

Comment 23 Miroslav Suchý 2017-07-31 16:06:30 UTC
> well, sure:

Because when using nspawn then /dev is being populated by systemd-nspawn. So mock should not touch it.

Comment 24 Jens Petersen 2017-07-31 17:01:18 UTC
Anything I can do to help with this?

This issue prevents building any haskell packages in Copr...

Any chance of adding a toggle in copr to turn off nspawn until this is fixed?

Comment 25 Miroslav Suchý 2017-08-06 18:30:32 UTC
OK. I found the culprint. This happen with initial population of chroot. I.e the /dev/null initialy exists, but when postscript is run, then because dnf is executed with --installroot and rpm is run inside the chroot. But /dev is not mounted there so /dev/null really does not exists yet. And we cannot rely on nspawn to populate because this is initial command which is not executed within chroot, but from host, because there is no binary installed in chroot yet.

So Igor was right in #20.

Commit 90e2485

Comment 26 Fedora Update System 2017-08-06 23:46:24 UTC
mock-1.4.3-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-53f9c9cb51

Comment 27 Fedora Update System 2017-08-06 23:46:55 UTC
mock-1.4.3-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-204acb9aa4

Comment 28 Fedora Update System 2017-08-06 23:47:27 UTC
mock-1.4.3-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4ee5b66a4c

Comment 29 Fedora Update System 2017-08-07 21:49:04 UTC
mock-1.4.3-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-53f9c9cb51

Comment 30 Fedora Update System 2017-08-07 22:25:35 UTC
mock-1.4.3-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4ee5b66a4c

Comment 31 Fedora Update System 2017-08-08 01:23:31 UTC
mock-1.4.3-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-204acb9aa4

Comment 32 Jens Petersen 2017-08-08 06:18:41 UTC
Great news, thanks a lot!

Comment 33 Fedora Update System 2017-08-10 16:55:04 UTC
mock-1.4.3-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 34 David Shea 2017-08-10 21:18:49 UTC
The original bug is still present. Installing the builddeps for haskell packages is full of errors along the lines of:

DEBUG util.py:450:  /usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory

and the build ultimately fails when it is unable to open /usr/lib64/ghc-8.0.2/package.conf.d/package.cache.

Comment 35 Jens Petersen 2017-08-14 08:19:38 UTC
David is right - I still see the errors in root.log too :-(

Comment 36 Jens Petersen 2017-08-14 09:03:46 UTC
How can we reproduce and debug this more?

Comment 37 Zbigniew Jędrzejewski-Szmek 2017-08-14 14:12:22 UTC
On up-to-date F26:
$ fedpkg clone ghc
$ fedpkg mockbuild
...
  Installing       : ghc-terminfo-0.4.0.2-59.fc27.x86_64                                                         31/132 
...
  Installing       : ghc-base-devel-4.9.1.0-59.fc27.x86_64                                                       99/132 
  Running scriptlet: ghc-base-devel-4.9.1.0-59.fc27.x86_64                                                       99/132 
/usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory
...

$ ldd /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/ghc-8.0.2/bin/ghc-pkg
	linux-vdso.so.1 (0x00007ffdbf7e2000)
	libHSterminfo-0.4.0.2-ghc8.0.2.so => /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/ghc-8.0.2/bin/../terminfo-0.4.0.2/libHSterminfo-0.4.0.2-ghc8.0.2.so (0x00007fa6fea87000)
...

$ rpm -q mock
mock-1.4.3-1.fc26.noarch

$ /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/ghc-8.0.2/bin/ghc-pkg
ghc-pkg: missing command
For usage information see 'ghc-pkg --help'.

$ sudo chroot /var/lib/mock/fedora-rawhide-x86_64/root/
# /usr/lib64/ghc-8.0.2/bin/ghc-pkg
/usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory

So the file is there, but it doesn't run from inside the chroot.

# strace /usr/lib64/ghc-8.0.2/bin/ghc-pkg
execve("/usr/lib64/ghc-8.0.2/bin/ghc-pkg", ["/usr/lib64/ghc-8.0.2/bin/ghc-pkg"], 0x7fff0e2ec2f0 /* 21 vars */) = 0
brk(NULL)                               = 0x14a9000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3e1b94d000
readlink("/proc/self/exe", 0x7ffff11744b0, 4096) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "tls/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=14855, ...}) = 0
mmap(NULL, 14855, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3e1b949000
close(3)                                = 0
openat(AT_FDCWD, "/lib64/tls/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/lib64/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64", {st_mode=S_IFDIR|0555, st_size=20480, ...}) = 0
openat(AT_FDCWD, "/usr/lib64/tls/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/usr/lib64/libHSterminfo-0.4.0.2-ghc8.0.2.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0555, st_size=20480, ...}) = 0
writev(2, [{iov_base="/usr/lib64/ghc-8.0.2/bin/ghc-pkg", iov_len=32}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra...

$ readelf -d /usr/lib64/ghc-8.0.2/bin/ghc-pkg|grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../terminfo-0.4.0.2:$ORIGIN/../ghc-boot-8.0.2:$ORIGIN/../ghc-boot-th-8.0.2:$ORIGIN/../Cabal-1.24.2.0:$ORIGIN/../process-1.4.3.0:$ORIGIN/../pretty-1.1.3.3:$ORIGIN/../directory-1.3.0.0:$ORIGIN/../unix-2.7.2.1:$ORIGIN/../time-1.6.0.1:$ORIGIN/../filepath-1.4.1.1:$ORIGIN/../binary-0.8.3.0:$ORIGIN/../containers-0.5.7.1:$ORIGIN/../bytestring-0.10.8.1:$ORIGIN/../deepseq-1.4.2.0:$ORIGIN/../array-0.5.1.1:$ORIGIN/../base-4.9.1.0:$ORIGIN/../integer-gmp-1.0.0.1:$ORIGIN/../ghc-prim-0.5.0.0:$ORIGIN/../rts]

So the observed errors are consistent with /proc not being mounted:
ghc-pkg doesn't load because rpath resolution is broken. $ORIGIN cannot be queried
without /proc.

I see two solutions:
1. change haskell packaging to use an rpath which is absolute and does not use $ORIGIN.
2. change mock to also populate /proc.

I guess option 2. is more realistic.

Comment 38 Jan Kurik 2017-08-15 08:23:00 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 39 David Shea 2017-08-18 15:40:01 UTC
Any progress on this? It looks like the same kind of thing as /dev, where it's not being populated when using nspawn but nspawn isn't used for setting up the chroot:

        if not util.USE_NSPAWN:
            self.managed_mounts = [
                FileSystemMountPoint(filetype='proc',
                                     device='mock_chroot_proc',
                                     path=rootObj.make_chroot_path('/proc')),
                FileSystemMountPoint(filetype='sysfs',
                                     device='mock_chroot_sys',
                                     path=rootObj.make_chroot_path('/sys')),
            ]

Comment 40 Fedora Update System 2017-08-22 12:48:35 UTC
mock-1.4.3-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 41 Jens Petersen 2017-08-23 09:35:36 UTC
Reopening

Thank you, Zbigniew

I could patch ghc to not use $ORIGIN as a workaround,
but I think it is better to fix mock for this of course.

Comment 42 Fedora Update System 2017-08-23 10:29:09 UTC
mock-1.4.3-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.

Comment 43 Jens Petersen 2017-08-25 06:51:55 UTC
Miroslav, asking again, any chance of an --old-chroot setup option in Copr
until this is fixed?

Can this be fixed easily in a similar way to /dev/ ?

Comment 44 David Shea 2017-09-08 15:28:12 UTC
Is there any update on this?

Comment 45 Roman Joost 2017-09-11 03:06:38 UTC
Yes I'd actually also be interested. Is there anything to help out here to get this working again?

Comment 46 Miroslav Suchý 2017-09-25 12:50:33 UTC
I cannot reproduce it. With mock-1.4.6.

fedpkg clone ghc
cd ghc
fedpkg mockbuild

I tried even f26 branch. There are some errors, but none related to /dev or /proc

Does it still happen to you?

Comment 47 Jens Petersen 2017-10-06 07:53:39 UTC
(In reply to Miroslav Suchý from comment #46)
> I cannot reproduce it. With mock-1.4.6.
> 
> fedpkg clone ghc
> cd ghc
> fedpkg mockbuild

No need to build the whole of ghc! :)

I suggest building any other Haskell package (ghc-*):
eg I have been testing with hlint.

> I tried even f26 branch. There are some errors, but none related to /dev or
> /proc

The errors are indirectly due to missing /proc as explained earlier
in comment 37.

> Does it still happen to you?

Yes

$ mock --new-chroot -r fedora-rawhide-x86_64  hlint-2.0.9-1.src.rpm
:
  Installing       : ghc-compiler-8.0.2-59.fc27.x86_64                   96/149 
  Running scriptlet: ghc-compiler-8.0.2-59.fc27.x86_64                   96/149 
  Installing       : ghc-base-devel-4.9.1.0-59.fc27.x86_64               97/149 
  Running scriptlet: ghc-base-devel-4.9.1.0-59.fc27.x86_64               97/149 
/usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory
  Installing       : ghc-transformers-devel-0.5.2.0-59.fc27.x86_64       98/149 
  Running scriptlet: ghc-transformers-devel-0.5.2.0-59.fc27.x86_64       98/149 
/usr/lib64/ghc-8.0.2/bin/ghc-pkg: error while loading shared libraries: libHSterminfo-0.4.0.2-ghc8.0.2.so: cannot open shared object file: No such file or directory
:
:
:

Comment 48 Miroslav Suchý 2017-11-10 13:24:32 UTC
Fixed in commit:
* b8b721b (HEAD -> devel) mount /proc and /sys before executing any PM command [RHBZ#1467299]

Comment 49 Jens Petersen 2017-11-29 10:07:58 UTC
(In reply to Miroslav Suchý from comment #48)
> Fixed in commit:
> * b8b721b (HEAD -> devel) mount /proc and /sys before executing any PM
> command [RHBZ#1467299]

Great, I don't see any errors when installing ghc-*-devel packages now.
So the commit seems to fix the issue now.
Maybe someone else can confirm too?

When can we expect a release and for it to be deployed on Copr? :-)

Comment 50 Miroslav Suchý 2017-11-29 12:28:30 UTC
There must be a release of Mock first (ETA December). Then it must hit Fedora stable (+ 4 days). Then it gets installed on Copr builders.

Comment 51 Jens Petersen 2017-12-06 07:28:31 UTC
It seems now many of the copr builders have mock-1.3.4 but some have 1.4.7.

Not sure if and when this changed, but I didn't know about.

Comment 52 clime 2017-12-07 09:03:40 UTC
(In reply to Jens Petersen from comment #51)
> It seems now many of the copr builders have mock-1.3.4 but some have 1.4.7.
> 
> Not sure if and when this changed, but I didn't know about.

There should be mock-1.3.4, which is the current version in infrastructure repos (1.4.7 was on builders that were spawned before mock-1.3.4 with epoch '2' got into production).

Comment 53 clime 2017-12-07 10:32:50 UTC
(In reply to Jens Petersen from comment #49)
> (In reply to Miroslav Suchý from comment #48)
> > Fixed in commit:
> > * b8b721b (HEAD -> devel) mount /proc and /sys before executing any PM
> > command [RHBZ#1467299]
> 
> Great, I don't see any errors when installing ghc-*-devel packages now.
> So the commit seems to fix the issue now.
> Maybe someone else can confirm too?
> 

Yes, the latest mock HEAD fixes also this build https://copr.fedorainfracloud.org/coprs/g/weldr/bdcs-haskell-deps/build/682256/. So it is now just matter of releasing it.

Comment 54 Fedora Update System 2017-12-22 12:57:07 UTC
mock-1.4.8-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e954edb1bb

Comment 55 Fedora Update System 2017-12-22 12:57:48 UTC
mock-1.4.8-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ac67357aa1

Comment 56 Fedora Update System 2017-12-22 12:58:28 UTC
mock-1.4.8-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0c8682fd2a

Comment 57 Fedora Update System 2017-12-23 19:13:21 UTC
mock-1.4.8-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e954edb1bb

Comment 58 Fedora Update System 2017-12-23 19:43:34 UTC
mock-1.4.8-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ac67357aa1

Comment 59 Fedora Update System 2017-12-23 22:35:46 UTC
mock-1.4.8-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0c8682fd2a

Comment 60 Fedora Update System 2018-01-02 16:25:49 UTC
mock-1.4.8-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 61 Fedora Update System 2018-01-02 16:52:59 UTC
mock-1.4.8-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 62 Fedora Update System 2018-01-09 16:17:47 UTC
mock-1.4.8-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.