Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 693394 - error: unpacking of archive failed on file /var/lock/lvm: cpio: mkdir failed - Resource temporarily unavailable
Summary: error: unpacking of archive failed on file /var/lock/lvm: cpio: mkdir failed ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: filesystem
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 693259 (view as bug list)
Depends On:
Blocks: F15Beta, F15BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2011-04-04 14:38 UTC by James Laska
Modified: 2013-09-02 06:55 UTC (History)
13 users (show)

Fixed In Version: filesystem-2.4.40-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-05 21:31:54 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description James Laska 2011-04-04 14:38:31 UTC 
Description of problem:

Installing a @core (text-install) of F-15-Beta fails when unpacking lvm2.  Closer inspection shows that /var/lock is not available in the /mnt/sysimage chroot during installation.

Version-Release number of selected component (if applicable):
 * systemd-22-1.fc15.x86_64
 * filesystem-2.4.39-1.fc15.x86_64

How reproducible:
 * 100%

Steps to Reproduce:
1. Perform a text-based F-15-Beta install
  
Actual results:

From /mnt/sysimage/root/install.log ...

Installing cronie-1.4.7-1.fc15.x86_64
Installing crontabs-1.11-2.20101115git.fc15.noarch
Installing kpartx-0.4.9-15.fc15.x86_64
Installing dmraid-events-1.0.0.rc16-15.fc15.x86_64
Installing dmraid-1.0.0.rc16-15.fc15.x86_64
Installing openssh-server-5.6p1-30.fc15.x86_64
Installing sendmail-8.14.4-20.fc15.x86_64
Installing lvm2-2.02.84-1.fc15.x86_64
error: unpacking of archive failed on file /var/lock/lvm: cpio: mkdir failed - Resource temporarily unavailable

Expected results:

The installer should not fail while installing packages that rely on /var/lock capabilities

Additional info:

* Packages appear to install in the proper order ...
    # grep -n "\(systemd\|filesystem\|lvm2\)-[0-9]" /mnt/sysimage/root/install.log
    4:Installing filesystem-2.4.39-1.fc15.x86_64
    164:Installing systemd-22-1.fc15.x86_64
    191:Installing lvm2-2.02.84-1.fc15.x86_64

* The /var/lock (or /run/lock) directory, doesn't exist
    # ls -l /mnt/sysimage/var/lock
    lrwxrwxrwx. 1 root root 11 Apr  4 10:10 /mnt/sysimage/var/lock -> ../run/lock

    # ls /mnt/sysimage/var/lock/lvm /mnt/sysimage/run/lock
    ls: cannot access /mnt/sysimage/var/lock/lvm: No such file or directory
    ls: cannot access /mnt/sysimage/run/lock: No such file or directory

    # ls /mnt/sysimage/var/run /mnt/sysimage/run
    /mnt/sysimage/run:
    console  faillock  netreport  plymouth  sepermit  setrans  utmp

    /mnt/sysimage/var/run:
    console  faillock  netreport  plymouth  sepermit  setrans  utmp
Comment 1 Lennart Poettering 2011-04-04 14:48:10 UTC 
Hm, we create that dir dynamically on boot. If it is missing in the anaconda chroot, then the chroot should probably create it together with /run itself, at the same place it mounts /proc, /sys and friends.
Comment 2 Lennart Poettering 2011-04-04 14:55:06 UTC 
Yeah, i think the chroot code should take responsibility for this. The same way it mounts /sys and /proc it should mount a tmpfs to /run, and then do mkdir -p -m 0755 /run/lock.
Comment 3 Chris Lumens 2011-04-04 16:13:38 UTC 
systemd creates this (and a bunch of other directories it sounds like) automatically as part of bootup, correct?  If so, this will only hit us on F15 as on rawhide, I'm ditching our own init and using systemd there.
Comment 4 Chris Lumens 2011-04-04 16:18:45 UTC 
Scratch that - you're talking about within /mnt/sysimage.  anaconda doesn't create /proc or /sys.  Those directories are all owned by the filesystem package and created when it is installed.  I'd suggest we treat these other directories the same way.
Comment 5 James Laska 2011-04-04 16:29:34 UTC 
(In reply to comment #4)
> Scratch that - you're talking about within /mnt/sysimage.  anaconda doesn't
> create /proc or /sys.  Those directories are all owned by the filesystem
> package and created when it is installed.  I'd suggest we treat these other
> directories the same way.

Adding filesystem maintainer, ovasik, to the cc list for input
Comment 6 Ondrej Vasik 2011-04-04 17:36:36 UTC 
Which input do you mean? 

Starting with this filesystem update, filesystem creates /var/run and /var/lock as symlinks to /run/ and /run/lock ... /run/ is created and owned by filesystem package, but /run/lock is owned by systemd package. So we need to have /run/lock on the system during the installation (before lvm2 package installation started) - doesn't really matter what will create this, as /run/ should be afaik tmpfs mounted and will not survive boot anyway.
Comment 7 Chris Lumens 2011-04-04 17:48:09 UTC 
*** Bug 693259 has been marked as a duplicate of this bug. ***
Comment 8 James Laska 2011-04-04 18:36:30 UTC 
(In reply to comment #6)
> Which input do you mean? 
> 
> Starting with this filesystem update, filesystem creates /var/run and /var/lock
> as symlinks to /run/ and /run/lock ... /run/ is created and owned by filesystem
> package, but /run/lock is owned by systemd package. So we need to have
> /run/lock on the system during the installation (before lvm2 package
> installation started)

So this means systemd should be responsible for this?  This is where i started with the bug, but I believe Lennart felt a different approach was needed.
Comment 9 Ondrej Vasik 2011-04-04 19:03:09 UTC 
IMHO systemd and its post scriptlet is definitely one possibility. Another possibility is probably installer. Firstboot is too late I guess... Any other idea?
Comment 10 Lennart Poettering 2011-04-04 19:32:52 UTC 
(In reply to comment #4)
> Scratch that - you're talking about within /mnt/sysimage.  anaconda doesn't
> create /proc or /sys.  Those directories are all owned by the filesystem
> package and created when it is installed.  I'd suggest we treat these other
> directories the same way.

But who mounts /proc into the chroot? That's not the filesystem rpm I am pretty sure. And that same code should also mount /run into the chroot (and do an mkdir in it)
Comment 11 Chris Lumens 2011-04-04 19:46:45 UTC 
We do the bind mounting, but we don't create those directories to begin with.  The filesystem package owns those directories.  anaconda shouldn't be creating the directories, as if we do then they won't be owned by any package on the installed system.
Comment 12 Ondrej Vasik 2011-04-04 20:07:17 UTC 
Chris, /run/lock is already owned by systemd package, so it will be owned by that package on the installed system. But it is created only after boot. 
Additionally, if created by anaconda, it should be only tmpfs anyway, so it will not survive the boot (and after boot everything should be handled by systemd itself) -> no unowned directory.
Comment 13 Ondrej Vasik 2011-04-04 20:08:49 UTC 
(but if you are still worried about it, we could probably discuss moving ownership of that directory to filesystem package with Lennart)
Comment 14 Bill Nottingham 2011-04-04 20:42:17 UTC 
I think it's best that /run/lock be owned by filesystem, not systemd; this introduces the least ordering issues. Having it ownedas a real directory in filesystem shouldn't cause any problems.
Comment 15 Ondrej Vasik 2011-04-05 07:40:50 UTC 
Maybe it is really easiest way ... I'll do a filesystem f15 update with /run/lock owned and created by filesystem package.
Comment 16 Eetu Huisman 2011-04-05 10:11:08 UTC 
I got my F15 installation blocked by this bug yesterday. Is there a workaround or am I forced to wait until a fix is released?
Comment 17 Ondrej Vasik 2011-04-05 10:48:53 UTC 
I'm not aware of any workaround - except not using filesystem-2.4.39-1.fc15 - filesystem-2.4.37-1.fc15 should work without troubles. Anyway, update will be there in just few minutes...
Comment 18 Fedora Update System 2011-04-05 10:51:42 UTC 
filesystem-2.4.39-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/filesystem-2.4.39-1.fc15
Comment 19 Ondrej Vasik 2011-04-05 10:56:08 UTC 
Please use https://admin.fedoraproject.org/updates/filesystem-2.4.40-1.fc15 link :) ...
Comment 20 Fedora Update System 2011-04-05 21:31:39 UTC 
filesystem-2.4.40-1.fc15 has been pushed to the Fedora 15 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.