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 1052932 - /var/lock is not present in build chroot - tpm-tools fails to build cause opencryptoki can not be installed
Summary: /var/lock is not present in build chroot - tpm-tools fails to build cause ope...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F-ExcludeArch-ppc64le, PPC64LETracker
TreeView+ depends on / blocked
 
Reported: 2014-01-14 12:51 UTC by Marcin Juszkiewicz
Modified: 2014-05-29 09:00 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-29 09:00:29 UTC


Attachments (Terms of Use)

Description Marcin Juszkiewicz 2014-01-14 12:51:29 UTC
Description of problem:

When I tried to build "tpm-tools" package (for rawhide or fedora 20) build failed because "opencryptoki" was not installable due to lack of /var/lock/ directory (or rather /run/lock to which /var/lock was symlinked).

Version-Release number of selected component (if applicable):

1.1.35-fc21

How reproducible:

always

Steps to Reproduce:
1. fedpkg clone -a tpm-tools
2. cd tpm-tools
3. fedpkg mockbuild

Actual results:

(sorry for Polish messages)

DEBUG util.py:281:  Error unpacking rpm package opencryptoki-3.0-7.fc21.x86_64
DEBUG util.py:281:  błąd: rozpakowanie archiwum się nie powiodło na pliku /var/lock/opencryptoki: cpio: mkdir
DEBUG util.py:281:  błąd: opencryptoki-3.0-7.fc21.x86_64: instalacja nie powiodło się

Expected results:

"tpm-tools" package builds

Additional info:

Comment 1 Jaromír Cápík 2014-01-14 15:56:34 UTC
Bug 1045849 is related ...

Comment 2 Jaromír Cápík 2014-01-14 17:35:42 UTC
It seems opencryptoki needs to be fixed instead. It doesn't make sense to install anything into /var/lock as it is linked to /run/lock and therefore the installed content is erased with the reboot.

Comment 3 Marcin Juszkiewicz 2014-01-14 17:39:37 UTC
Changed component to opencryptoki then.

