I have a large, complex application. I'm trying to run it from a boot CD, which is obviously read-only. But the application needs a large writable area. (A ramdisk won't cut it.) So I've managed to construct a chroot environment to make it look to the application as if it's running from a normal writable environment.
The trouble is, one of the first things the application tries to do is mount some devices that are already mounted. I was expecting the kernel to allow that, but it seems if you try to remount a device with different mount options, the
mount(2) call returns
EBUSY. I need to make that stop happening.
The application has no idea that it's being run in this slightly strange configuration. I don't really want to change the application code to make this work. Is there some way I can instruct the kernel to pretend to mount something read-only even though it's already mounted somewhere else as read-write?
OK, so people said the question is unclear. Let's try this again:
~# mount /dev/sdb1 /XData ~# mkdir /tmp/CD ~# mount --bind / /tmp/CD ~# mount -t overlayfs -o lowerdir=/tmp/CD,upperdir=/XData/Root,workdir=/XData/Work none /NewRoot ~# chroot /NewRoot ~# java /home/user7/app.jar
app.jar has no idea that I'm doing this, so it immediately tries to do
mount --ro /dev/sdb1 /XData
which fails. What I'm looking for is a way to make it not fail. I don't really want to alter the application JAR file, but I'm totally OK with altering the commands leading up to launching it. Basically I want
app.jar to think everything is normal and nothing weird is happening. But I'm having trouble figuring out how to do that.
(It seems if you try to mount something several times with the same options, the kernel is perfectly fine with that. But trying to mount with different options seems to upset it.)