atomic mount read-write mode broken in atomic-1.22.1 version

[navidshaikh]

latest version: atomic-1.22.1-1.gitd36c015.el7.centos.x86_64 Working version: atomic-1.20.1-9.git436cf5d.el7.centos.x86_64

Functionality broken: atomic mount -o rw $IMAGE $MOUNTPOINT

Issue:

• atomic mount will mount the image in read-only mode, even if rw option is provided.

Re-produce:

$  yum install atomic
$ docker pull registry.centos.org/centos/centos:latest
$ atomic mount -o rw registry.centos.org/centos/centos:latest /mnt
$ touch /mnt/foo
touch: cannot touch ‘/mnt/foo’: Read-only file system 

Expected behavior: With working version mentioned, mounted an image with rw option, the image will be mounted in read write mode.

[navidshaikh]

The older version of atomic will give the warning about not supported OverlayFS backend and returns with exit status 1

# rpm -q atomic
atomic-1.20.1-9.git436cf5d.el7.centos.x86_64

# atomic mount -o rw registry.centos.org/centos/centos /mnt
The OverlayFS backend does not support writeable mounts.

# echo $?
1

while the latest version doesn't warn about not supported OverlayFS backend and returns with exit status 0

# rpm -q atomic
atomic-1.22.1-1.gitd36c015.el7.centos.x86_64

# atomic mount -o rw registry.centos.org/centos/centos /mnt

# echo $?
0

[rhatdan]

@baude @giuseppe PTAL

[giuseppe]

PR here: https://github.com/projectatomic/atomic/pull/1223

[navidshaikh]

@rhatdan : Sinceoverlay2 is recommended and default storage option, we had to use devicemapper option for writable writable mounts (for atomic scanners).

What are recommendations on using devicemapper in production?

Writable mounts could be a possible use case, are there plans for overlay2 to support writable mounts ?

[rhatdan]

@navidshaikh Why do you need writable mounts for scanning? You should not be writing to the rootfs?

[navidshaikh]

Why do you need writable mounts for scanning? You should not be writing to the rootfs?

@rhatdan : We have a scanner which checks if there are available yum updates for image_under_test using

yum -q check-updates --installroot=$IMAGE_MOUNTPOINT

yum creates lock file in target $IMAGE_MOUNTPOINT to process updates. Given a read-only filesystem it complains

/scanin/_e60c69716e424d7bd4bad0bf2c9aa82eb98ed860db418846db2c1c32741f9f8c/var/log/yum.log
ovl: Error while doing RPMdb copy-up:

[Errno 30] Read-only file system: 
'/scanin/_e60c69716e424d7bd4bad0bf2c9aa82eb98ed860db418846db2c1c32741f9f8c/var/lib/rpm/.dbenv.lock'

Could not create lock at /scanin/_e60c69716e424d7bd4bad0bf2c9aa82eb98ed860db418846db2c1c32741f9f8c/var/run/yum.pid: 

[Errno 30] Read-only file system: '/scanin/_e60c69716e424d7bd4bad0bf2c9aa82eb98ed860db418846db2c1c32741f9f8c/var/run/yum.pid' 

Can't create lock file; exiting

[rhatdan]

Yuck.

[giuseppe]

can you mount the container and then add a tmpfs on top of it with overlayfs? That should solve the issue you have seen

[navidshaikh]

and then add a tmpfs on top of it with overlayfs

@giuseppe : Can you please help clarify "add a tmpfs on top of it with overlayfs"? As in, how to add another tmpfs on a mounted container?

[giuseppe]

@navidshaikh yes exactly, or you can use a temporary directory as the upper layer, something like:

mount -t overlay overlay -o lowerdir=mounted-container,upperdir=/tmp/somewhere/up,workdir=/tmp/somewhere/wd mounted-writeable

[rhatdan]

Perhaps that is something we could automate in the command, although we would have to point out that changes will be lost when the container is umounted.