Bug 693394
| Summary: | error: unpacking of archive failed on file /var/lock/lvm: cpio: mkdir failed - Resource temporarily unavailable | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James Laska <jlaska> |
| Component: | filesystem | Assignee: | Ondrej Vasik <ovasik> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | anaconda-maint-list, eh, johannbg, jonathan, jturner, lpoetter, metherid, moschleg, mschmidt, notting, ovasik, plautrba, vanmeeuwen+fedora |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | filesystem-2.4.40-1.fc15 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-05 21:31:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 657618 | ||
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. 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. 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. 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. (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 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. *** Bug 693259 has been marked as a duplicate of this bug. *** (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. IMHO systemd and its post scriptlet is definitely one possibility. Another possibility is probably installer. Firstboot is too late I guess... Any other idea? (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) 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. 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. (but if you are still worried about it, we could probably discuss moving ownership of that directory to filesystem package with Lennart) 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. Maybe it is really easiest way ... I'll do a filesystem f15 update with /run/lock owned and created by filesystem package. 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? 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... 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 Please use https://admin.fedoraproject.org/updates/filesystem-2.4.40-1.fc15 link :) ... 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. |
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