hello -
we're using fai 5.0.3 and have been seeing a problem when there are two
or more simultaneous dirinstalls taking place on a ubuntu xenial/16.04
host. i haven't tested with newer versions of fai, but it looks like
/usr/lib/fai/updatebase hasn't changed that much between then and now.
(apologies in advance for the long lines...)
the problem appears to be with the bind mount of /dev into the
$FAI_ROOT/dev chroot and the subsequent devpts mount at
$FAI_ROOT/dev/pts. on our systems, this results in a shared(?) devpts
filesystem mounted repeatedly on the host's /dev/pts as well as
multiple times in the first dirinstall (/tmp/tmp.9TKUTDClPW below, both
dirinstalls in process):
devpts on
/dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
/dev/mapper/xenvg-beff2349--8d77--4ef3--9988--23d7ca0e2461.disk0-1 on
/tmp/tmp.9TKUTDClPW type ext4
(rw,relatime,block_validity,delalloc,barrier,user_xattr,acl)
/dev/mapper/xenvg-c10d187e--9fd6--4eb6--a916--19ade0447915.disk0-1 on
/tmp/tmp.OTjBmSXukS type ext4
(rw,relatime,block_validity,delalloc,barrier,user_xattr,acl)
tmpfs on
/tmp/tmp.9TKUTDClPW/var/lib/dpkg type tmpfs (rw,noatime)
tmpfs on
/tmp/tmp.OTjBmSXukS/var/lib/dpkg type tmpfs (rw,noatime)
proc on
/tmp/tmp.9TKUTDClPW/proc type proc (rw,relatime)
sysfs on
/tmp/tmp.9TKUTDClPW/sys type sysfs (rw,relatime)
udev on
/tmp/tmp.9TKUTDClPW/dev type devtmpfs
(rw,nosuid,relatime,size=12305280k,nr_inodes=3076320,mode=755)
devpts on
/tmp/tmp.9TKUTDClPW/dev/pts type devpts
(rw,relatime,mode=600,ptmxmode=000)
devpts on
/dev/pts type devpts
(rw,relatime,mode=600,ptmxmode=000)
proc on
/tmp/tmp.OTjBmSXukS/proc type proc (rw,relatime)
sysfs on
/tmp/tmp.OTjBmSXukS/sys type sysfs (rw,relatime)
udev on
/tmp/tmp.OTjBmSXukS/dev type devtmpfs
(rw,nosuid,relatime,size=12305280k,nr_inodes=3076320,mode=755)
devpts on
/tmp/tmp.OTjBmSXukS/dev/pts type devpts
(rw,relatime,mode=600,ptmxmode=000)
devpts on
/dev/pts type devpts
(rw,relatime,mode=600,ptmxmode=000)
devpts on
/tmp/tmp.9TKUTDClPW/dev/pts type devpts
(rw,relatime,mode=600,ptmxmode=000)
when that first dirinstall has completed, it tries to umount
everything. however, this fails since there is the
extraneous /tmp/tmp.9TKUTDClPW/dev/pts that is apparently still in use
until the second dirinstall also completes (i'm unclear on the exact
details of how/why). we're left with the first dirinstall error'ing
out:
The dirinstall took 369 seconds.
umount: /tmp/tmp.9TKUTDClPW/dev: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
Source hook: savelog.LAST.sh
ERRORS found in log files. See
/var/log/fai/instance4.us.archive.org/dirinstall-20180706_233705/error.log
and its root and /dev left in place:
/dev/mapper/xenvg-beff2349--8d77--4ef3--9988--23d7ca0e2461.disk0-1 on
/tmp/tmp.9TKUTDClPW type ext4
(rw,relatime,block_validity,delalloc,barrier,user_xattr,acl)
udev on
/tmp/tmp.9TKUTDClPW/dev type devtmpfs
(rw,nosuid,relatime,size=12305280k,nr_inodes=3076320,mode=755)
i looked at how the schroot package avoids this and it uses `mount --
private`. the attached patch applies that option to the $FAI_ROOT/dev
and $FAI_ROOT/dev/pts mounts set up via /usr/lib/fai/updatebase and
clears up this dirinstall problem. i'll be testing it early next week
to ensure it doesn't introduce any issues on a netbooted install; if
that works (and barring feedback/concerns) i'll then submit an mr to
the fai repo.
thanks...
andy
--
andrew bezella <abeze...@archive.org>
internet archive--- a/lib/updatebase 2016-04-08 15:36:40.617083832 -0700
+++ b/lib/updatebase 2018-07-06 16:32:01.763344155 -0700
@@ -10,8 +10,12 @@
if [ "$FAI_ACTION" = "install" -o "$FAI_ACTION" = "dirinstall" ]; then
mount -t proc proc $FAI_ROOT/proc
mount -t sysfs sysfs $FAI_ROOT/sys
- [ -f /etc/init.d/udev ] && mount --bind /dev $FAI_ROOT/dev
+ if [ -f /etc/init.d/udev ]; then
+ mount --bind /dev $FAI_ROOT/dev
+ mount --make-private $FAI_ROOT/dev
+ fi
mount -t devpts devpts $FAI_ROOT/dev/pts
+ mount --make-private $FAI_ROOT/dev/pts
# if libc is upgraded init u is called in chroot environment and
# then init will eat up much cpu time
