From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shymkent.ilbers.de ([unix socket]) by shymkent (Cyrus 2.5.10-Debian-2.5.10-3+deb9u2) with LMTPA; Tue, 13 Jan 2026 16:01:49 +0100 X-Sieve: CMU Sieve 2.4 Received: from mail-qt1-f192.google.com (mail-qt1-f192.google.com [209.85.160.192]) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPS id 60DF1lp8028262 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Jan 2026 16:01:48 +0100 Received: by mail-qt1-f192.google.com with SMTP id d75a77b69052e-4ed782d4c7dsf149645501cf.2 for ; Tue, 13 Jan 2026 07:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1768316502; x=1768921302; darn=ilbers.de; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=53zawtzNIHIhrHi1K7nwMLGyrCnbURi92jtO84m1y9U=; b=f65Sb5PKZ/QNcqhkGFiporUEO720Zifn0s99YBbU114r18VNDLoZQ/cQMRvvXwRiTA /1s0kl3dqj4OxqzJICagHWhCFwH9oO4S34LOxD/p4IGVKjEtwnYsWTbFew71LUueeI3q 8cx+onRwYrr2V1uPalqx+3XIrVTbF7R3YSkdZIWKbnywREcZNMfHiFu2D9j7owZ0YX4m wRHKCK1QC5+3tlXzahLNB8Q4o21OHz6ASW2o5uoz/leLT7jDeMhbFO/Ug6RrxvYNEFEC kJk/8GwEUvgl4ia/qjGivl8NlZWT4Hu2QvKq8pXpBRmXE7Mpfl0i8LP1FikTAGU7KUam OS9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768316502; x=1768921302; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :x-spam-checked-in-group:list-id:mailing-list:precedence:reply-to :x-original-sender:mime-version:subject:references:in-reply-to :message-id:to:from:date:x-beenthere:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=53zawtzNIHIhrHi1K7nwMLGyrCnbURi92jtO84m1y9U=; b=NS7xgEd6yMA7bh5TRsMZWOkacUn8vmC1SQzTzcuvRpB33smy4p3F7hNjkaCSv4h7PC O0pZve0CyCeL3FVMpohPvJJubIk9q0GaB1JtbxN6i8qKl3D8kyY4W9gDeUBtY6aCEVwM 8bd9hXluJMQl2W9BcGGUQ8xsDSK3bFR2O20HAh9hS/sTWJ+YrKfs45XRex4Jy1XGWbs/ 036V/3OCTDFIBCiFvsxxePH33/WxC0c44RYhP+t8AMRS5wxcNIB2Cjn8l/Fc8bTD7K0R MOZIEsCSRofUbl9mOMGAJuN4i0JSqUGWCVnRld6sXPSK7ClMg1UsSwWEJsJGcjGXCUFr ZK4A== X-Forwarded-Encrypted: i=1; AJvYcCXT9HnQNnQSzO6SOf8CDK1rLxmrDoeOZcFYfmfn/p/kqVnXIZcpohY56gpjJRafyvSf7O35@ilbers.de X-Gm-Message-State: AOJu0YwB1UY0e8rxEx0g2nPL6kmNFWhCVLuGuzgkGo9/SXAWI1dvrzjn ME4KZRsY/9Tw5j2Jq+jOyao5cW8zslaJJiiWcf9beV9FfMY13Oyn+fsk X-Google-Smtp-Source: AGHT+IHP6DBzgA8x0OsKvLhfvqvo/qFSX8DyuIKq2qNZTcSGQXgm9rA4EE9I+Lq6jcR8J1h0mfzcdA== X-Received: by 2002:a05:622a:7102:b0:500:b4a6:6edb with SMTP id d75a77b69052e-500b4a673f1mr112882331cf.44.1768316496278; Tue, 13 Jan 2026 07:01:36 -0800 (PST) X-BeenThere: isar-users@googlegroups.com; h="AV1CL+GiLyrT9vPY03B2lxVyPrr9ykOKNY2MHa7X0S0SIQuEsg==" Received: by 2002:a05:622a:546:b0:4ee:1f69:fde2 with SMTP id d75a77b69052e-4ffa72a281cls165536791cf.2.-pod-prod-02-us; Tue, 13 Jan 2026 07:01:33 -0800 (PST) X-Received: by 2002:a05:620a:2847:b0:8c3:6f1e:21ef with SMTP id af79cd13be357-8c38943a4d8mr2962670685a.83.1768316493790; Tue, 13 Jan 2026 07:01:33 -0800 (PST) Date: Tue, 13 Jan 2026 07:01:32 -0800 (PST) From: "'Badrikesh Prusty' via isar-users" To: isar-users Message-Id: In-Reply-To: References: <20251212053214.80936-1-badrikesh.prusty@siemens.com> Subject: Re: [PATCH] image-postproc: apply all systemd preset rules and ignore failures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_318022_498838036.1768316492435" X-Original-Sender: badrikesh.prusty@siemens.com X-Original-From: Badrikesh Prusty Reply-To: Badrikesh Prusty Precedence: list Mailing-list: list isar-users@googlegroups.com; contact isar-users+owners@googlegroups.com List-ID: X-Spam-Checked-In-Group: isar-users@googlegroups.com X-Google-Group-Id: 914930254986 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Status: No, score=-4.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,RCVD_IN_RP_CERTIFIED, RCVD_IN_RP_RNBL,RCVD_IN_RP_SAFE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: UxAdRqy8nLa6 ------=_Part_318022_498838036.1768316492435 Content-Type: multipart/alternative; boundary="----=_Part_318023_1664674131.1768316492435" ------=_Part_318023_1664674131.1768316492435 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the information and for pointing out the differences in the=20 actual systemd code. I have updated the patch to make populate-systemd-preset opt-in instead of= =20 opt-out, due to the many service failures we observed when it was enabled during image=20 postprocessing: [PATCH v2 1/2] image-postproc: ignore systemd preset failures=20 Thanks, Badrikesh On Tuesday, December 16, 2025 at 2:47:34=E2=80=AFPM UTC+5:30 Heinisch, Alex= ander=20 wrote: > On Tue, 2025-12-16 at 02:32 +0000, Prusty, Badrikesh (FT FDS CES LX PBU > 2) wrote: > > Hi, > > > > > Before I introduced this postprocessing step some services got > > > enabled > > > on first boot which was not reflected in the images rootfs after > > > build. > > > So the idea was to align the build artifacts to what was actually > > > running on the system. (and by that supporting ro /usr + /etc > > > systems) > > > > > > Systemd back then (and afaik as of now) on first boot only > > > populates > > > the presets with flag --enable-only. > > > > > > > I agree with the goal of aligning the build artifacts with what > > actually runs on the > > system. However, I think the closer match to first-boot behavior > > would be to run > > `systemctl preset-all`. According to the systemd man pages, this is > > what is executed > > on first boot, whereas enable-only changes the semantics. > > > While this holds true for invocations of of systemctl preset-all, this > is not the case for systemd during first-boot! > > From systemd changelog: > > ``` > * Systemd can optionally do a full preset in the "first boot" condition > (instead of just enable-only). This behaviour is controlled > by the > compile-time option -Dfirst-boot-full-preset. Right now it > defaults > to 'false', but the plan is to switch it to 'true' for the > subsequent > release. > ``` > > According to [1],[2] and [3] this (defaults to false) is still the > case. > Also on the debian source package (for trixie) I could not find any > patch changing this. > > > [1]: > > https://github.com/systemd/systemd/blob/6066106b3c066a6091d3edb2367c4f0a1= 5c87025/meson_options.txt#L32 > [2]: > > https://github.com/systemd/systemd/blob/6066106b3c066a6091d3edb2367c4f0a1= 5c87025/meson.build#L335 > [3]: > https://github.com/systemd/systemd/blob/6066106b3c066a6091d3edb2367c4f0a1= 5c87025/src/core/manager.c#L1940 > > > > Using enable-only ignores disable presets and still enable units (as > > in the case > > I shared earlier), which can cause the rootfs to diverge from the > > intended preset > > policy. preset-all respects both enable and disable presets and > > should align the > > image more closely. > > > > > system). At least such feature should be opt-in. Also a note about > > > this > > > change should be put in the RECIPE-API-CHANGELOG.md > > > > > > > This change is already well documented in RECIPE-API-CHANGELOG.md, > > so no additional note should be necessary. > > It clearly states enable only semantics. > > > BR Alexander > > > > > Many thanks, > > Badrikesh > > > > ________________________________________ > > From: 'Prusty, Badrikesh' via isar-users > > > > Sent: 15 December 2025 19:28 > > To: Heinisch, Alexander (FT RPD CED SES-AT); > > isar-...@googlegroups.com; Moessbauer, Felix (FT RPD CED OES-DE) > > Subject: Re: [PATCH] image-postproc: apply all systemd preset rules > > and ignore failures > > > > > > Hi Felix / Alex, > > > > Thanks for review. > > > > > is this change in sync regarding what Debian does during > > > installation? > > > > Debian does not run `systemctl preset-all` automatically at the end > > of the OS installation. > > > > The systemd manpage in Debian states that on the first boot, systemd > > will enable or disable > > services according to preset policy, similar to running `systemctl > > preset-all`. > > Reference: > > https://manpages.debian.org/bookworm/systemd/systemd.preset.5.en.html > > > > > Enabling additional services should be fine in general, but > > > disabling > > > bears some risk in case packages that otherwise only enable > > > services > > > via symlink in /etc get disabled again. > > > > Yes, the point is correct and, but here `systemctl preset-all` would > > only apply according > > to the rules defined in /usr/lib/systemd/system-preset/*.preset (or > > /etc/systemd/system-preset/), > > not to all services. > > > > The other issue I encountered was with a custom preset rule. For > > example, > > I created a preset file 90-no-reboot.preset containing the following > > rule: > > ``` > > disable ctrl-alt-del.target > > ``` > > > > When running `systemctl preset-all --preset-mode=3Denable-only` this > > rule is ignored, > > and enabled ctrl-alt-del.target (i.e., gets symlinked to > > reboot.target). However, running > > `systemctl preset-all` without specifying `--preset-mode` (i.e., the > > default full mode) > > correctly applies the preset and disables ctrl-alt-del.target. > > > > Thank you, > > Badrikesh > > > > > > ________________________________________ > > From: Heinisch, Alexander (FT RPD CED SES-AT) > > > > Sent: 15 December 2025 17:20 > > To: Prusty, Badrikesh (FT FDS CES LX PBU 2); > > isar-...@googlegroups.com; Moessbauer, Felix (FT RPD CED OES-DE) > > Subject: Re: [PATCH] image-postproc: apply all systemd preset rules > > and ignore failures > > > > On Mon, 2025-12-15 at 07:31 +0000, Moessbauer, Felix (FT RPD CED OES- > > DE) wrote: > > > On Fri, 2025-12-12 at 00:32 -0500, 'Badrikesh Prusty' via isar- > > > users > > > wrote: > > > > Update image postprocessing to run 'systemctl preset-all' without > > > > restricting to '--preset-mode=3Denable-only', so that both enable > > > > and > > > > disable rules from systemd preset files are applied. > > > > > > > > Add '|| true' to ignore failures from already masked units set by > > > > package post-install scripts during rootfs_install tasks. > > > > > > Hi, > > > > > > is this change in sync regarding what Debian does during > > > installation? > > > Enabling additional services should be fine in general, but > > > disabling > > > bears some risk in case packages that otherwise only enable > > > services > > > via symlink in /etc get disabled again. > > > > > > > Before I introduced this postprocessing step some services got > > enabled > > on first boot which was not reflected in the images rootfs after > > build. > > So the idea was to align the build artifacts to what was actually > > running on the system. (and by that supporting ro /usr + /etc > > systems) > > > > Systemd back then (and afaik as of now) on first boot only populates > > the presets with flag --enable-only. > > One can change this behavior with compile time flag -Dfirst-boot- > > full- > > preset which seems not to be the case. > > > > Imo, disabling services during the postprocessing changes the image > > in > > an unexpected way (as this does not happen by default on the running > > system). At least such feature should be opt-in. Also a note about > > this > > change should be put in the RECIPE-API-CHANGELOG.md > > > > BR Alexander > > > > > Do you know if this topic has already been discussed in upstream > > > Debian? > > > > > > +CC Alexander > > > > > > Felix > > > > > > > > > > > Signed-off-by: Badrikesh Prusty > > > > --- > > > > meta/classes-recipe/rootfs.bbclass | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/meta/classes-recipe/rootfs.bbclass b/meta/classes- > > > > recipe/rootfs.bbclass > > > > index 8485b32f..7e79bb8e 100644 > > > > --- a/meta/classes-recipe/rootfs.bbclass > > > > +++ b/meta/classes-recipe/rootfs.bbclass > > > > @@ -574,7 +574,7 @@ image_postprocess_populate_systemd_preset() { > > > > --show systemd || echo "" ) > > > > > > > > if (test "$SYSTEMD_INSTALLED" =3D "installed"); then > > > > - sudo chroot '${ROOTFSDIR}' systemctl preset-all -- > > > > preset- > > > > mode=3D"enable-only" > > > > + sudo chroot '${ROOTFSDIR}' systemctl preset-all || true > > > > fi > > > > } > > > > > > > > -- > > > > 2.47.3 > > > > > > > > -- > > > > 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+...@googlegroups.com. > > > > To view this discussion visit > > > >=20 > https://groups.google.com/d/msgid/isar-users/20251212053214.80936-1-badri= kesh.prusty%40siemens.com > > > > . > > > > -- > > Alexander Heinisch > > Siemens AG > > http://www.siemens.com/ > > > > -- > > 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+...@googlegroups.com. > > To view this discussion visit > >=20 > https://groups.google.com/d/msgid/isar-users/SG2PR06MB5107E12994821DDF3B9= F34B191ADA%40SG2PR06MB5107.apcprd06.prod.outlook.com > > . > > -- > Alexander Heinisch > Siemens AG > http://www.siemens.com/ > --=20 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 e= mail to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/= ef5c3500-e517-4629-bebf-1f4bd2ef4d5dn%40googlegroups.com. ------=_Part_318023_1664674131.1768316492435 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,