Comment 4 Rex Dieter 2014-01-15 14:28:09 UTC
After some discussion on irc, we concluded *someone* needs the job to ensure that /run/lock (target of filesystem's /var/lock symlink) needs to exist at systemd package install time.    IMHO, I think the best place to implement that is systemd package itself.

Options include:
* systemd run it's own tmpfile-related scriptlets in %post to create/populate /run/lock (and friends).  Ideally accompanied by %ghost of them, so they are owned (currently /run/lock is unowned)
* or just create/own /run/lock is a regular dir
* ... or some better implementation idea

(not sure why rawhide is seeing this problem when apparently related f20 bug #1045849 is marked fixed already)

Comment 5 Clark Williams 2014-01-15 20:57:03 UTC
I've been looking at adding a mechanism for the mock config file to specify extra directories to setup in the chroot and finally added the 'extra_chroot_dirs' config option. I modified the f19, f20 and rawhide configs to have the line:

    config_opts['extra_chroot_dirs'] = ['/run/lock', ]

Mock 1.36 for f19 and up will create /run/lock while initializing the chroot framework.

Comment 6 Lennart Poettering 2014-01-23 13:25:22 UTC
This is something really between yum and mock, they set up the really basic directory tree, not systemd. Reassigning.

Comment 7 Rex Dieter 2014-01-23 13:31:37 UTC
Doesn't answer my query in comment #4 , why does systemd (or *some* package) not own /run/lock ?

Comment 8 Rex Dieter 2014-01-23 14:45:42 UTC
Relatedly, filesystem %changelog mentions:

* Wed Jun 20 2013 Ondrej Vasik <ovasik@redhat.com> - 3.2-16
- /var/run and /var/lock can't be in payload for some reason

wonder what "some reason" means.  maybe there is more going on.

Comment 9 Rex Dieter 2014-01-23 14:58:43 UTC
CC: ovasik ...

Ondrej, can you help explain why filesystem pkg doesn't own /var/lock ?

Comment 10 Zbigniew Jędrzejewski-Szmek 2014-01-23 15:00:10 UTC
(In reply to Rex Dieter from comment #8)
They used to be dirs and cannot be converted to symlinks and stored in the rpm because of RPM inaneness.

Comment 11 Rex Dieter 2014-01-23 15:10:42 UTC
Actually, filesystem pkg does already include the 
%pretrans -p <lua>
magic to workaround that (largely).  The prior commit was about trying to own the symlink as a dir, which is apparently bad. (workaround was to use %ghost instead).
 

More irc conversation, and I realized the filesystem comment was about /var/lock (not /run/lock), and that it has never tried to own /run/lock too.  So, lets amend the question to:

Ondrej, any objections/comments about filesystem owning /run/lock dir ?


This case of /var/lock (symlink) and /var/run (target dir) isn't much different that the situation of /var/run (symlink) and /run (target dir)

Comment 12 Ondrej Vasik 2014-01-23 15:58:40 UTC
Well, filesystem already owned /run/lock (#693394) - and I'm fine with owning it again if necessary - this drop was requested by systemd guys (Kay Sievers namely) - http://pkgs.fedoraproject.org/cgit/filesystem.git/commit/?id=5a403cd70564264b9bb7a5e2b3f1a6351c2f4ad8 - to address the "symlinked /var" related yum buildroot issue with dirs ending up in /var instead of symlinks to /run/ . It seems that it would be better to fix the yum buildroot issue instead of removing the /run/lock dir ownership (or to see if the /run/lock ownership removal was really necessary there).

Comment 13 Rex Dieter 2014-01-23 16:46:31 UTC
Interesting, bug #693394 is essentially the same as this bug (obviously something has regressed), and comment 14 basically says filesystem should own /run/lock too.  I *think* the dropping of /run/lock ownership was either not intended or not required to fix the prior issue(s).

I'm (still) of a mind to recommend moving forward with filesystem owning /run/lock dir, unless evidence or rationale comes to suggest doing otherwise.

Comment 14 Ondrej Vasik 2014-01-23 18:19:40 UTC
Don't know, adding Kay Sievers to CC - he may recall some reason for it. If not, I'll return /run/lock ownership back to filesystem.

Comment 15 Harald Hoyer 2014-03-13 11:51:07 UTC
How can you own /run/lock? /run is on tmpfs and should be correctly mounted and setup prior to installation.
Either by the initramfs, mock, anaconda or whatever provides a root/chroot to be installed to.

Comment 16 Ondrej Vasik 2014-03-13 12:31:05 UTC
Someone needs to own /run/lock - no matter who. In filesystem, it would be just %ghost ownership, and mkdir-ed in the pretrans of the setup installation. That way, /run/lock will be there even during the mock installation - and after cleanup, systemd will create it again in the brand new tmpfs after reboot.

Comment 17 Michal Sekletar 2014-03-21 09:19:50 UTC
Please note new --boot option added to systemd-tmpfiles not so long ago. In tmpfiles.d configuration files it is now possible to mark entries with exclamation mark, meaning that it is possible to execute action according to entry in question *only* during system boot and it might possibly break running system if executed at later time. 

Also note tmpfiles.d/legacy.conf, that /run/lock is not marked with !, thus I propose adding call to systemd-tmpfiles (without --boot of course) to systemd %post. This would assure existence of the directory on both, rootfs as well as in chroot. I am not 100% sure if systemd would be installed earlier in the transaction as component which needs directory, but I think we should at least consider this option. Might solve similar issues for some rather legacy daemons too. Just my 2¢...

Comment 18 Miroslav Suchý 2014-04-02 14:03:33 UTC
Anyway this directory is created by mock (since mock-1.1.36) so original issue reported against mock should be fixed.
Can you please confirm it?

Comment 19 Marcin Juszkiewicz 2014-04-02 14:28:16 UTC
trace-cmd built fine: https://brewweb.devel.redhat.com/buildinfo?buildID=343808

Comment 20 Miroslav Suchý 2014-04-02 14:39:41 UTC
Closing per #19 and #5.

Comment 21 Pavel Raiskup 2014-05-27 12:42:31 UTC
Weird, please close this bugreport if you see something what I don't.

Looking at mock profiles on my machine (f20, mock 1.1.38), I see the hack
  config_opts['extra_chroot_dirs'] = [ '/run/lock', ]

This results in something like this in mock lock:
  ....
  DEBUG: ensuring that dir exists: /var/lib/mock/fedora-20-x86_64/root/sys
  DEBUG: ensuring that dir exists: /var/lib/mock/fedora-20-x86_64/root/run/lock
  ...

But in ..
(In reply to Marcin Juszkiewicz from comment #19)
> trace-cmd built fine:
> https://brewweb.devel.redhat.com/buildinfo?buildID=343808

.. this build, I don't see such output.  I am coming here to this bug because
of the bug 1101325 (well, uucp should be fixed to provide the directory as
a %ghost probably but still, I don't think that the hack currently works.
Build of hylafax facing this issue:

https://koji.fedoraproject.org/koji/taskinfo?taskID=6894360

Comment 22 Michal Sekletar 2014-05-28 08:46:06 UTC
Yep, looks like fix in mock doesn't work and packages need to workaround that in %post. As I mentioned in comment #17 we can add %tmpfiles_create to systemd %post and that should fix this issue for most packages. FYI I went ahead and did exactly that in systemd for RHEL7 and I think we should do the same in Fedora too. Also we should keep in mind that this is not only about mock but also installing some package set via yum --installroot has the same problem.

Comment 23 Pavel Raiskup 2014-05-28 09:02:25 UTC
[OT, should have its own systemd bug]

(In reply to Michal Sekletar from comment #22)
> Yep, looks like fix in mock doesn't work and packages need to workaround
> that in %post.

If this is really workaround, what is proper fix?

> As I mentioned in comment #17 we can add %tmpfiles_create to systemd %post
> and that should fix this issue for most packages. FYI I went ahead and did
> exactly that in systemd for RHEL7 and I think we should do the same in
> Fedora too.

If the package is not installed together with systemd in one transaction?
Probably %posttrans would be better workaround?

[/OT]

Comment 24 Pavel Raiskup 2014-05-28 09:53:01 UTC
I split the systemd relevant issue into its own bug 1101983.

Comment 25 Rex Dieter 2014-05-28 14:59:10 UTC
Re: comment #23
> If this is really workaround, what is proper fix?

See comment #13 and comment #16 (imho)

Comment 26 Pavel Raiskup 2014-05-28 15:32:59 UTC
(In reply to Rex Dieter from comment #25)
> Re: comment #23
> > If this is really workaround, what is proper fix?
> 
> See comment #13 and comment #16 (imho)

Done via #1101983 fix.  Systemd should now create /var/lock in %post.  It is
still _not_ "owned" as it should be IMO (%ghost ownership would be OK), but
anyway, it should work.

Seems like package guidelines should be changed a little.  If (a) packages
_own_ some directory under /var/lock (non-ghost), they must have set correct
permissions on two places (the tmpfilesdir conf file and %dir
%files-statement).  These two permissions should really match.  (b) The
%package can %ghost own that directory and keep the permission just in conf
%file (but it must call tmpfiles_create in %post).

Still does not change the fact that config_opts['extra_chroot_dirs'] is broken,
thats why this is reopened.

Comment 27 Miroslav Suchý 2014-05-28 18:40:31 UTC
Ad #21 - according the log
  http://download.devel.redhat.com/brewroot/packages/trace-cmd/2.2.1/6.sa1.2/data/logs/aarch64/state.log
Brew use mock-1.1.35, while #5 say, that this was fixed in 1.1.36, talk to Brew owners about upgrading mock.

Comment 28 Pavel Raiskup 2014-05-29 05:38:37 UTC
Oh, sorry, comment #21 was partly bad.  The second link was hitting the bug:

from comment #21
> Build of hylafax facing this issue:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=6894360

Also this one (newer build):

https://kojipkgs.fedoraproject.org//packages/hylafax+/5.5.5/1.fc20/data/logs/x86_64/root.log

Comment 29 Miroslav Suchý 2014-05-29 09:00:29 UTC
Koji have separate configs for mock. And those config overwrited default mock config. Therefore this bug still appear in Fedora Koji.
I created:
  https://fedorahosted.org/fedora-infrastructure/ticket/4390


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