Bug 1467299 - /proc is not available during chroot preparation in mock build
/proc is not available during chroot preparation in mock build
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mock (Show other bugs)
27
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Miroslav Suchý
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 1176888
  Show dependency treegraph
 
Reported: 2017-07-03 06:47 EDT by Jens Petersen
Modified: 2018-01-09 11:17 EST (History)
26 users (show)

See Also:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-01-02 11:25:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
script output from mock (1.13 MB, text/plain)
2017-07-21 10:02 EDT, David Shea
no flags Details

  None (edit)
Description Jens Petersen 2017-07-03 06:47:13 EDT
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 06:49:45 EDT
I opened a bug upstream too https://github.com/rpm-software-management/mock/issues/88
Comment 2 Miroslav Suchý 2017-07-03 08:45:45 EDT
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 07:35:21 EDT
It lists:

Requires(post): /sbin/install-info

though.

Is that not sufficient?
Comment 4 Miroslav Suchý 2017-07-04 11:21:58 EDT
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 01:41:45 EDT
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 02:25:42 EDT
libffi-3.1-12.fc27 and libffi-3.1-12.fc26
Comment 7 Fedora Update System 2017-07-05 03:00:20 EDT
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 14:49:20 EDT
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 03:15:37 EDT
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 12:50:56 EDT
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 07:28:18 EDT
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 08:54:13 EDT
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 05:09:06 EDT
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 10:15:31 EDT
> 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 01:34:58 EDT
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 05:59:41 EDT
I can't reproduce it at all =(

Can someone give me reliable reproducer?
Comment 17 David Shea 2017-07-21 10:02 EDT
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 04:08:46 EDT
Well, /dev is empty when it is installing package. You should rbind it from host system.
Comment 19 Igor Gnatenko 2017-07-22 04:12:52 EDT
no idea how to debug it, but _setup_devices() is not called.
Comment 20 Igor Gnatenko 2017-07-22 04:14:06 EDT
well, sure:

        if not util.USE_NSPAWN:
            self._setup_devices()
Comment 21 Jens Petersen 2017-07-25 07:58:59 EDT
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 13:12:43 EDT
I have absolutely no idea, I'm not mock developer ;)
Comment 23 Miroslav Suchý 2017-07-31 12:06:30 EDT
> 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 13:01:18 EDT
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 14:30:32 EDT
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 19:46:24 EDT
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 19:46:55 EDT
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 19:47:27 EDT
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 17:49:04 EDT
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 18:25:35 EDT
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-07 21:23:31 EDT
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 02:18:41 EDT
Great news, thanks a lot!
Comment 33 Fedora Update System 2017-08-10 12:55:04 EDT
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 17:18:49 EDT
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 04:19:38 EDT
David is right - I still see the errors in root.log too :-(
Comment 36 Jens Petersen 2017-08-14 05:03:46 EDT
How can we reproduce and debug this more?
Comment 37 Zbigniew Jędrzejewski-Szmek 2017-08-14 10:12:22 EDT
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 04:23:00 EDT
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 11:40:01 EDT
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 08:48:35 EDT
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 05:35:36 EDT
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 06:29:09 EDT
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 02:51:55 EDT
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 11:28:12 EDT
Is there any update on this?
Comment 45 Roman Joost 2017-09-10 23:06:38 EDT
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 08:50:33 EDT
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 03:53:39 EDT
(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 08:24:32 EST
Fixed in commit:
* b8b721b (HEAD -> devel) mount /proc and /sys before executing any PM command [RHBZ#1467299]
Comment 49 Jens Petersen 2017-11-29 05:07:58 EST
(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 07:28:30 EST
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 02:28:31 EST
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 04:03:40 EST
(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 05:32:50 EST
(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 07:57:07 EST
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 07:57:48 EST
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 07:58:28 EST
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 14:13:21 EST
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 14:43:34 EST
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 17:35:46 EST
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 11:25:49 EST
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 11:52:59 EST
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 11:17:47 EST
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.