Thanks for the information and for pointing out th= e differences in the actual systemd code.
I have updated the patc= h to make populate-systemd-preset opt-in instead of opt-out, due to
the many service failures we observed when it was enabled during image p= ostprocessing:

Thanks,
Badrikesh=
On = Tuesday, December 16, 2025 at 2:47:34=E2=80=AFPM UTC+5:30 Heinisch, Alexand= er wrote:
On = Tue, 2025-12-16 at 02:32 +0000, Prusty, Badrikesh (FT FDS CES LX PBU
2) wrote:
> Hi,
>
> > Before I introduced this postprocessing step some services go= t
> > enabled
> > on first boot which was not reflected in the images rootfs af= ter
> > build.
> > So the idea was to align the build artifacts to what was actu= ally
> > running on the system. (and by that supporting ro /usr + /etc
> > systems)
> >
> > Systemd back then (and afaik as of now) on first boot only
> > populates
> > the presets with flag --enable-only.
> >
>
> I agree with the goal of aligning the build artifacts with what
> actually runs on the
> system. However, I think the closer match to first-boot behavior
> would be to run
> `systemctl preset-all`. According to the systemd man pages, this i= s
> what is executed
> on first boot, whereas enable-only changes the semantics.
>
While this holds true for invocations of of systemctl preset-all, this
is not the case for systemd during first-boot!

From systemd changelog:

```
* Systemd can optionally do a full preset in the "first boot"= condition
(instead of just enable-only). This behaviour is controlled
by the
compile-time option -Dfirst-boot-full-preset. Right now it
defaults
to 'false', but the plan is to switch it to 'true= ' for the
subsequent
release.
```

According to [1],[2] and [3] this (defaults to false) is still the
case.
Also on the debian source package (for trixie) I could not find any
patch changing this.


[1]:
https://github.com/systemd/systemd/blo= b/6066106b3c066a6091d3edb2367c4f0a15c87025/meson_options.txt#L32
[2]:
https://github.com/systemd/systemd/blob/6066106b= 3c066a6091d3edb2367c4f0a15c87025/meson.build#L335
[3]:https://github.com/systemd/s= ystemd/blob/6066106b3c066a6091d3edb2367c4f0a15c87025/src/core/manager.c#L19= 40


> Using enable-only ignores disable presets and still enable units (= as
> in the case
> I shared earlier), which can cause the rootfs to diverge from the
> intended preset
> policy. preset-all respects both enable and disable presets and
> should align the
> image more closely.
>
> > system). At least such feature should be opt-in. Also a note = about
> > this
> > change should be put in the RECIPE-API-CHANGELOG.md
> >
>
> This change is already well documented in RECIPE-API-CHANGELOG.md,
> so no additional note should be necessary.

It clearly states enable only semantics.


BR Alexander

>
> Many thanks,
> Badrikesh
>
> ________________________________________
> From: 'Prusty, Badrikesh' via isar-users
> <isar-...@googlegrou= ps.com>
> Sent: 15 December 2025 19:28
> To: Heinisch, Alexander (FT RPD CED SES-AT);
> isar-...@googlegroups.c= om; Moessbauer, Felix (FT RPD CED OES-DE)
> Subject: Re: [PATCH] image-postproc: apply all systemd preset rule= s
> and ignore failures
>
>
> Hi Felix / Alex,
>
> Thanks for review.
>
> > is this change in sync regarding what Debian does during
> > installation?
>
> Debian does not run `systemctl preset-all` automatically at the en= d
> of the OS installation.
>
> The systemd manpage in Debian states that on the first boot, syste= md
> will enable or disable
> services according to preset policy, similar to running `systemctl
> preset-all`.
> Reference:
> https://manpages.debian.or= g/bookworm/systemd/systemd.preset.5.en.html
>
> > Enabling additional services should be fine in general, but
> > disabling
> > bears some risk in case packages that otherwise only enable
> > services
> > via symlink in /etc get disabled again.
>
> Yes, the point is correct and, but here `systemctl preset-all` wou= ld
> only apply according
> to the rules defined in /usr/lib/systemd/system-preset/*.preset (o= r
> /etc/systemd/system-preset/),
> not to all services.
>
> The other issue I encountered was with a custom preset rule. For
> example,
> I created a preset file 90-no-reboot.preset containing the followi= ng
> rule:
> ```
> disable ctrl-alt-del.target
> ```
>
> When running `systemctl preset-all --preset-mode=3Denable-only` th= is
> rule is ignored,
> and enabled ctrl-alt-del.target (i.e., gets symlinked to
> reboot.target). However, running
> `systemctl preset-all` without specifying `--preset-mode` (i.e., t= he
> default full mode)
> correctly applies the preset and disables ctrl-alt-del.target.
>
> Thank you,
> Badrikesh
>
>
> ________________________________________
> From: Heinisch, Alexander (FT RPD CED SES-AT)
> <alexander...@siemen= s.com>
> Sent: 15 December 2025 17:20
> To: Prusty, Badrikesh (FT FDS CES LX PBU 2);
> isar-...@googlegroups.c= om; Moessbauer, Felix (FT RPD CED OES-DE)
> Subject: Re: [PATCH] image-postproc: apply all systemd preset rule= s
> and ignore failures
>
> On Mon, 2025-12-15 at 07:31 +0000, Moessbauer, Felix (FT RPD CED O= ES-
> DE) wrote:
> > On Fri, 2025-12-12 at 00:32 -0500, 'Badrikesh Prusty'= via isar-
> > users
> > wrote:
> > > Update image postprocessing to run 'systemctl preset= -all' without
> > > restricting to '--preset-mode=3Denable-only', so= that both enable
> > > and
> > > disable rules from systemd preset files are applied.
> > >
> > > Add '|| true' to ignore failures from already ma= sked units set by
> > > package post-install scripts during rootfs_install tasks= .
> >
> > Hi,
> >
> > is this change in sync regarding what Debian does during
> > installation?
> > Enabling additional services should be fine in general, but
> > disabling
> > bears some risk in case packages that otherwise only enable
> > services
> > via symlink in /etc get disabled again.
> >
>
> Before I introduced this postprocessing step some services got
> enabled
> on first boot which was not reflected in the images rootfs after
> build.
> So the idea was to align the build artifacts to what was actually
> running on the system. (and by that supporting ro /usr + /etc
> systems)
>
> Systemd back then (and afaik as of now) on first boot only populat= es
> the presets with flag --enable-only.
> One can change this behavior with compile time flag -Dfirst-boot-
> full-
> preset which seems not to be the case.
>
> Imo, disabling services during the postprocessing changes the imag= e
> in
> an unexpected way (as this does not happen by default on the runni= ng
> system). At least such feature should be opt-in. Also a note about
> this
> change should be put in the RECIPE-API-CHANGELOG.md
>
> BR Alexander
>
> > Do you know if this topic has already been discussed in upstr= eam
> > Debian?
> >
> > +CC Alexander
> >
> > Felix
> >
> > >
> > > Signed-off-by: Badrikesh Prusty <badrikes...@siemens.com>
> > > ---
> > > meta/classes-recipe/rootfs.bbclass | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes-recipe/rootfs.bbclass b/meta/c= lasses-
> > > recipe/rootfs.bbclass
> > > index 8485b32f..7e79bb8e 100644
> > > --- a/meta/classes-recipe/rootfs.bbclass
> > > +++ b/meta/classes-recipe/rootfs.bbclass
> > > @@ -574,7 +574,7 @@ image_postprocess_populate_systemd_p= reset() {
> > > --show systemd || echo "" )
> > >
> > > if (test "$SYSTEMD_INSTALLED" =3D "i= nstalled"); then
> > > - sudo chroot '${ROOTFSDIR}' systemctl pr= eset-all --
> > > preset-
> > > mode=3D"enable-only"
> > > + sudo chroot '${ROOTFSDIR}' systemctl pr= eset-all || true
> > > fi
> > > }
> > >
> > > --
> > > 2.47.3
> > >
> > > --
> > > 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+...@googlegroups.com.
> > > To view this discussion visit
> > > https://groups.google.com/d/msg= id/isar-users/20251212053214.80936-1-badrikesh.prusty%40siemens.com
> > > .
>
> --
> Alexander Heinisch
> Siemens AG
> http://www.siemens.com/
>
> --
> 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-u= sers+...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/isar-users/SG2PR06MB5107E129= 94821DDF3B9F34B191ADA%40SG2PR06MB5107.apcprd06.prod.outlook.com
> .

--
Alexander Heinisch
Siemens AG
http://www.siemens.com/

--
You received this message because you are subscribed to the Google Groups &= quot;isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to isar-use= rs+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-use= rs/ef5c3500-e517-4629-bebf-1f4bd2ef4d5dn%40googlegroups.com.
------=_Part_318023_1664674131.1768316492435-- ------=_Part_318022_498838036.1768316492435--