* [PATCH] meta: Drop lazy and recursive unmounts
@ 2024-06-19 10:41 Anton Mikanovich
2024-06-26 6:31 ` Uladzimir Bely
2024-08-28 13:05 ` 'Florian Bezdeka' via isar-users
0 siblings, 2 replies; 16+ messages in thread
From: Anton Mikanovich @ 2024-06-19 10:41 UTC (permalink / raw)
To: isar-users; +Cc: Ilia Skochilov, Anton Mikanovich
From: Ilia Skochilov <iskochilov@ilbers.de>
Cleanup lazy and recursive unmounting because they just mask other
issues caused by wrong mounting.
Also remove umount || true usages for the same reason.
Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
Signed-off-by: Ilia Skochilov <iskochilov@ilbers.de>
---
meta/classes/deb-dl-dir.bbclass | 4 ++--
meta/classes/image.bbclass | 14 +++++++++-----
meta/classes/isar-events.bbclass | 2 +-
meta/classes/rootfs.bbclass | 10 +++++-----
meta/classes/sbuild.bbclass | 12 ++++++------
meta/classes/sdk.bbclass | 13 ++++++++++---
.../isar-bootstrap/isar-bootstrap.inc | 19 ++++++++++---------
.../sdk-files/files/README.sdk | 2 +-
scripts/mount_chroot.sh | 2 +-
9 files changed, 45 insertions(+), 33 deletions(-)
diff --git a/meta/classes/deb-dl-dir.bbclass b/meta/classes/deb-dl-dir.bbclass
index d36b7190..8e0243fe 100644
--- a/meta/classes/deb-dl-dir.bbclass
+++ b/meta/classes/deb-dl-dir.bbclass
@@ -27,7 +27,7 @@ debsrc_do_mounts() {
set -e
mkdir -p "${1}/deb-src"
mountpoint -q "${1}/deb-src" || \
- mount --bind "${DEBSRCDIR}" "${1}/deb-src"
+ mount -o bind,private "${DEBSRCDIR}" "${1}/deb-src"
EOSUDO
}
@@ -36,7 +36,7 @@ debsrc_undo_mounts() {
set -e
mkdir -p "${1}/deb-src"
mountpoint -q "${1}/deb-src" && \
- umount -l "${1}/deb-src"
+ umount "${1}/deb-src"
rm -rf "${1}/deb-src"
EOSUDO
}
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 4f774bbc..0a80273f 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -407,19 +407,23 @@ do_rootfs_finalize() {
fi
mountpoint -q '${ROOTFSDIR}/isar-apt' && \
- umount -l ${ROOTFSDIR}/isar-apt && \
+ umount '${ROOTFSDIR}/isar-apt' && \
rmdir --ignore-fail-on-non-empty ${ROOTFSDIR}/isar-apt
mountpoint -q '${ROOTFSDIR}/base-apt' && \
- umount -l ${ROOTFSDIR}/base-apt && \
+ umount '${ROOTFSDIR}/base-apt' && \
rmdir --ignore-fail-on-non-empty ${ROOTFSDIR}/base-apt
+ mountpoint -q '${ROOTFSDIR}/dev/pts' && \
+ umount '${ROOTFSDIR}/dev/pts'
+ mountpoint -q '${ROOTFSDIR}/dev/shm' && \
+ umount '${ROOTFSDIR}/dev/shm'
mountpoint -q '${ROOTFSDIR}/dev' && \
- umount -l ${ROOTFSDIR}/dev
+ umount '${ROOTFSDIR}/dev'
mountpoint -q '${ROOTFSDIR}/proc' && \
- umount -l ${ROOTFSDIR}/proc
+ umount '${ROOTFSDIR}/proc'
mountpoint -q '${ROOTFSDIR}/sys' && \
- umount -l ${ROOTFSDIR}/sys
+ umount '${ROOTFSDIR}/sys'
if [ -e "${ROOTFSDIR}/etc/apt/sources-list" ]; then
mv "${ROOTFSDIR}/etc/apt/sources-list" \
diff --git a/meta/classes/isar-events.bbclass b/meta/classes/isar-events.bbclass
index a6ba0a9e..f5061a8b 100644
--- a/meta/classes/isar-events.bbclass
+++ b/meta/classes/isar-events.bbclass
@@ -55,7 +55,7 @@ python build_completed() {
if basepath in line:
bb.debug(1, '%s left mounted, unmounting...' % line.split()[1])
subprocess.call(
- ["sudo", "umount", "-l", line.split()[1]],
+ ["sudo", "umount", line.split()[1]],
stdout=subprocess.DEVNULL,
stderr=subprocess.DEVNULL,
)
diff --git a/meta/classes/rootfs.bbclass b/meta/classes/rootfs.bbclass
index 498fbfd6..2e091e0c 100644
--- a/meta/classes/rootfs.bbclass
+++ b/meta/classes/rootfs.bbclass
@@ -37,11 +37,11 @@ rootfs_do_mounts() {
mountpoint -q '${ROOTFSDIR}/dev' || \
( mount -o bind,private /dev '${ROOTFSDIR}/dev' &&
mount -t tmpfs none '${ROOTFSDIR}/dev/shm' &&
- mount --bind /dev/pts '${ROOTFSDIR}/dev/pts' )
+ mount -o bind,private /dev/pts '${ROOTFSDIR}/dev/pts' )
mountpoint -q '${ROOTFSDIR}/proc' || \
mount -t proc none '${ROOTFSDIR}/proc'
mountpoint -q '${ROOTFSDIR}/sys' || \
- mount --rbind /sys '${ROOTFSDIR}/sys'
+ mount -o bind,private /sys '${ROOTFSDIR}/sys'
mount --make-rslave '${ROOTFSDIR}/sys'
# Mount isar-apt if the directory does not exist or if it is empty
@@ -51,7 +51,7 @@ rootfs_do_mounts() {
then
mkdir -p '${ROOTFSDIR}/isar-apt'
mountpoint -q '${ROOTFSDIR}/isar-apt' || \
- mount --bind '${REPO_ISAR_DIR}/${DISTRO}' '${ROOTFSDIR}/isar-apt'
+ mount -o bind,private '${REPO_ISAR_DIR}/${DISTRO}' '${ROOTFSDIR}/isar-apt'
fi
# Mount base-apt if 'ISAR_USE_CACHED_BASE_REPO' is set
@@ -59,7 +59,7 @@ rootfs_do_mounts() {
then
mkdir -p '${ROOTFSDIR}/base-apt'
mountpoint -q '${ROOTFSDIR}/base-apt' || \
- mount --bind '${REPO_BASE_DIR}' '${ROOTFSDIR}/base-apt'
+ mount -o bind,private '${REPO_BASE_DIR}' '${ROOTFSDIR}/base-apt'
fi
EOSUDO
@@ -360,7 +360,7 @@ rootfs_install_sstate_prepare() {
# tar --one-file-system will cross bind-mounts to the same filesystem,
# so we use some mount magic to prevent that
mkdir -p ${WORKDIR}/mnt/rootfs
- sudo mount --bind ${WORKDIR}/rootfs ${WORKDIR}/mnt/rootfs -o ro
+ sudo mount -o bind,private '${WORKDIR}/rootfs' '${WORKDIR}/mnt/rootfs' -o ro
lopts="--one-file-system --exclude=var/cache/apt/archives"
sudo tar -C ${WORKDIR}/mnt -cpSf rootfs.tar $lopts ${SSTATE_TAR_ATTR_FLAGS} rootfs
sudo umount ${WORKDIR}/mnt/rootfs
diff --git a/meta/classes/sbuild.bbclass b/meta/classes/sbuild.bbclass
index f1193c20..9c268281 100644
--- a/meta/classes/sbuild.bbclass
+++ b/meta/classes/sbuild.bbclass
@@ -40,14 +40,14 @@ EOF
cp -rf "${SCHROOT_CONF}/sbuild" "${SBUILD_CONF_DIR}"
sbuild_fstab="${SBUILD_CONF_DIR}/fstab"
- fstab_baseapt="${REPO_BASE_DIR} /base-apt none rw,bind 0 0"
+ fstab_baseapt="${REPO_BASE_DIR} /base-apt none rw,bind,private 0 0"
grep -qxF "${fstab_baseapt}" ${sbuild_fstab} || echo "${fstab_baseapt}" >> ${sbuild_fstab}
- fstab_pkgdir="${WORKDIR} /home/builder/${PN} none rw,bind 0 0"
+ fstab_pkgdir="${WORKDIR} /home/builder/${PN} none rw,bind,private 0 0"
grep -qxF "${fstab_pkgdir}" ${sbuild_fstab} || echo "${fstab_pkgdir}" >> ${sbuild_fstab}
if [ -d ${DL_DIR} ]; then
- fstab_downloads="${DL_DIR} /downloads none rw,bind 0 0"
+ fstab_downloads="${DL_DIR} /downloads none rw,bind,private 0 0"
grep -qxF "${fstab_downloads}" ${sbuild_fstab} || echo "${fstab_downloads}" >> ${sbuild_fstab}
fi
EOSUDO
@@ -98,7 +98,7 @@ insert_mounts() {
sudo -s <<'EOSUDO'
set -e
for mp in ${SCHROOT_MOUNTS}; do
- FSTAB_LINE="${mp%%:*} ${mp#*:} none rw,bind 0 0"
+ FSTAB_LINE="${mp%%:*} ${mp#*:} none rw,bind,private 0 0"
grep -qxF "${FSTAB_LINE}" ${SBUILD_CONF_DIR}/fstab || \
echo "${FSTAB_LINE}" >> ${SBUILD_CONF_DIR}/fstab
done
@@ -109,7 +109,7 @@ remove_mounts() {
sudo -s <<'EOSUDO'
set -e
for mp in ${SCHROOT_MOUNTS}; do
- FSTAB_LINE="${mp%%:*} ${mp#*:} none rw,bind 0 0"
+ FSTAB_LINE="${mp%%:*} ${mp#*:} none rw,bind,private 0 0"
sed -i "\|${FSTAB_LINE}|d" ${SBUILD_CONF_DIR}/fstab
done
EOSUDO
@@ -122,7 +122,7 @@ schroot_configure_ccache() {
sbuild_fstab="${SBUILD_CONF_DIR}/fstab"
- fstab_ccachedir="${CCACHE_DIR} /ccache none rw,bind 0 0"
+ fstab_ccachedir="${CCACHE_DIR} /ccache none rw,bind,private 0 0"
grep -qxF "${fstab_ccachedir}" ${sbuild_fstab} || echo "${fstab_ccachedir}" >> ${sbuild_fstab}
(flock 9
diff --git a/meta/classes/sdk.bbclass b/meta/classes/sdk.bbclass
index 71db6f3a..754fd4cd 100644
--- a/meta/classes/sdk.bbclass
+++ b/meta/classes/sdk.bbclass
@@ -92,9 +92,16 @@ sdkchroot_configscript () {
ROOTFS_POSTPROCESS_COMMAND:append:class-sdk = " sdkchroot_finalize"
sdkchroot_finalize() {
- sudo umount -R ${ROOTFSDIR}/dev || true
- sudo umount ${ROOTFSDIR}/proc || true
- sudo umount -R ${ROOTFSDIR}/sys || true
+ mountpoint -q "${ROOTFSDIR}/dev/pts" && \
+ sudo umount "${ROOTFSDIR}/dev/pts"
+ mountpoint -q "${ROOTFSDIR}/dev/shm" && \
+ sudo umount "${ROOTFSDIR}/dev/shm"
+ mountpoint -q "${ROOTFSDIR}/dev" && \
+ sudo umount "${ROOTFSDIR}/dev"
+ mountpoint -q "${ROOTFSDIR}/proc" && \
+ sudo umount "${ROOTFSDIR}/proc"
+ mountpoint -q "${ROOTFSDIR}/sys" && \
+ sudo umount "${ROOTFSDIR}/sys"
# Remove setup scripts
sudo rm -f ${ROOTFSDIR}/chroot-setup.sh ${ROOTFSDIR}/configscript.sh
diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
index faf22a50..6bc667e7 100644
--- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
+++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
@@ -341,7 +341,7 @@ do_bootstrap() {
echo "deb-src ${line}" >> "${ROOTFSDIR}/etc/apt/sources.list.d/base-apt.list"
mkdir -p ${ROOTFSDIR}/base-apt
- mount --bind ${REPO_BASE_DIR} ${ROOTFSDIR}/base-apt
+ mount -o bind,private "${REPO_BASE_DIR}" "${ROOTFSDIR}/base-apt"
else
install -v -m644 "${APTSRCS}" \
"${ROOTFSDIR}/etc/apt/sources.list.d/bootstrap.list"
@@ -378,10 +378,10 @@ do_bootstrap() {
# update APT
mount -o bind,private /dev ${ROOTFSDIR}/dev
- mount --bind /dev/pts ${ROOTFSDIR}/dev/pts
+ mount -o bind,private /dev/pts "${ROOTFSDIR}/dev/pts"
mount -t tmpfs none "${ROOTFSDIR}/dev/shm"
mount -t proc none ${ROOTFSDIR}/proc
- mount --rbind /sys ${ROOTFSDIR}/sys
+ mount -o bind,private /sys "${ROOTFSDIR}/sys"
mount --make-rslave ${ROOTFSDIR}/sys
export DEBIAN_FRONTEND=noninteractive
@@ -400,12 +400,13 @@ do_bootstrap() {
chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade -y \
-o Debug::pkgProblemResolver=yes
- umount -l "${ROOTFSDIR}/dev/shm"
- umount -l "${ROOTFSDIR}/dev/pts"
- umount -l "${ROOTFSDIR}/dev"
- umount -l "${ROOTFSDIR}/proc"
- umount -l "${ROOTFSDIR}/sys"
- umount -l "${ROOTFSDIR}/base-apt" || true
+ umount "${ROOTFSDIR}/dev/shm"
+ umount "${ROOTFSDIR}/dev/pts"
+ umount "${ROOTFSDIR}/dev"
+ umount "${ROOTFSDIR}/proc"
+ umount "${ROOTFSDIR}/sys"
+ mountpoint -q "${ROOTFSDIR}/base-apt" && \
+ umount "${ROOTFSDIR}/base-apt"
# Finalize debootstrap by setting the link in deploy
ln -Tfsr "${ROOTFSDIR}" "${DEPLOY_ISAR_BOOTSTRAP}"
diff --git a/meta/recipes-devtools/sdk-files/files/README.sdk b/meta/recipes-devtools/sdk-files/files/README.sdk
index 3e06d8c5..29c09950 100644
--- a/meta/recipes-devtools/sdk-files/files/README.sdk
+++ b/meta/recipes-devtools/sdk-files/files/README.sdk
@@ -29,7 +29,7 @@ $ sudo <sdk_rootfs>/mount_chroot.sh <sdk_rootfs>
Bind-mount the project into the rootfs:
-$ sudo mount -o bind /path/to/project <sdk_rootfs>/mnt
+$ sudo mount -o bind,private /path/to/project <sdk_rootfs>/mnt
If you have relocated the SDK previously for using option 1, you need to call
this next:
diff --git a/scripts/mount_chroot.sh b/scripts/mount_chroot.sh
index e238f1cc..122bb33b 100755
--- a/scripts/mount_chroot.sh
+++ b/scripts/mount_chroot.sh
@@ -2,7 +2,7 @@
set -e
-mount /tmp "$1/tmp" -o bind
+mount /tmp "$1/tmp" -o bind,private
mount proc "$1/proc" -t proc -o nosuid,noexec,nodev
mount sysfs "$1/sys" -t sysfs -o nosuid,noexec,nodev
mount devtmpfs "$1/dev" -t devtmpfs -o mode=0755,nosuid
--
2.34.1
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-06-19 10:41 [PATCH] meta: Drop lazy and recursive unmounts Anton Mikanovich
@ 2024-06-26 6:31 ` Uladzimir Bely
2024-08-28 13:05 ` 'Florian Bezdeka' via isar-users
1 sibling, 0 replies; 16+ messages in thread
From: Uladzimir Bely @ 2024-06-26 6:31 UTC (permalink / raw)
To: isar-users
On Wed, 2024-06-19 at 13:41 +0300, Anton Mikanovich wrote:
> From: Ilia Skochilov <iskochilov@ilbers.de>
>
> Cleanup lazy and recursive unmounting because they just mask other
> issues caused by wrong mounting.
> Also remove umount || true usages for the same reason.
>
> Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
> Signed-off-by: Ilia Skochilov <iskochilov@ilbers.de>
> ---
> meta/classes/deb-dl-dir.bbclass | 4 ++--
> meta/classes/image.bbclass | 14 +++++++++-----
> meta/classes/isar-events.bbclass | 2 +-
> meta/classes/rootfs.bbclass | 10 +++++-----
> meta/classes/sbuild.bbclass | 12 ++++++------
> meta/classes/sdk.bbclass | 13 ++++++++++---
> .../isar-bootstrap/isar-bootstrap.inc | 19 ++++++++++-------
> --
> .../sdk-files/files/README.sdk | 2 +-
> scripts/mount_chroot.sh | 2 +-
> 9 files changed, 45 insertions(+), 33 deletions(-)
Applied to next.
--
Best regards,
Uladzimir.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-06-19 10:41 [PATCH] meta: Drop lazy and recursive unmounts Anton Mikanovich
2024-06-26 6:31 ` Uladzimir Bely
@ 2024-08-28 13:05 ` 'Florian Bezdeka' via isar-users
2024-08-29 9:26 ` Anton Mikanovich
1 sibling, 1 reply; 16+ messages in thread
From: 'Florian Bezdeka' via isar-users @ 2024-08-28 13:05 UTC (permalink / raw)
To: Anton Mikanovich, isar-users; +Cc: Ilia Skochilov, Jan Kiszka
Hi all,
I'm not 100% sure, but it seems I'm facing some problems with this
patch. I know about the situation that we sporadically saw some
mounting issues and that patch tries to expose such issues.
At least my issue seems to reproduce to 100%...
See below...
On Wed, 2024-06-19 at 13:41 +0300, Anton Mikanovich wrote:
> From: Ilia Skochilov <iskochilov@ilbers.de>
>
> Cleanup lazy and recursive unmounting because they just mask other
> issues caused by wrong mounting.
> Also remove umount || true usages for the same reason.
>
> Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
> Signed-off-by: Ilia Skochilov <iskochilov@ilbers.de>
> ---
> meta/classes/deb-dl-dir.bbclass | 4 ++--
> meta/classes/image.bbclass | 14 +++++++++-----
> meta/classes/isar-events.bbclass | 2 +-
> meta/classes/rootfs.bbclass | 10 +++++-----
> meta/classes/sbuild.bbclass | 12 ++++++------
> meta/classes/sdk.bbclass | 13 ++++++++++---
> .../isar-bootstrap/isar-bootstrap.inc | 19 ++++++++++---------
> .../sdk-files/files/README.sdk | 2 +-
> scripts/mount_chroot.sh | 2 +-
> 9 files changed, 45 insertions(+), 33 deletions(-)
>
> diff --git a/meta/classes/deb-dl-dir.bbclass b/meta/classes/deb-dl-dir.bbclass
> index d36b7190..8e0243fe 100644
> --- a/meta/classes/deb-dl-dir.bbclass
> +++ b/meta/classes/deb-dl-dir.bbclass
> @@ -27,7 +27,7 @@ debsrc_do_mounts() {
> set -e
> mkdir -p "${1}/deb-src"
> mountpoint -q "${1}/deb-src" || \
> - mount --bind "${DEBSRCDIR}" "${1}/deb-src"
> + mount -o bind,private "${DEBSRCDIR}" "${1}/deb-src"
> EOSUDO
> }
>
> @@ -36,7 +36,7 @@ debsrc_undo_mounts() {
> set -e
> mkdir -p "${1}/deb-src"
> mountpoint -q "${1}/deb-src" && \
> - umount -l "${1}/deb-src"
> + umount "${1}/deb-src"
> rm -rf "${1}/deb-src"
> EOSUDO
> }
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 4f774bbc..0a80273f 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -407,19 +407,23 @@ do_rootfs_finalize() {
> fi
>
> mountpoint -q '${ROOTFSDIR}/isar-apt' && \
> - umount -l ${ROOTFSDIR}/isar-apt && \
> + umount '${ROOTFSDIR}/isar-apt' && \
> rmdir --ignore-fail-on-non-empty ${ROOTFSDIR}/isar-apt
>
> mountpoint -q '${ROOTFSDIR}/base-apt' && \
> - umount -l ${ROOTFSDIR}/base-apt && \
> + umount '${ROOTFSDIR}/base-apt' && \
> rmdir --ignore-fail-on-non-empty ${ROOTFSDIR}/base-apt
>
> + mountpoint -q '${ROOTFSDIR}/dev/pts' && \
> + umount '${ROOTFSDIR}/dev/pts'
> + mountpoint -q '${ROOTFSDIR}/dev/shm' && \
> + umount '${ROOTFSDIR}/dev/shm'
> mountpoint -q '${ROOTFSDIR}/dev' && \
> - umount -l ${ROOTFSDIR}/dev
> + umount '${ROOTFSDIR}/dev'
> mountpoint -q '${ROOTFSDIR}/proc' && \
> - umount -l ${ROOTFSDIR}/proc
> + umount '${ROOTFSDIR}/proc'
> mountpoint -q '${ROOTFSDIR}/sys' && \
> - umount -l ${ROOTFSDIR}/sys
> + umount '${ROOTFSDIR}/sys'
>
> if [ -e "${ROOTFSDIR}/etc/apt/sources-list" ]; then
> mv "${ROOTFSDIR}/etc/apt/sources-list" \
> diff --git a/meta/classes/isar-events.bbclass b/meta/classes/isar-events.bbclass
> index a6ba0a9e..f5061a8b 100644
> --- a/meta/classes/isar-events.bbclass
> +++ b/meta/classes/isar-events.bbclass
> @@ -55,7 +55,7 @@ python build_completed() {
> if basepath in line:
> bb.debug(1, '%s left mounted, unmounting...' % line.split()[1])
> subprocess.call(
> - ["sudo", "umount", "-l", line.split()[1]],
> + ["sudo", "umount", line.split()[1]],
> stdout=subprocess.DEVNULL,
> stderr=subprocess.DEVNULL,
> )
> diff --git a/meta/classes/rootfs.bbclass b/meta/classes/rootfs.bbclass
> index 498fbfd6..2e091e0c 100644
> --- a/meta/classes/rootfs.bbclass
> +++ b/meta/classes/rootfs.bbclass
> @@ -37,11 +37,11 @@ rootfs_do_mounts() {
> mountpoint -q '${ROOTFSDIR}/dev' || \
> ( mount -o bind,private /dev '${ROOTFSDIR}/dev' &&
> mount -t tmpfs none '${ROOTFSDIR}/dev/shm' &&
> - mount --bind /dev/pts '${ROOTFSDIR}/dev/pts' )
> + mount -o bind,private /dev/pts '${ROOTFSDIR}/dev/pts' )
> mountpoint -q '${ROOTFSDIR}/proc' || \
> mount -t proc none '${ROOTFSDIR}/proc'
> mountpoint -q '${ROOTFSDIR}/sys' || \
> - mount --rbind /sys '${ROOTFSDIR}/sys'
> + mount -o bind,private /sys '${ROOTFSDIR}/sys'
> mount --make-rslave '${ROOTFSDIR}/sys'
>
> # Mount isar-apt if the directory does not exist or if it is empty
> @@ -51,7 +51,7 @@ rootfs_do_mounts() {
> then
> mkdir -p '${ROOTFSDIR}/isar-apt'
> mountpoint -q '${ROOTFSDIR}/isar-apt' || \
> - mount --bind '${REPO_ISAR_DIR}/${DISTRO}' '${ROOTFSDIR}/isar-apt'
> + mount -o bind,private '${REPO_ISAR_DIR}/${DISTRO}' '${ROOTFSDIR}/isar-apt'
> fi
>
> # Mount base-apt if 'ISAR_USE_CACHED_BASE_REPO' is set
> @@ -59,7 +59,7 @@ rootfs_do_mounts() {
> then
> mkdir -p '${ROOTFSDIR}/base-apt'
> mountpoint -q '${ROOTFSDIR}/base-apt' || \
> - mount --bind '${REPO_BASE_DIR}' '${ROOTFSDIR}/base-apt'
> + mount -o bind,private '${REPO_BASE_DIR}' '${ROOTFSDIR}/base-apt'
> fi
>
> EOSUDO
> @@ -360,7 +360,7 @@ rootfs_install_sstate_prepare() {
> # tar --one-file-system will cross bind-mounts to the same filesystem,
> # so we use some mount magic to prevent that
> mkdir -p ${WORKDIR}/mnt/rootfs
> - sudo mount --bind ${WORKDIR}/rootfs ${WORKDIR}/mnt/rootfs -o ro
> + sudo mount -o bind,private '${WORKDIR}/rootfs' '${WORKDIR}/mnt/rootfs' -o ro
> lopts="--one-file-system --exclude=var/cache/apt/archives"
> sudo tar -C ${WORKDIR}/mnt -cpSf rootfs.tar $lopts ${SSTATE_TAR_ATTR_FLAGS} rootfs
> sudo umount ${WORKDIR}/mnt/rootfs
> diff --git a/meta/classes/sbuild.bbclass b/meta/classes/sbuild.bbclass
> index f1193c20..9c268281 100644
> --- a/meta/classes/sbuild.bbclass
> +++ b/meta/classes/sbuild.bbclass
> @@ -40,14 +40,14 @@ EOF
> cp -rf "${SCHROOT_CONF}/sbuild" "${SBUILD_CONF_DIR}"
> sbuild_fstab="${SBUILD_CONF_DIR}/fstab"
>
> - fstab_baseapt="${REPO_BASE_DIR} /base-apt none rw,bind 0 0"
> + fstab_baseapt="${REPO_BASE_DIR} /base-apt none rw,bind,private 0 0"
> grep -qxF "${fstab_baseapt}" ${sbuild_fstab} || echo "${fstab_baseapt}" >> ${sbuild_fstab}
>
> - fstab_pkgdir="${WORKDIR} /home/builder/${PN} none rw,bind 0 0"
> + fstab_pkgdir="${WORKDIR} /home/builder/${PN} none rw,bind,private 0 0"
> grep -qxF "${fstab_pkgdir}" ${sbuild_fstab} || echo "${fstab_pkgdir}" >> ${sbuild_fstab}
>
> if [ -d ${DL_DIR} ]; then
> - fstab_downloads="${DL_DIR} /downloads none rw,bind 0 0"
> + fstab_downloads="${DL_DIR} /downloads none rw,bind,private 0 0"
> grep -qxF "${fstab_downloads}" ${sbuild_fstab} || echo "${fstab_downloads}" >> ${sbuild_fstab}
> fi
> EOSUDO
> @@ -98,7 +98,7 @@ insert_mounts() {
> sudo -s <<'EOSUDO'
> set -e
> for mp in ${SCHROOT_MOUNTS}; do
> - FSTAB_LINE="${mp%%:*} ${mp#*:} none rw,bind 0 0"
> + FSTAB_LINE="${mp%%:*} ${mp#*:} none rw,bind,private 0 0"
> grep -qxF "${FSTAB_LINE}" ${SBUILD_CONF_DIR}/fstab || \
> echo "${FSTAB_LINE}" >> ${SBUILD_CONF_DIR}/fstab
> done
> @@ -109,7 +109,7 @@ remove_mounts() {
> sudo -s <<'EOSUDO'
> set -e
> for mp in ${SCHROOT_MOUNTS}; do
> - FSTAB_LINE="${mp%%:*} ${mp#*:} none rw,bind 0 0"
> + FSTAB_LINE="${mp%%:*} ${mp#*:} none rw,bind,private 0 0"
> sed -i "\|${FSTAB_LINE}|d" ${SBUILD_CONF_DIR}/fstab
> done
> EOSUDO
> @@ -122,7 +122,7 @@ schroot_configure_ccache() {
>
> sbuild_fstab="${SBUILD_CONF_DIR}/fstab"
>
> - fstab_ccachedir="${CCACHE_DIR} /ccache none rw,bind 0 0"
> + fstab_ccachedir="${CCACHE_DIR} /ccache none rw,bind,private 0 0"
> grep -qxF "${fstab_ccachedir}" ${sbuild_fstab} || echo "${fstab_ccachedir}" >> ${sbuild_fstab}
>
> (flock 9
> diff --git a/meta/classes/sdk.bbclass b/meta/classes/sdk.bbclass
> index 71db6f3a..754fd4cd 100644
> --- a/meta/classes/sdk.bbclass
> +++ b/meta/classes/sdk.bbclass
> @@ -92,9 +92,16 @@ sdkchroot_configscript () {
>
> ROOTFS_POSTPROCESS_COMMAND:append:class-sdk = " sdkchroot_finalize"
> sdkchroot_finalize() {
> - sudo umount -R ${ROOTFSDIR}/dev || true
> - sudo umount ${ROOTFSDIR}/proc || true
> - sudo umount -R ${ROOTFSDIR}/sys || true
> + mountpoint -q "${ROOTFSDIR}/dev/pts" && \
> + sudo umount "${ROOTFSDIR}/dev/pts"
> + mountpoint -q "${ROOTFSDIR}/dev/shm" && \
> + sudo umount "${ROOTFSDIR}/dev/shm"
> + mountpoint -q "${ROOTFSDIR}/dev" && \
> + sudo umount "${ROOTFSDIR}/dev"
> + mountpoint -q "${ROOTFSDIR}/proc" && \
> + sudo umount "${ROOTFSDIR}/proc"
> + mountpoint -q "${ROOTFSDIR}/sys" && \
> + sudo umount "${ROOTFSDIR}/sys"
>
> # Remove setup scripts
> sudo rm -f ${ROOTFSDIR}/chroot-setup.sh ${ROOTFSDIR}/configscript.sh
> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> index faf22a50..6bc667e7 100644
> --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> @@ -341,7 +341,7 @@ do_bootstrap() {
> echo "deb-src ${line}" >> "${ROOTFSDIR}/etc/apt/sources.list.d/base-apt.list"
>
> mkdir -p ${ROOTFSDIR}/base-apt
> - mount --bind ${REPO_BASE_DIR} ${ROOTFSDIR}/base-apt
> + mount -o bind,private "${REPO_BASE_DIR}" "${ROOTFSDIR}/base-apt"
> else
> install -v -m644 "${APTSRCS}" \
> "${ROOTFSDIR}/etc/apt/sources.list.d/bootstrap.list"
> @@ -378,10 +378,10 @@ do_bootstrap() {
>
> # update APT
> mount -o bind,private /dev ${ROOTFSDIR}/dev
That means that we mount /dev from "the host" into the rootfs/chroot
environment, right? "Submounts included", no?
I'm facing the following error with that. The isar build is executed
inside a container / pod running on a k8s cluster.
Inside the container the following steps are executed:
build-bookworm:
script:
- kas build <path-to-kas-file>
- sudo rm -rf build/tmp/work/debian-bookworm-amd64/buildchroot-target
The rm command triggers the following errors:
rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/shm': Device or resource busy
rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/termination-log': Device or resource busy
rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/mqueue': Device or resource busy
rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/pts': Device or resource busy
My assumption is that isar is not cleaning up all mounts. I think the
interesting part is about /dev/termination-log.
That device is mounted into the pod by the k8s infrastructure.
I think we should never mount that into the chroot, or make sure it is
properly unmounted again...
Any thoughts on that? Any additional information needed?
Florian
> - mount --bind /dev/pts ${ROOTFSDIR}/dev/pts
> + mount -o bind,private /dev/pts "${ROOTFSDIR}/dev/pts"
> mount -t tmpfs none "${ROOTFSDIR}/dev/shm"
> mount -t proc none ${ROOTFSDIR}/proc
> - mount --rbind /sys ${ROOTFSDIR}/sys
> + mount -o bind,private /sys "${ROOTFSDIR}/sys"
> mount --make-rslave ${ROOTFSDIR}/sys
>
> export DEBIAN_FRONTEND=noninteractive
> @@ -400,12 +400,13 @@ do_bootstrap() {
> chroot "${ROOTFSDIR}" /usr/bin/apt-get dist-upgrade -y \
> -o Debug::pkgProblemResolver=yes
>
> - umount -l "${ROOTFSDIR}/dev/shm"
> - umount -l "${ROOTFSDIR}/dev/pts"
> - umount -l "${ROOTFSDIR}/dev"
> - umount -l "${ROOTFSDIR}/proc"
> - umount -l "${ROOTFSDIR}/sys"
> - umount -l "${ROOTFSDIR}/base-apt" || true
> + umount "${ROOTFSDIR}/dev/shm"
> + umount "${ROOTFSDIR}/dev/pts"
> + umount "${ROOTFSDIR}/dev"
> + umount "${ROOTFSDIR}/proc"
> + umount "${ROOTFSDIR}/sys"
> + mountpoint -q "${ROOTFSDIR}/base-apt" && \
> + umount "${ROOTFSDIR}/base-apt"
>
> # Finalize debootstrap by setting the link in deploy
> ln -Tfsr "${ROOTFSDIR}" "${DEPLOY_ISAR_BOOTSTRAP}"
> diff --git a/meta/recipes-devtools/sdk-files/files/README.sdk b/meta/recipes-devtools/sdk-files/files/README.sdk
> index 3e06d8c5..29c09950 100644
> --- a/meta/recipes-devtools/sdk-files/files/README.sdk
> +++ b/meta/recipes-devtools/sdk-files/files/README.sdk
> @@ -29,7 +29,7 @@ $ sudo <sdk_rootfs>/mount_chroot.sh <sdk_rootfs>
>
> Bind-mount the project into the rootfs:
>
> -$ sudo mount -o bind /path/to/project <sdk_rootfs>/mnt
> +$ sudo mount -o bind,private /path/to/project <sdk_rootfs>/mnt
>
> If you have relocated the SDK previously for using option 1, you need to call
> this next:
> diff --git a/scripts/mount_chroot.sh b/scripts/mount_chroot.sh
> index e238f1cc..122bb33b 100755
> --- a/scripts/mount_chroot.sh
> +++ b/scripts/mount_chroot.sh
> @@ -2,7 +2,7 @@
>
> set -e
>
> -mount /tmp "$1/tmp" -o bind
> +mount /tmp "$1/tmp" -o bind,private
> mount proc "$1/proc" -t proc -o nosuid,noexec,nodev
> mount sysfs "$1/sys" -t sysfs -o nosuid,noexec,nodev
> mount devtmpfs "$1/dev" -t devtmpfs -o mode=0755,nosuid
> --
> 2.34.1
>
> --
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/20240619104126.105252-1-amikan%40ilbers.de.
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/dccfd6b9e590e3429f74a990648e27c4d5e25ff8.camel%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-08-28 13:05 ` 'Florian Bezdeka' via isar-users
@ 2024-08-29 9:26 ` Anton Mikanovich
2024-08-29 12:26 ` 'Florian Bezdeka' via isar-users
0 siblings, 1 reply; 16+ messages in thread
From: Anton Mikanovich @ 2024-08-29 9:26 UTC (permalink / raw)
To: Florian Bezdeka, isar-users; +Cc: Jan Kiszka, Baurzhan Ismagulov
28/08/2024 16:05, Florian Bezdeka wrote:
> Hi all,
>
> I'm not 100% sure, but it seems I'm facing some problems with this
> patch. I know about the situation that we sporadically saw some
> mounting issues and that patch tries to expose such issues.
>
> At least my issue seems to reproduce to 100%...
>
> See below...
>
> On Wed, 2024-06-19 at 13:41 +0300, Anton Mikanovich wrote:
>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
>> index faf22a50..6bc667e7 100644
>> --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
>> +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
>> @@ -341,7 +341,7 @@ do_bootstrap() {
>> echo "deb-src ${line}" >> "${ROOTFSDIR}/etc/apt/sources.list.d/base-apt.list"
>>
>> mkdir -p ${ROOTFSDIR}/base-apt
>> - mount --bind ${REPO_BASE_DIR} ${ROOTFSDIR}/base-apt
>> + mount -o bind,private "${REPO_BASE_DIR}" "${ROOTFSDIR}/base-apt"
>> else
>> install -v -m644 "${APTSRCS}" \
>> "${ROOTFSDIR}/etc/apt/sources.list.d/bootstrap.list"
>> @@ -378,10 +378,10 @@ do_bootstrap() {
>>
>> # update APT
>> mount -o bind,private /dev ${ROOTFSDIR}/dev
> That means that we mount /dev from "the host" into the rootfs/chroot
> environment, right? "Submounts included", no?
>
> I'm facing the following error with that. The isar build is executed
> inside a container / pod running on a k8s cluster.
>
> Inside the container the following steps are executed:
>
> build-bookworm:
> script:
> - kas build <path-to-kas-file>
> - sudo rm -rf build/tmp/work/debian-bookworm-amd64/buildchroot-target
>
> The rm command triggers the following errors:
>
> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/shm': Device or resource busy
> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/termination-log': Device or resource busy
> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/mqueue': Device or resource busy
> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/pts': Device or resource busy
>
> My assumption is that isar is not cleaning up all mounts. I think the
> interesting part is about /dev/termination-log.
> That device is mounted into the pod by the k8s infrastructure.
>
> I think we should never mount that into the chroot, or make sure it is
> properly unmounted again...
>
> Any thoughts on that? Any additional information needed?
>
> Florian
Hello Florian,
The line you are pointing to is inside isar-bootstrap preparations,
while your
error is pointing to busy mountpoints in sbuild-chroot, managed by
rootfs.bbclass.
Anyway private mount private mount does not forward or receive
propagations. It means no external submounts will be mounted inside
rootfs and
no Isar mounts will be mounted to external /dev.
Can you check which mountpoints are left after the build (before rm)?
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/9ecb2ac7-9abd-4782-8498-7c5216fc99ca%40ilbers.de.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-08-29 9:26 ` Anton Mikanovich
@ 2024-08-29 12:26 ` 'Florian Bezdeka' via isar-users
2024-09-06 14:34 ` Anton Mikanovich
0 siblings, 1 reply; 16+ messages in thread
From: 'Florian Bezdeka' via isar-users @ 2024-08-29 12:26 UTC (permalink / raw)
To: Anton Mikanovich, isar-users; +Cc: Jan Kiszka, Baurzhan Ismagulov
On Thu, 2024-08-29 at 12:26 +0300, Anton Mikanovich wrote:
> 28/08/2024 16:05, Florian Bezdeka wrote:
> > Hi all,
> >
> > I'm not 100% sure, but it seems I'm facing some problems with this
> > patch. I know about the situation that we sporadically saw some
> > mounting issues and that patch tries to expose such issues.
> >
> > At least my issue seems to reproduce to 100%...
> >
> > See below...
> >
> > On Wed, 2024-06-19 at 13:41 +0300, Anton Mikanovich wrote:
> > > diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> > > index faf22a50..6bc667e7 100644
> > > --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> > > +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> > > @@ -341,7 +341,7 @@ do_bootstrap() {
> > > echo "deb-src ${line}" >> "${ROOTFSDIR}/etc/apt/sources.list.d/base-apt.list"
> > >
> > > mkdir -p ${ROOTFSDIR}/base-apt
> > > - mount --bind ${REPO_BASE_DIR} ${ROOTFSDIR}/base-apt
> > > + mount -o bind,private "${REPO_BASE_DIR}" "${ROOTFSDIR}/base-apt"
> > > else
> > > install -v -m644 "${APTSRCS}" \
> > > "${ROOTFSDIR}/etc/apt/sources.list.d/bootstrap.list"
> > > @@ -378,10 +378,10 @@ do_bootstrap() {
> > >
> > > # update APT
> > > mount -o bind,private /dev ${ROOTFSDIR}/dev
> > That means that we mount /dev from "the host" into the rootfs/chroot
> > environment, right? "Submounts included", no?
> >
> > I'm facing the following error with that. The isar build is executed
> > inside a container / pod running on a k8s cluster.
> >
> > Inside the container the following steps are executed:
> >
> > build-bookworm:
> > script:
> > - kas build <path-to-kas-file>
> > - sudo rm -rf build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target
> >
> > The rm command triggers the following errors:
> >
> > rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/shm': Device or resource busy
> > rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/termination-log': Device or resource busy
> > rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/mqueue': Device or resource busy
> > rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/pts': Device or resource busy
> >
> > My assumption is that isar is not cleaning up all mounts. I think the
> > interesting part is about /dev/termination-log.
> > That device is mounted into the pod by the k8s infrastructure.
> >
> > I think we should never mount that into the chroot, or make sure it is
> > properly unmounted again...
> >
> > Any thoughts on that? Any additional information needed?
> >
> > Florian
>
> Hello Florian,
>
> The line you are pointing to is inside isar-bootstrap preparations,
> while your
> error is pointing to busy mountpoints in sbuild-chroot, managed by
> rootfs.bbclass.
> Anyway private mount private mount does not forward or receive
> propagations. It means no external submounts will be mounted inside
> rootfs and
> no Isar mounts will be mounted to external /dev.
> Can you check which mountpoints are left after the build (before rm)?
I think this is the relevant line from "mount":
tmpfs on /builds/<project>/build/tmp/work/debian-bookworm-amd64/sbuild-
chroot-target/1.0-r0/rootfs/dev type tmpfs
(rw,nosuid,size=65536k,mode=755,inode64)
Florian
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/8086840c9b7bcf8dbcd6d3141d493c87f9e6d5c8.camel%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-08-29 12:26 ` 'Florian Bezdeka' via isar-users
@ 2024-09-06 14:34 ` Anton Mikanovich
2024-10-01 11:59 ` 'Florian Bezdeka' via isar-users
0 siblings, 1 reply; 16+ messages in thread
From: Anton Mikanovich @ 2024-09-06 14:34 UTC (permalink / raw)
To: Florian Bezdeka, isar-users; +Cc: Jan Kiszka, Baurzhan Ismagulov
29/08/2024 15:26, Florian Bezdeka wrote:
> I think this is the relevant line from "mount":
>
> tmpfs on /builds/<project>/build/tmp/work/debian-bookworm-amd64/sbuild-
> chroot-target/1.0-r0/rootfs/dev type tmpfs
> (rw,nosuid,size=65536k,mode=755,inode64)
>
> Florian
So it is sbuild who should manage mount in this rootfs. Not sure how
this patch
influence on internal sbuild mount/unmount logic. But sbuild shouldn't
left any
mounts without any errors. Do you have any packages failed to be built?
Are there any lost schroot sessions running before external rm you have
issue
with? This can be checked with 'schroot -la' command.
You can also try to add some verbose to sbuild with following change:
diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
index bcc3f828..b54e3ab9 100644
--- a/meta/classes/dpkg.bbclass
+++ b/meta/classes/dpkg.bbclass
@@ -113,6 +113,8 @@ dpkg_runbuild() {
DSC_FILE=$(find ${WORKDIR} -maxdepth 1 -name
"${DEBIAN_SOURCE}_*.dsc" -print)
sbuild -A -n -c ${SBUILD_CHROOT} \
+ -D \
+ --chroot-setup-commands="mount" \
--host=${PACKAGE_ARCH} --build=${BUILD_ARCH} ${profiles} \
--no-run-lintian --no-run-piuparts --no-run-autopkgtest
--resolve-alternatives \
--bd-uninstallable-explainer=apt \
This will be very helpfull to get some build logs from your setup.
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/deeeb768-e3c4-43a4-a132-51fb51643f0b%40ilbers.de.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-09-06 14:34 ` Anton Mikanovich
@ 2024-10-01 11:59 ` 'Florian Bezdeka' via isar-users
2024-10-01 12:14 ` 'Jan Kiszka' via isar-users
2024-10-03 14:37 ` Baurzhan Ismagulov
0 siblings, 2 replies; 16+ messages in thread
From: 'Florian Bezdeka' via isar-users @ 2024-10-01 11:59 UTC (permalink / raw)
To: Anton Mikanovich, isar-users; +Cc: Jan Kiszka, Baurzhan Ismagulov
On Fri, 2024-09-06 at 17:34 +0300, Anton Mikanovich wrote:
> 29/08/2024 15:26, Florian Bezdeka wrote:
> > I think this is the relevant line from "mount":
> >
> > tmpfs on /builds/<project>/build/tmp/work/debian-bookworm-amd64/sbuild-
> > chroot-target/1.0-r0/rootfs/dev type tmpfs
> > (rw,nosuid,size=65536k,mode=755,inode64)
> >
> > Florian
>
> So it is sbuild who should manage mount in this rootfs. Not sure how
> this patch
> influence on internal sbuild mount/unmount logic. But sbuild shouldn't
> left any
> mounts without any errors. Do you have any packages failed to be built?
>
> Are there any lost schroot sessions running before external rm you have
> issue
> with? This can be checked with 'schroot -la' command.
This one, right after the build completed, delivers:
W: No chroots are defined in ‘/etc/schroot/schroot.conf’ or
‘/etc/schroot/chroot.d’
>
> You can also try to add some verbose to sbuild with following change:
>
> diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
> index bcc3f828..b54e3ab9 100644
> --- a/meta/classes/dpkg.bbclass
> +++ b/meta/classes/dpkg.bbclass
> @@ -113,6 +113,8 @@ dpkg_runbuild() {
> DSC_FILE=$(find ${WORKDIR} -maxdepth 1 -name
> "${DEBIAN_SOURCE}_*.dsc" -print)
>
> sbuild -A -n -c ${SBUILD_CHROOT} \
> + -D \
> + --chroot-setup-commands="mount" \
> --host=${PACKAGE_ARCH} --build=${BUILD_ARCH} ${profiles} \
> --no-run-lintian --no-run-piuparts --no-run-autopkgtest
> --resolve-alternatives \
> --bd-uninstallable-explainer=apt \
>
> This will be very helpfull to get some build logs from your setup.
I scanned the logs and searched for /dev mounts. Typical example:
tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-r0/temp/log.do_dpkg_build.18089
521:devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
At the end I still have one active /dev mount:
tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs (rw,nosuid,size=65536k,mode=755,inode64)
Trying to delete the sbuild-chroot-target delivers:
rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/shm': Device or resource busy
rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/termination-log': Device or resource busy
rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/mqueue': Device or resource busy
rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/pts': Device or resource busy
mqueue and termination-log are host specific. That might be the reason
why I can only reproduce in CI setups. k8s has some "specials" like
termination-log here.
It seems that the mount comes from the rootfs_postprocess task of
sbuild-chroot-target. Which task should undo/clean them up?
Florian
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/b631604383ed020ce51c0c3f75aa3693509c4293.camel%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-01 11:59 ` 'Florian Bezdeka' via isar-users
@ 2024-10-01 12:14 ` 'Jan Kiszka' via isar-users
2024-10-01 12:18 ` 'Florian Bezdeka' via isar-users
2024-10-03 14:37 ` Baurzhan Ismagulov
1 sibling, 1 reply; 16+ messages in thread
From: 'Jan Kiszka' via isar-users @ 2024-10-01 12:14 UTC (permalink / raw)
To: Florian Bezdeka, Anton Mikanovich, isar-users; +Cc: Baurzhan Ismagulov
On 01.10.24 13:59, Florian Bezdeka wrote:
> On Fri, 2024-09-06 at 17:34 +0300, Anton Mikanovich wrote:
>> 29/08/2024 15:26, Florian Bezdeka wrote:
>>> I think this is the relevant line from "mount":
>>>
>>> tmpfs on /builds/<project>/build/tmp/work/debian-bookworm-amd64/sbuild-
>>> chroot-target/1.0-r0/rootfs/dev type tmpfs
>>> (rw,nosuid,size=65536k,mode=755,inode64)
>>>
>>> Florian
>>
>> So it is sbuild who should manage mount in this rootfs. Not sure how
>> this patch
>> influence on internal sbuild mount/unmount logic. But sbuild shouldn't
>> left any
>> mounts without any errors. Do you have any packages failed to be built?
>>
>> Are there any lost schroot sessions running before external rm you have
>> issue
>> with? This can be checked with 'schroot -la' command.
>
> This one, right after the build completed, delivers:
>
> W: No chroots are defined in ‘/etc/schroot/schroot.conf’ or
> ‘/etc/schroot/chroot.d’
>
>>
>> You can also try to add some verbose to sbuild with following change:
>>
>> diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
>> index bcc3f828..b54e3ab9 100644
>> --- a/meta/classes/dpkg.bbclass
>> +++ b/meta/classes/dpkg.bbclass
>> @@ -113,6 +113,8 @@ dpkg_runbuild() {
>> DSC_FILE=$(find ${WORKDIR} -maxdepth 1 -name
>> "${DEBIAN_SOURCE}_*.dsc" -print)
>>
>> sbuild -A -n -c ${SBUILD_CHROOT} \
>> + -D \
>> + --chroot-setup-commands="mount" \
>> --host=${PACKAGE_ARCH} --build=${BUILD_ARCH} ${profiles} \
>> --no-run-lintian --no-run-piuparts --no-run-autopkgtest
>> --resolve-alternatives \
>> --bd-uninstallable-explainer=apt \
>>
>> This will be very helpfull to get some build logs from your setup.
>
> I scanned the logs and searched for /dev mounts. Typical example:
>
> tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-r0/temp/log.do_dpkg_build.18089
> 521:devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
> 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
>
> At the end I still have one active /dev mount:
> tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs (rw,nosuid,size=65536k,mode=755,inode64)
>
> Trying to delete the sbuild-chroot-target delivers:
>
> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/shm': Device or resource busy
> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/termination-log': Device or resource busy
> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/mqueue': Device or resource busy
> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/pts': Device or resource busy
>
> mqueue and termination-log are host specific. That might be the reason
> why I can only reproduce in CI setups. k8s has some "specials" like
> termination-log here.
>
> It seems that the mount comes from the rootfs_postprocess task of
> sbuild-chroot-target. Which task should undo/clean them up?
If you are building an image (image.bbclass), do_rootfs_finalize will
clean up. If no (see the initramfs issue), those mounts will stick.
Jan
--
Siemens AG, Technology
Linux Expert Center
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/174d07bf-30ca-4d64-b035-26f19905a5b5%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-01 12:14 ` 'Jan Kiszka' via isar-users
@ 2024-10-01 12:18 ` 'Florian Bezdeka' via isar-users
2024-10-01 12:28 ` 'Jan Kiszka' via isar-users
0 siblings, 1 reply; 16+ messages in thread
From: 'Florian Bezdeka' via isar-users @ 2024-10-01 12:18 UTC (permalink / raw)
To: Jan Kiszka, Anton Mikanovich, isar-users; +Cc: Baurzhan Ismagulov
On Tue, 2024-10-01 at 14:14 +0200, Jan Kiszka wrote:
> On 01.10.24 13:59, Florian Bezdeka wrote:
> > On Fri, 2024-09-06 at 17:34 +0300, Anton Mikanovich wrote:
> > > 29/08/2024 15:26, Florian Bezdeka wrote:
> > > > I think this is the relevant line from "mount":
> > > >
> > > > tmpfs on /builds/<project>/build/tmp/work/debian-bookworm-amd64/sbuild-
> > > > chroot-target/1.0-r0/rootfs/dev type tmpfs
> > > > (rw,nosuid,size=65536k,mode=755,inode64)
> > > >
> > > > Florian
> > >
> > > So it is sbuild who should manage mount in this rootfs. Not sure how
> > > this patch
> > > influence on internal sbuild mount/unmount logic. But sbuild shouldn't
> > > left any
> > > mounts without any errors. Do you have any packages failed to be built?
> > >
> > > Are there any lost schroot sessions running before external rm you have
> > > issue
> > > with? This can be checked with 'schroot -la' command.
> >
> > This one, right after the build completed, delivers:
> >
> > W: No chroots are defined in ‘/etc/schroot/schroot.conf’ or
> > ‘/etc/schroot/chroot.d’
> >
> > >
> > > You can also try to add some verbose to sbuild with following change:
> > >
> > > diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
> > > index bcc3f828..b54e3ab9 100644
> > > --- a/meta/classes/dpkg.bbclass
> > > +++ b/meta/classes/dpkg.bbclass
> > > @@ -113,6 +113,8 @@ dpkg_runbuild() {
> > > DSC_FILE=$(find ${WORKDIR} -maxdepth 1 -name
> > > "${DEBIAN_SOURCE}_*.dsc" -print)
> > >
> > > sbuild -A -n -c ${SBUILD_CHROOT} \
> > > + -D \
> > > + --chroot-setup-commands="mount" \
> > > --host=${PACKAGE_ARCH} --build=${BUILD_ARCH} ${profiles} \
> > > --no-run-lintian --no-run-piuparts --no-run-autopkgtest
> > > --resolve-alternatives \
> > > --bd-uninstallable-explainer=apt \
> > >
> > > This will be very helpfull to get some build logs from your setup.
> >
> > I scanned the logs and searched for /dev mounts. Typical example:
> >
> > tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-r0/temp/log.do_dpkg_build.18089
> > 521:devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
> > 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
> >
> > At the end I still have one active /dev mount:
> > tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs (rw,nosuid,size=65536k,mode=755,inode64)
> >
> > Trying to delete the sbuild-chroot-target delivers:
> >
> > rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/shm': Device or resource busy
> > rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/termination-log': Device or resource busy
> > rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/mqueue': Device or resource busy
> > rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/pts': Device or resource busy
> >
> > mqueue and termination-log are host specific. That might be the reason
> > why I can only reproduce in CI setups. k8s has some "specials" like
> > termination-log here.
> >
> > It seems that the mount comes from the rootfs_postprocess task of
> > sbuild-chroot-target. Which task should undo/clean them up?
>
> If you are building an image (image.bbclass), do_rootfs_finalize will
> clean up. If no (see the initramfs issue), those mounts will stick.
There is no do_rootfs_finalize task in the list of tasks:
20241001-074332.296794 do_fetch (805): log.do_fetch.805
20241001-074332.387021 do_unpack (969): log.do_unpack.969
20241001-074503.068122 do_rootfs_install (11792): log.do_rootfs_install.11792
20241001-074728.511151 do_rootfs_postprocess (18028): log.do_rootfs_postprocess.18028
20241001-074728.628202 do_rootfs (18057): log.do_rootfs.18057
20241001-074728.675634 do_sbuildchroot_deploy (18068): log.do_sbuildchroot_deploy.18068
Missing task dependency somewhere?
>
> Jan
>
> --
> Siemens AG, Technology
> Linux Expert Center
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/862fb2631df7a50757a28d19adde49a780456a2e.camel%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-01 12:18 ` 'Florian Bezdeka' via isar-users
@ 2024-10-01 12:28 ` 'Jan Kiszka' via isar-users
0 siblings, 0 replies; 16+ messages in thread
From: 'Jan Kiszka' via isar-users @ 2024-10-01 12:28 UTC (permalink / raw)
To: Florian Bezdeka, Anton Mikanovich, isar-users; +Cc: Baurzhan Ismagulov
On 01.10.24 14:18, Florian Bezdeka wrote:
> On Tue, 2024-10-01 at 14:14 +0200, Jan Kiszka wrote:
>> On 01.10.24 13:59, Florian Bezdeka wrote:
>>> On Fri, 2024-09-06 at 17:34 +0300, Anton Mikanovich wrote:
>>>> 29/08/2024 15:26, Florian Bezdeka wrote:
>>>>> I think this is the relevant line from "mount":
>>>>>
>>>>> tmpfs on /builds/<project>/build/tmp/work/debian-bookworm-amd64/sbuild-
>>>>> chroot-target/1.0-r0/rootfs/dev type tmpfs
>>>>> (rw,nosuid,size=65536k,mode=755,inode64)
>>>>>
>>>>> Florian
>>>>
>>>> So it is sbuild who should manage mount in this rootfs. Not sure how
>>>> this patch
>>>> influence on internal sbuild mount/unmount logic. But sbuild shouldn't
>>>> left any
>>>> mounts without any errors. Do you have any packages failed to be built?
>>>>
>>>> Are there any lost schroot sessions running before external rm you have
>>>> issue
>>>> with? This can be checked with 'schroot -la' command.
>>>
>>> This one, right after the build completed, delivers:
>>>
>>> W: No chroots are defined in ‘/etc/schroot/schroot.conf’ or
>>> ‘/etc/schroot/chroot.d’
>>>
>>>>
>>>> You can also try to add some verbose to sbuild with following change:
>>>>
>>>> diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
>>>> index bcc3f828..b54e3ab9 100644
>>>> --- a/meta/classes/dpkg.bbclass
>>>> +++ b/meta/classes/dpkg.bbclass
>>>> @@ -113,6 +113,8 @@ dpkg_runbuild() {
>>>> DSC_FILE=$(find ${WORKDIR} -maxdepth 1 -name
>>>> "${DEBIAN_SOURCE}_*.dsc" -print)
>>>>
>>>> sbuild -A -n -c ${SBUILD_CHROOT} \
>>>> + -D \
>>>> + --chroot-setup-commands="mount" \
>>>> --host=${PACKAGE_ARCH} --build=${BUILD_ARCH} ${profiles} \
>>>> --no-run-lintian --no-run-piuparts --no-run-autopkgtest
>>>> --resolve-alternatives \
>>>> --bd-uninstallable-explainer=apt \
>>>>
>>>> This will be very helpfull to get some build logs from your setup.
>>>
>>> I scanned the logs and searched for /dev mounts. Typical example:
>>>
>>> tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-r0/temp/log.do_dpkg_build.18089
>>> 521:devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
>>> 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
>>>
>>> At the end I still have one active /dev mount:
>>> tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs (rw,nosuid,size=65536k,mode=755,inode64)
>>>
>>> Trying to delete the sbuild-chroot-target delivers:
>>>
>>> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/shm': Device or resource busy
>>> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/termination-log': Device or resource busy
>>> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/mqueue': Device or resource busy
>>> rm: cannot remove 'build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev/pts': Device or resource busy
>>>
>>> mqueue and termination-log are host specific. That might be the reason
>>> why I can only reproduce in CI setups. k8s has some "specials" like
>>> termination-log here.
>>>
>>> It seems that the mount comes from the rootfs_postprocess task of
>>> sbuild-chroot-target. Which task should undo/clean them up?
>>
>> If you are building an image (image.bbclass), do_rootfs_finalize will
>> clean up. If no (see the initramfs issue), those mounts will stick.
>
> There is no do_rootfs_finalize task in the list of tasks:
>
> 20241001-074332.296794 do_fetch (805): log.do_fetch.805
> 20241001-074332.387021 do_unpack (969): log.do_unpack.969
> 20241001-074503.068122 do_rootfs_install (11792): log.do_rootfs_install.11792
> 20241001-074728.511151 do_rootfs_postprocess (18028): log.do_rootfs_postprocess.18028
> 20241001-074728.628202 do_rootfs (18057): log.do_rootfs.18057
> 20241001-074728.675634 do_sbuildchroot_deploy (18068): log.do_sbuildchroot_deploy.18068
>
> Missing task dependency somewhere?
Missing cleanup then for sbuild-chroot-*, analogously to initramfs_rootfs.
Jan
--
Siemens AG, Technology
Linux Expert Center
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/cfbb244d-dcd5-4d79-bb8d-7da451114133%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-01 11:59 ` 'Florian Bezdeka' via isar-users
2024-10-01 12:14 ` 'Jan Kiszka' via isar-users
@ 2024-10-03 14:37 ` Baurzhan Ismagulov
2024-10-04 7:28 ` 'Florian Bezdeka' via isar-users
1 sibling, 1 reply; 16+ messages in thread
From: Baurzhan Ismagulov @ 2024-10-03 14:37 UTC (permalink / raw)
To: isar-users; +Cc: Anton Mikanovich, Jan Kiszka, Florian Bezdeka
Hello Florian,
On 2024-10-01 13:59, Florian Bezdeka wrote:
> I scanned the logs and searched for /dev mounts. Typical example:
>
> tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-r0/temp/log.do_dpkg_build.18089
> 521:devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
> 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
We'll address the patches with priority. Could you please provide 1. the output
of bitbake ... 2>&1 |tee bitbake.txt and 2. the related failed task
log.do_build? Off-list if sensitive.
> At the end I still have one active /dev mount:
> tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs (rw,nosuid,size=65536k,mode=755,inode64)
Thanks for the info, this looks like an sbuild migration bug. Checking.
With kind regards,
Baurzhan
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/Zv6sLwXgXm1p5yTw%40abai.m.ilbers.de.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-03 14:37 ` Baurzhan Ismagulov
@ 2024-10-04 7:28 ` 'Florian Bezdeka' via isar-users
2024-10-04 8:00 ` Uladzimir Bely
0 siblings, 1 reply; 16+ messages in thread
From: 'Florian Bezdeka' via isar-users @ 2024-10-04 7:28 UTC (permalink / raw)
To: isar-users, Anton Mikanovich, Jan Kiszka
On Thu, 2024-10-03 at 16:37 +0200, Baurzhan Ismagulov wrote:
> Hello Florian,
>
> On 2024-10-01 13:59, Florian Bezdeka wrote:
> > I scanned the logs and searched for /dev mounts. Typical example:
> >
> > tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-r0/temp/log.do_dpkg_build.18089
> > 521:devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
> > 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
>
> We'll address the patches with priority. Could you please provide 1. the output
> of bitbake ... 2>&1 |tee bitbake.txt and 2. the related failed task
> log.do_build? Off-list if sensitive.
I already sent patches for fixing this issue. There is no failed task.
rootfs::do_rootfs_postprocess and rootfs::do_rootfs_install both call
rootfs::rootfs_do_mounts but never clean up.
In case the mounts are left behind I will run into "can not umount,
device still active" later.
>
>
> > At the end I still have one active /dev mount:
> > tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs (rw,nosuid,size=65536k,mode=755,inode64)
>
> Thanks for the info, this looks like an sbuild migration bug. Checking.
Reviewing patches should do it...
>
>
> With kind regards,
> Baurzhan
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/143d65f425959b3510c96ae08f20791ea46655d5.camel%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-04 7:28 ` 'Florian Bezdeka' via isar-users
@ 2024-10-04 8:00 ` Uladzimir Bely
2024-10-04 8:16 ` 'Jan Kiszka' via isar-users
0 siblings, 1 reply; 16+ messages in thread
From: Uladzimir Bely @ 2024-10-04 8:00 UTC (permalink / raw)
To: Florian Bezdeka, isar-users, Anton Mikanovich, Jan Kiszka
On Fri, 2024-10-04 at 09:28 +0200, 'Florian Bezdeka' via isar-users
wrote:
> On Thu, 2024-10-03 at 16:37 +0200, Baurzhan Ismagulov wrote:
> > Hello Florian,
> >
> > On 2024-10-01 13:59, Florian Bezdeka wrote:
> > > I scanned the logs and searched for /dev mounts. Typical example:
> > >
> > > tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-
> > > r0/temp/log.do_dpkg_build.18089
> > > 521:devpts on /dev/pts type devpts
> > > (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
> > > 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
> >
> > We'll address the patches with priority. Could you please provide
> > 1. the output
> > of bitbake ... 2>&1 |tee bitbake.txt and 2. the related failed task
> > log.do_build? Off-list if sensitive.
>
> I already sent patches for fixing this issue. There is no failed
> task.
> rootfs::do_rootfs_postprocess and rootfs::do_rootfs_install both call
> rootfs::rootfs_do_mounts but never clean up.
>
> In case the mounts are left behind I will run into "can not umount,
> device still active" later.
>
> >
> >
> > > At the end I still have one active /dev mount:
> > > tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-
> > > amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs
> > > (rw,nosuid,size=65536k,mode=755,inode64)
> >
> > Thanks for the info, this looks like an sbuild migration bug.
> > Checking.
>
> Reviewing patches should do it...
>
Hello all.
I've checked this case and we are really have this mount left. It's not
related to sbuild (e.g., building packages) but to producing sbuild-
chroot itself.
E.g., entering kas shell and running "bitbake sbuild-chroot-target"
always results in "/dev" mount left in sbuild-chroot workdir rootfs.
For "image" targets we have umount routiness in image.bbclass. For
initramfs, we now have Jan's patches.
But I guess that "[PATCH 0/2] Fix leftover mounts in rootfs.bbclass"
patchset should itself cover all cases. And we might not even need
special handling in image.bbclass and initramfs.bbclass.
Probably, only the case when an error happens before rootf_postprocess
(e.g., in image_install) may lead to some mounts left.
> >
> >
> > With kind regards,
> > Baurzhan
>
--
Best regards,
Uladzimir.
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/0fb46eeddf91578871a624d51c76e79958760a24.camel%40ilbers.de.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-04 8:00 ` Uladzimir Bely
@ 2024-10-04 8:16 ` 'Jan Kiszka' via isar-users
2024-10-10 4:33 ` 'Jan Kiszka' via isar-users
0 siblings, 1 reply; 16+ messages in thread
From: 'Jan Kiszka' via isar-users @ 2024-10-04 8:16 UTC (permalink / raw)
To: Uladzimir Bely, Florian Bezdeka, isar-users, Anton Mikanovich
On 04.10.24 10:00, Uladzimir Bely wrote:
> On Fri, 2024-10-04 at 09:28 +0200, 'Florian Bezdeka' via isar-users
> wrote:
>> On Thu, 2024-10-03 at 16:37 +0200, Baurzhan Ismagulov wrote:
>>> Hello Florian,
>>>
>>> On 2024-10-01 13:59, Florian Bezdeka wrote:
>>>> I scanned the logs and searched for /dev mounts. Typical example:
>>>>
>>>> tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-
>>>> r0/temp/log.do_dpkg_build.18089
>>>> 521:devpts on /dev/pts type devpts
>>>> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
>>>> 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
>>>
>>> We'll address the patches with priority. Could you please provide
>>> 1. the output
>>> of bitbake ... 2>&1 |tee bitbake.txt and 2. the related failed task
>>> log.do_build? Off-list if sensitive.
>>
>> I already sent patches for fixing this issue. There is no failed
>> task.
>> rootfs::do_rootfs_postprocess and rootfs::do_rootfs_install both call
>> rootfs::rootfs_do_mounts but never clean up.
>>
>> In case the mounts are left behind I will run into "can not umount,
>> device still active" later.
>>
>>>
>>>
>>>> At the end I still have one active /dev mount:
>>>> tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-
>>>> amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs
>>>> (rw,nosuid,size=65536k,mode=755,inode64)
>>>
>>> Thanks for the info, this looks like an sbuild migration bug.
>>> Checking.
>>
>> Reviewing patches should do it...
>>
>
> Hello all.
>
> I've checked this case and we are really have this mount left. It's not
> related to sbuild (e.g., building packages) but to producing sbuild-
> chroot itself.
>
> E.g., entering kas shell and running "bitbake sbuild-chroot-target"
> always results in "/dev" mount left in sbuild-chroot workdir rootfs.
>
> For "image" targets we have umount routiness in image.bbclass. For
> initramfs, we now have Jan's patches.
>
> But I guess that "[PATCH 0/2] Fix leftover mounts in rootfs.bbclass"
> patchset should itself cover all cases. And we might not even need
> special handling in image.bbclass and initramfs.bbclass.
We can and possibly should make this work - but not in the way those
patches currently interact. Please check once again.
Jan
>
> Probably, only the case when an error happens before rootf_postprocess
> (e.g., in image_install) may lead to some mounts left.
>
>>>
>>>
>>> With kind regards,
>>> Baurzhan
>>
>
--
Siemens AG, Technology
Linux Expert Center
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/1e2853af-9f9f-4bad-89a0-d5629b2a5ca1%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-04 8:16 ` 'Jan Kiszka' via isar-users
@ 2024-10-10 4:33 ` 'Jan Kiszka' via isar-users
2024-10-10 9:43 ` Baurzhan Ismagulov
0 siblings, 1 reply; 16+ messages in thread
From: 'Jan Kiszka' via isar-users @ 2024-10-10 4:33 UTC (permalink / raw)
To: Uladzimir Bely, Florian Bezdeka, isar-users, Anton Mikanovich
On 04.10.24 10:16, 'Jan Kiszka' via isar-users wrote:
> On 04.10.24 10:00, Uladzimir Bely wrote:
>> On Fri, 2024-10-04 at 09:28 +0200, 'Florian Bezdeka' via isar-users
>> wrote:
>>> On Thu, 2024-10-03 at 16:37 +0200, Baurzhan Ismagulov wrote:
>>>> Hello Florian,
>>>>
>>>> On 2024-10-01 13:59, Florian Bezdeka wrote:
>>>>> I scanned the logs and searched for /dev mounts. Typical example:
>>>>>
>>>>> tmp/work/debian-bookworm-amd64/isar-exclude-docs/0.2.2-
>>>>> r0/temp/log.do_dpkg_build.18089
>>>>> 521:devpts on /dev/pts type devpts
>>>>> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
>>>>> 522:tmpfs on /dev/shm type tmpfs (rw,relatime,inode64)
>>>>
>>>> We'll address the patches with priority. Could you please provide
>>>> 1. the output
>>>> of bitbake ... 2>&1 |tee bitbake.txt and 2. the related failed task
>>>> log.do_build? Off-list if sensitive.
>>>
>>> I already sent patches for fixing this issue. There is no failed
>>> task.
>>> rootfs::do_rootfs_postprocess and rootfs::do_rootfs_install both call
>>> rootfs::rootfs_do_mounts but never clean up.
>>>
>>> In case the mounts are left behind I will run into "can not umount,
>>> device still active" later.
>>>
>>>>
>>>>
>>>>> At the end I still have one active /dev mount:
>>>>> tmpfs on /builds/myproject/build/tmp/work/debian-bookworm-
>>>>> amd64/sbuild-chroot-target/1.0-r0/rootfs/dev type tmpfs
>>>>> (rw,nosuid,size=65536k,mode=755,inode64)
>>>>
>>>> Thanks for the info, this looks like an sbuild migration bug.
>>>> Checking.
>>>
>>> Reviewing patches should do it...
>>>
>>
>> Hello all.
>>
>> I've checked this case and we are really have this mount left. It's not
>> related to sbuild (e.g., building packages) but to producing sbuild-
>> chroot itself.
>>
>> E.g., entering kas shell and running "bitbake sbuild-chroot-target"
>> always results in "/dev" mount left in sbuild-chroot workdir rootfs.
>>
>> For "image" targets we have umount routiness in image.bbclass. For
>> initramfs, we now have Jan's patches.
>>
>> But I guess that "[PATCH 0/2] Fix leftover mounts in rootfs.bbclass"
>> patchset should itself cover all cases. And we might not even need
>> special handling in image.bbclass and initramfs.bbclass.
>
> We can and possibly should make this work - but not in the way those
> patches currently interact. Please check once again.
No, we should not start to consolidate the umounts again. If we do that,
we could also drop the warning from the catch-all handler
build_completed and let it umount everything, as we've done in the past.
If we don't want this anymore, every individual task that does mounting
must also do the umounting at its end. And that means even the umount in
do_rootfs_finalize would become obsolete.
Jan
--
Siemens AG, Technology
Linux Expert Center
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/ecda24dc-7921-4477-b3ba-dc14a39aa148%40siemens.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] meta: Drop lazy and recursive unmounts
2024-10-10 4:33 ` 'Jan Kiszka' via isar-users
@ 2024-10-10 9:43 ` Baurzhan Ismagulov
0 siblings, 0 replies; 16+ messages in thread
From: Baurzhan Ismagulov @ 2024-10-10 9:43 UTC (permalink / raw)
To: isar-users; +Cc: Uladzimir Bely, Florian Bezdeka, Anton Mikanovich, Jan Kiszka
On 2024-10-10 06:33, 'Jan Kiszka' via isar-users wrote:
> No, we should not start to consolidate the umounts again. If we do that,
> we could also drop the warning from the catch-all handler
> build_completed and let it umount everything, as we've done in the past.
> If we don't want this anymore, every individual task that does mounting
> must also do the umounting at its end. And that means even the umount in
> do_rootfs_finalize would become obsolete.
I agree, the vision has always been to mount-umount as locally as possible. To
avoid misunderstanding, it isn't about "consolidate the umounts again" -- the
single goal of the cleanup handler is to warn about the problem; unmounting was
done as a by-product only to return a saner state to the user, as executing
sudo rm -rf build afterwards might delete the host /dev, making the system
unusable.
On the whole, the approach in the patches looks good to us; we'll provide a
consolidated patchset today / tomorrow as long as we don't encounter any
surprises underway.
With kind regards,
Baurzhan
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/ZwehtJp6hJ7B2LfT%40abai.m.ilbers.de.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-10-10 9:43 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-06-19 10:41 [PATCH] meta: Drop lazy and recursive unmounts Anton Mikanovich
2024-06-26 6:31 ` Uladzimir Bely
2024-08-28 13:05 ` 'Florian Bezdeka' via isar-users
2024-08-29 9:26 ` Anton Mikanovich
2024-08-29 12:26 ` 'Florian Bezdeka' via isar-users
2024-09-06 14:34 ` Anton Mikanovich
2024-10-01 11:59 ` 'Florian Bezdeka' via isar-users
2024-10-01 12:14 ` 'Jan Kiszka' via isar-users
2024-10-01 12:18 ` 'Florian Bezdeka' via isar-users
2024-10-01 12:28 ` 'Jan Kiszka' via isar-users
2024-10-03 14:37 ` Baurzhan Ismagulov
2024-10-04 7:28 ` 'Florian Bezdeka' via isar-users
2024-10-04 8:00 ` Uladzimir Bely
2024-10-04 8:16 ` 'Jan Kiszka' via isar-users
2024-10-10 4:33 ` 'Jan Kiszka' via isar-users
2024-10-10 9:43 ` Baurzhan Ismagulov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox