-
Notifications
You must be signed in to change notification settings - Fork 63
apt-get update failed on overlay storage driver #74
Comments
Looks like a limitation due to 9p?
On a running container:
|
Above was distracted by |
I confirm that it fixes the problem by adding back 9p "cache=loose" mount option.
|
So this is a classic unlink-after-open use case. Applications use this pattern to create an anonymous file. 9p has special handling for write-after-open-unlink case but it seems it does not handle fstat-after-open-unlink. |
some related info
problem of overlay? |
It is a different issue than https://bugzilla.redhat.com/show_bug.cgi?id=1213602, which is caused by overlayfs when a file lives in the down layer, opening it RO and RW can result in data inconsistency. And its workaround is to do However, in our case, the operation pattern is:
So the file is in the upper layer in the first place. And above test program (and apt-get update) passes in a docker container backed by overlay. |
I observed the same error with https://bugzilla.redhat.com/show_bug.cgi?id=1213602 |
Did you see it from |
I saw it from |
That should be fixed by newer yum plugin, namingly |
no, the ovl plugin is present |
With the hack patch on 9p client (bergwolf/linux@084b4a5), I no longer see errors in both multiline cat and
|
Well, spoke too soon... Another run gave me a different error:
Although multiline cat still works:
|
The warning occurs because currently chown would fail in hyper container:
|
yum install still fails with:
And that's because
And it seems that 9p's permission check does not allow root to bypass it. May be related to qemu squashing user mapping?
|
The open() EACCESS failure boils down to qemu failing to create new files under a directory that it does not have write access to. However, since qemu is running as root, it is supposed to be able to create new files there.
The directory does not allow to be written by root.
Possibly the qemu process has lost CAP_DAC_OVERRIDE and CAP_CHOWN at some point. |
All qemu process capabilities are dropped by libvirt according to https://libvirt.org/drvqemu.html#securitycap As a result:
And it cannot bypass 9p directory permission check due to missing CAP_DAC_OVERRIDE. chown 9p files in a hyper container always fails as well due to QEMU process lacking CAP_CHOWN. |
update: The qemu 9p server does not support open()->unlink()->getattr() operation (fix available but not merged, http://patchwork.ozlabs.org/patch/626194/). kernel 9pfs client also needs fixing (patch available but not merged, https://github.com/ericvh/linux/commit/eaf70223eac094291169f5a6de580351890162a2). So the hack (https://github.com/hyperhq/hyperstart/blob/master/build/kernel_patch/0001-HACK-9P-always-use-cached-inode-to-fill-in-v9fs_vfs_.patch) is necessary until both above fixes are merged, which seems unlikely in near future. |
Step 6 : RUN apt-get update
---> Running in 33968afa2cb0
Ign http://archive.ubuntu.com trusty InRelease
Get:1 http://archive.ubuntu.com trusty-updates InRelease [65.9 kB]
E: Unable to determine file size for fd 7 - fstat (2: No such file or directory)
The text was updated successfully, but these errors were encountered: