From: Jan Kiszka <jan.kiszka@siemens.com>
To: Anton Mikanovich <amikan@ilbers.de>, isar-users@googlegroups.com
Subject: Re: [PATCH v1 3/5] dpkg: Remove unmount loop
Date: Thu, 8 Jul 2021 14:21:32 +0200 [thread overview]
Message-ID: <18078814-c9c0-b46b-af32-17058c39f036@siemens.com> (raw)
In-Reply-To: <20210707163851.204296-4-amikan@ilbers.de>
On 07.07.21 18:38, Anton Mikanovich wrote:
> Remove while loop when trying to unmount WORKDIR. Any failures of
> umount should be investigated to fix the root cause.
> Also make dpkg_undo_mounts do not fail if dpkg_do_mounts was not
> called or it was called twice.
>
This is very likely wrong: We know from the past (should be in the git
history, e.g 17d0842d) that not all subprocesses started inside the
chroot may have been terminated when we left it. That can cause
significant delays between returning from chroot and finding non-busy
mount points to complete all umounts. Now, if you silently fail umounts,
you may find inconsistently mounted chroots on the next recipe that
tries to remount them. Big fat warning sign...!
Jan
> Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
> ---
> meta/classes/dpkg-base.bbclass | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/meta/classes/dpkg-base.bbclass b/meta/classes/dpkg-base.bbclass
> index 97661a6..6c84f3a 100644
> --- a/meta/classes/dpkg-base.bbclass
> +++ b/meta/classes/dpkg-base.bbclass
> @@ -154,16 +154,11 @@ dpkg_do_mounts() {
> }
>
> dpkg_undo_mounts() {
> - i=1
> - while ! sudo umount ${BUILDROOT}; do
> - sleep 0.1
> - i=`expr $i + 1`
> - if [ $i -gt 100 ]; then
> - bbwarn "${BUILDROOT}: Couldn't unmount, retrying..."
> - i=1
> - fi
> - done
> - sudo rmdir ${BUILDROOT}
> + buildchroot_undo_mounts
> +
> + mountpoint -q '${BUILDROOT}' && \
> + sudo umount ${BUILDROOT} && \
> + sudo rmdir ${BUILDROOT} || true
> }
>
> # Placeholder for actual dpkg_runbuild() implementation
>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2021-07-08 12:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 16:38 [PATCH v1 0/5] Restore downstream mounts compatibility Anton Mikanovich
2021-07-07 16:38 ` [PATCH v1 1/5] Revert "dpkg: Make mount buildroot reliable" Anton Mikanovich
2021-07-08 12:16 ` Jan Kiszka
2021-07-07 16:38 ` [PATCH v1 2/5] mount: Allow calling unmount on not mounted paths Anton Mikanovich
2021-07-08 12:17 ` Jan Kiszka
2021-07-07 16:38 ` [PATCH v1 3/5] dpkg: Remove unmount loop Anton Mikanovich
2021-07-08 12:21 ` Jan Kiszka [this message]
2021-07-08 14:35 ` Anton Mikanovich
2021-07-08 16:16 ` Jan Kiszka
2021-08-17 13:02 ` Anton Mikanovich
2021-07-07 16:38 ` [PATCH v1 4/5] image: Add reference counter Anton Mikanovich
2021-07-07 16:38 ` [PATCH v1 5/5] events: Unmount all lost mounts at task fail Anton Mikanovich
2021-07-08 12:24 ` Jan Kiszka
2021-07-08 14:41 ` Anton Mikanovich
2021-07-08 16:28 ` Jan Kiszka
2021-07-12 16:08 ` Baurzhan Ismagulov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18078814-c9c0-b46b-af32-17058c39f036@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=amikan@ilbers.de \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox