From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7156869355346591744 X-Received: by 2002:a05:6e02:178a:b0:2fa:825f:6df8 with SMTP id y10-20020a056e02178a00b002fa825f6df8mr12482483ilu.157.1666373759072; Fri, 21 Oct 2022 10:35:59 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a02:6247:0:b0:363:e074:b345 with SMTP id d68-20020a026247000000b00363e074b345ls862825jac.0.-pod-prod-gmail; Fri, 21 Oct 2022 10:35:58 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4r9TmecohZQfE9FKmP5ZfksEQnnyCsjYmqJedtz2YHQ3xYSnmgCNTdBokfmIl3hmceeTY1 X-Received: by 2002:a02:880b:0:b0:35a:e4be:c408 with SMTP id r11-20020a02880b000000b0035ae4bec408mr14487676jai.113.1666373758570; Fri, 21 Oct 2022 10:35:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666373758; cv=none; d=google.com; s=arc-20160816; b=ZlYJVdnxxMdf7v4Nn4TsaaTpCVTxebX4n7L++AZBvg9/N+B/Upt7bK8Mji8nlWqt74 obD6uHwBFtWEsN+6kEC6IcH7bfZU+tn8hMpJ4QOiVK8BkYiqCg9Lrj3IJ7fspMUnVgd1 8yUDdh6nVeP/fjvV/qDmKm0uz4Ta10DTofK+GLAhFlr+hdobos5PHXS7mwzOPaTQjwxX CGm1snZZqVBDFtWAqLL9U5OGUJ++FCzW1ouA+QThEBX6V4m3aOXRPJJv6xpL7nG6XM+U wB52OSxnylzjjznLA1gIRe5il/4kfavGKNuVgNWzcIMvSL4/6rXG1+Vmah/vjE9ukOwY KDuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=0az9+zVm/YIkhFgCaUg+7iV6mb6dwoWlpKSSDvGyLP4=; b=ziiMZ7M48d54PfCwL2JIWdhAz4DuBhsmajDpsxzV3Eb3Bgyrsb5BRZZpAXq1bUT83l wzjyCCVpi5T16QS0mMge03B6X8KzStBVEsK3yOJlvfwVtLp/7KG81ri/4Ljzi/k0rjcY J9u9aThmAzJnrOuNODjae/70SZE4eac5EikRT6bwN54zds0gcO6O9b2pTtmtcR7i5P6H lSzm7dGJDRSNZ59lLN06t6Xlj+xJTDllry05zDz1vjC17aDyNszBhR7EuUCvmqJxtG8G +HJ8DnF1fM1SlfAEjCtCFXOPoEtMM4OQoFgVgrfcP+kz5oAlATvtkOdF6J1jzvLuGwOo FxIA== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="HTc/1FLX"; spf=pass (google.com: domain of roberto.foglietta@gmail.com designates 2607:f8b0:4864:20::42a as permitted sender) smtp.mailfrom=roberto.foglietta@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com. [2607:f8b0:4864:20::42a]) by gmr-mx.google.com with ESMTPS id g14-20020a056e021a2e00b002fc5c99ad7fsi470019ile.0.2022.10.21.10.35.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Oct 2022 10:35:58 -0700 (PDT) Received-SPF: pass (google.com: domain of roberto.foglietta@gmail.com designates 2607:f8b0:4864:20::42a as permitted sender) client-ip=2607:f8b0:4864:20::42a; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="HTc/1FLX"; spf=pass (google.com: domain of roberto.foglietta@gmail.com designates 2607:f8b0:4864:20::42a as permitted sender) smtp.mailfrom=roberto.foglietta@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: by mail-pf1-x42a.google.com with SMTP id m6so3272409pfb.0 for ; Fri, 21 Oct 2022 10:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0az9+zVm/YIkhFgCaUg+7iV6mb6dwoWlpKSSDvGyLP4=; b=HTc/1FLX25npagjUquQ2+s7tMkt9jE8wHKyhtK1Q88LXbQ4m7ipCvcsnY3RY6aZwky l5KlYvg0jGP3ononyJeznnBD4cOEpsQabn4GynrOFs5ZwlGoQBX6fjPcTUDBwgMMQh0A JXKDCSanvLWiqS50RafEgMnrfZMNIRclZvzVbnnWlNBGiTAPPqTF2rOwWffaqimuN/kK EbQJ1xpiqPzlEIYLjzH1IdYelfHplt62b7PQWGMzfnETDJ41zBkhet4eE5QJoTPmi3ED 4pRx+9MOIEMGM8pDAPET1fX4drCa/sjamsXT5yIOr5JzqfY4OPd6UszI9FIjqg7+5vJC O9DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0az9+zVm/YIkhFgCaUg+7iV6mb6dwoWlpKSSDvGyLP4=; b=XZMz75Ghu6fWpsGNGRdzUfNBVU7n+vP2ctYF0ye1Arasf94gtN6mBjzGAHak8dCYnN i36rU56rugqKg34fUajSjLYSFaGZlxq/ti7jyxbCQ5R/vDHrcONCtC/ShI07QO+0tCjn b6W9SJw9XPo0DWPrKIySEQHOhyqkCRMeAi7d0KJIMHOwNx1qFpf2o0FuOOn1r1aIJctY XLSIkib8hg0bm4gbkh992m822mwYwDx1eL3IYWnXnfUj9LB25yJCTprn7QhyQqld7S94 zkE2pLvw5dy4RCpIxgxTogC/qdNAFRE4j35k2CX8+vJTXRgLLtRxA3Es6B/8xeUkBdYJ wxeg== X-Gm-Message-State: ACrzQf3nK7QnpuEltcaRSvE2VatO2HfJnAG0Fp4xcjQBsc/ePQwalOEt r/cgoC5kTaWV9OH9IrGAfom/nv2naeDNOBScMzZs3EPNBUZVM9s= X-Received: by 2002:a63:6c01:0:b0:429:ea6e:486d with SMTP id h1-20020a636c01000000b00429ea6e486dmr16729146pgc.247.1666373757736; Fri, 21 Oct 2022 10:35:57 -0700 (PDT) MIME-Version: 1.0 References: <879c4cdb9f55f07d05d40e0b50975bcd5911c7cc.camel@siemens.com> In-Reply-To: <879c4cdb9f55f07d05d40e0b50975bcd5911c7cc.camel@siemens.com> From: "Roberto A. Foglietta" Date: Fri, 21 Oct 2022 19:35:20 +0200 Message-ID: Subject: Re: expand-on-first-boot and surprising umounts To: "Bezdeka, Florian" Cc: "Lisicki, Raphael" , "isar-users@googlegroups.com" Content-Type: text/plain; charset="UTF-8" X-TUID: QbRYCBld2T/t Il giorno ven 21 ott 2022 alle ore 18:15 Bezdeka, Florian ha scritto: > > On Fri, 2022-10-21 at 17:41 +0200, Roberto A. Foglietta wrote: > > Il giorno ven 21 ott 2022 alle ore 09:48 Raphael Lisicki > > ha scritto: > > > > > > Hi everybody, > > > > > > I am using a debian bullseye based system and use expand-on-first-boot > > > to expand the last partition. It is not the root file system but an > > > extra ext4 partition to be mounted under /data. The mounting happens > > > after expand-on-first boot has succeeded. > > > > > > Sometimes, on some builds more often than others, /data gets (attempted > > > to be) umounted immediately after being mounted and subsequent units > > > will fail. > > > > > > Removing expand-on-first-boot resolves the issue, so does adding > > > "ExecStartPost=/usr/bin/udevadm settle" to expand-on-first-boot but I am > > > not sure if this is only a sophisticated way of solving a race condition > > > with "sleep". > > > > Hi Raphael, > > > > this trick should resolve the problem (untested, after the first boot > > nothing happens anymore) > > > > echo 'echo "exit 0" >$0' > > > > isar/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh > > > > It is equivalent to apply this patch and obviously it is just a work around > > > > diff --git a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh > > b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh > > index 759ff8b..09f5cd4 100755 > > --- a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh > > +++ b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh > > @@ -62,3 +62,4 @@ partx -u "${LAST_PART}" > > export EXT2FS_NO_MTAB_OK=1 > > > > resize2fs "${LAST_PART}" > > +echo "exit 0" >$0 > > Why should we destroy the expand-last-partition.sh script? Hi Florian, because Raphael wrote: "Removing expand-on-first-boot resolves the issue" > We disable > the systemd service after the first run... Then why removing (so destroying) the script would fix the problem? [Service] Type=oneshot ExecStart=/usr/share/expand-on-first-boot/expand-last-partition.sh ExecStartPost=-/bin/systemctl disable expand-on-first-boot.service I am not an expert of systemd but I have the sensation that ExecStartPost will run ONLY IF ExecStart script returns true. It is a "oneshot" service - and in my mind - one successful shot. Where "in my mind" means if I were written systemd. Another reason is: because systemd could have a bug in some {past, present, future} version that affects the disabling. So, having a double way to obtain the same result is not a work-around but a redundant safe path for a mission critical system that cannot fail. However, the workaround may fail because the script runs with "set -e". So, every failure in the script will prevent it from arriving at the last command. So, if the workaround solves the problem then the problem is a bug in systemd that does not disable the service (probable) or something that re-enables it (unlikely). Instead, if the workaround does not work - and it is easy to check because after the first boot the script still exists in its original form - then "set -e" did its job and "set -x" + logging in a file would help for debugging. In brief: the workaround solves otherwise helps us to define the perimeter of the unexpected behaviour. Best regards, R-