public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Baurzhan Ismagulov <ibr@radix50.net>
To: isar-users@googlegroups.com
Cc: Florian Bezdeka <florian.bezdeka@siemens.com>,
	"Moessbauer, Felix (T CED OES-DE)" <felix.moessbauer@siemens.com>,
	Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [PATCH] initramfs: Add missing umounts after generation
Date: Thu, 3 Oct 2024 18:15:03 +0200	[thread overview]
Message-ID: <Zv7DB35UdWbBLpW2@abai.m.ilbers.de> (raw)
In-Reply-To: <f6fc27b0-a5c5-4bd9-bf40-83b90e702e4c@siemens.com>

Hello Jan,

On 2024-10-02 12:28, 'Jan Kiszka' via isar-users wrote:
> Lazy umount was apparently dropped without review/testing of the safety
> mechanisms and the code that is involved in mounting. We all assumed to
> world would be fine while things de facto work not that well. On top
> comes that most users are in containers and only notice those issues on
> rebuilds or due to further special factors.

I'll share a bit of background on this: This is not about assumptions, we knew
there were issues (and worked on them -- e.g., [1]). The occurrence rate was
several times per year. After migrating to sbuild, mounts moved into
per-package schroots, and the errors became even more rare. Debugging cycles of
weeks to months are not practical because you can dump the mounts or similar
stuff, but the necessary number of iterations is not reachable, not in
reasonable time.

Before sending the lazy umount removal patch, we've checked the archives why
"umount -l", "umount || true" were introduced but couldn't reproduce any of
those (I personally found the problem descriptions and root cause analysis
quite spare and often not actionable -- I think we can improve here). Even now,
the issue seems to occur more frequently downstream than in meta-isar CI. Given
that the downstreams have control of meta-isar revision and can also apply
patches, the question for me was whether to keep the problems under the rug or
work with downstreams to analyze them. If you have specific suggestions what we
could do better the next time, please share.

For this specific occurrence, if we don't have the races with package building
left after the sbuild introduction (this is why mounts and umounts were
asymmetric with buildchroot), the latest patches might be enough without
central mount / umount tracking or moving the mounts to individual schroots
altogether. We'll need to understand the failure mode because otherwise proper
testing is challenging.

1. https://lists.isar-build.org/isar-users/20210421145855.66257-1-amikan@ilbers.de/#b

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/Zv7DB35UdWbBLpW2%40abai.m.ilbers.de.

  parent reply	other threads:[~2024-10-03 16:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-30 19:42 'Jan Kiszka' via isar-users
2024-10-01  7:38 ` 'MOESSBAUER, Felix' via isar-users
2024-10-01 10:04   ` 'Jan Kiszka' via isar-users
2024-10-02  8:31     ` 'Florian Bezdeka' via isar-users
2024-10-02 10:28       ` 'Jan Kiszka' via isar-users
2024-10-02 15:10         ` 'Florian Bezdeka' via isar-users
2024-10-03 16:15         ` Baurzhan Ismagulov [this message]
2024-10-04  7:47           ` 'Jan Kiszka' via isar-users

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=Zv7DB35UdWbBLpW2@abai.m.ilbers.de \
    --to=ibr@radix50.net \
    --cc=felix.moessbauer@siemens.com \
    --cc=florian.bezdeka@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.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