Date
1 - 3 of 3
Cloud Foundry deploy on suse
|
Youzhi Zhu
Hi all
We are trying to deploy cloud foundry on suse, now every CF module can start successfully, but when I push an app to CF, it occurred error, I checked the logs and found when start the container, the wshd process throw error "pivot_root: Invalid argument", anyone has seen this error before or anyone has deploy CF to other OS successfully except ubuntu?thanks. CF version is cf-release170 suse version is suse 12 with kernel 3.12.28-4-default
|
|
|
|
Matthew Sykes <matthew.sykes@...>
wshd is simply reporting [1] the pivot_root [2] failure. It looks like
toggle quoted messageShow quoted text
you're getting an EINVAL from the call which implies warden is running in an unexpected environment. If I were to guess, I'd say that the container depot does not live on an expected file system type or location... As far as I'm aware, no work has been done to make warden run under anything but Ubuntu or CentOS recently but it's possible someone has. If nobody else has any hints, you'll likely have to look through the code and work out what's going on. [1]: https://github.com/cloudfoundry/warden/blob/76010f2ba12e41d9e8755985ec874391fb3c962a/warden/src/wsh/wshd.c#L715 [2]: http://man7.org/linux/man-pages/man2/pivot_root.2.html
On Wed, Nov 4, 2015 at 7:27 AM, Youzhi Zhu <zhuyouzhi03(a)gmail.com> wrote:
Hi all --
Matthew Sykes matthew.sykes(a)gmail.com
|
|
|
|
Youzhi Zhu
Hi Matthew
toggle quoted messageShow quoted text
I also guess it is something wrong with the file system type, then I checked the file system type when mount rootfs_lucid64 to container depot path "mnt/", it's overlayfs for suse other than aufs for ubuntu10.04, but it does support overlayfs for if you changed to overlayfs on ubuntu10.04, the app can alslo be started successfully. After that I found when stack the container file system, the command "mount" exec with "-n" option, which means do not write the mount info to /etc/mtab, but when exec on suse, it does write to the /proc/mtab. Another strange phenomenon is that the mount command is called by "unshare -m", which means do not share mount namespace with the calling process, but I can see the mounted files in the calling UTS namespace in fact, even add the "--make-rprivate" option to command mount does not work. that confused me too much. 2015-11-04 23:37 GMT+08:00 Matthew Sykes <matthew.sykes(a)gmail.com>:
wshd is simply reporting [1] the pivot_root [2] failure. It looks like
|
|
|