From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6449667588399038464 X-Received: by 10.28.141.8 with SMTP id p8mr133774wmd.31.1501746497528; Thu, 03 Aug 2017 00:48:17 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.69.194 with SMTP id s185ls63816lja.13.gmail; Thu, 03 Aug 2017 00:48:16 -0700 (PDT) X-Received: by 10.46.21.84 with SMTP id 20mr143166ljv.7.1501746496778; Thu, 03 Aug 2017 00:48:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501746496; cv=none; d=google.com; s=arc-20160816; b=XQVtEo2jBxjUatJeKAAyVPqpT0AIB/wdCX2dml0mr+iJaI6qL6MjeZJbV5iCkdg6fF f/9Id6jSRoZx/IXvCltBV9R9XCfyl1SHgE6xlT7K+YzcgTKQtgk0haSvMXT+jk9BqGBA JzVacbDPjrZFXeUNYNOzyp77f1c1mufQ6JU9Azu0kPD9+VYeTegJXqMMpDKBvpbAudJi Qc4xWPuOOPvQNxJSpdab7TN/V3OeBuiMThDadCU3pv6diDk95PAqavvorF/FOD7/4aFm AmGGq+sbTDgmOH6pUL9kqUstx1IQGXyh1gzUJM5LGL0KEDgnno9eVz5xfqrhLxmJF5it peEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=0DsYvWkaEI+uUMQES4ofIwFS2YEe5Q+UDXm89m1LVuc=; b=o4zJZqFllotyNq9VpzHUp36q8kvG0gXRwH/516DLPZMQ7smvuzWwBQ+cZoZztfSZxT aavd/e30qcGcDKOJMIwa81XIiINWR/AAcovXUU6RaQoXYQ03KYQ2ekaN24MVYfvk9Hcl +xgJk83ZYsaGK/KxlxOwfBbUS7hzAT2gZYvw4ZyXhSQ8rtJcrAkTWmlI4lBKuDyHQMTs zgz+Cqr7/XYoA6AgbLoIi3TFEofyIsq0w4SsjKYGDdOHdKI0KN1DRJ4nvqMJ+s28wOKN Ekwm2Z48au9s/50u8NglduO8cjnJNL/yyYsJXa3eI+AY37KlcVD+KVCr+l6qb9kdVf8R 1J6Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id 139si599920wmt.0.2017.08.03.00.48.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 00:48:16 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.2 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id v737mGF4026144 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 3 Aug 2017 09:48:16 +0200 Received: from md1em3qc ([139.25.68.40]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id v737mGcV011171; Thu, 3 Aug 2017 09:48:16 +0200 Date: Thu, 3 Aug 2017 09:50:11 +0200 From: Henning Schild To: "Andreas Reichel" Cc: Subject: Re: Integration of Pseudo into Isar Message-ID: <20170803095011.05aaa73c@md1em3qc> In-Reply-To: <20170802132413.GA25215@iiotirae> References: <20170802132413.GA25215@iiotirae> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: N5hAN+6fGust Another thing that might be important is which steps actually fail with pseudo. Currently we use sudo in several places. 1 multistrap 2 configure.sh 3 ext4fs 4 populate And maybe more, i do not know by heart. 1 needs to work for sure 2 can be merged into 1 when all configuration is moved into debian packages 3 will be replaced by wic if you choose to use wic 4 will move into 1 if my second patchq gets merged But i am guessing 1 already causes problems. Maybe in OE the magic that makes pseudo work is in the combination of pseudo and wic. In that case the magic needs to be understood and applied to 1 or maybe 1 can be done inside wic? Henning Am Wed, 2 Aug 2017 15:24:14 +0200 schrieb "Andreas Reichel" : > # Integrating pseudo into isar > > Idea was to exchange `sudo` by `pseudo`. The function of `pseudo` is > to intercept system calls and file accesses by preloading a library. > All such operations are recorded in a database. For this to work, a > `PSEUDO_PREFIX` variable must be seet, which is `/` if `pseudo` is > installed to the default location. > > # Given test configuration # > > - Docker container based on debian 9 > - `multistrap` from Siemens Debian repository > - `pseudo` from Siemens Debian repository > > Using the following multistrap configuration named `simple-config`: > > ``` > [General] > unpack=true > bootstrap=Debian > aptsources=Debian > noauth=true > > [Debian] > packages= > source=http://ftp.de.debian.org/debian > suite=stretch > ``` > > Inside chroot (which is inside pseudo): > > ``` > # mkdir rootfs > # multistrap -f simple-config -d rootfs > ``` > > # Results # > > * Error during package configuration. (Cannot write to > `/etc/ld.so.cache~`) > > This error can be tracked down to `ldconfig`. > It turned out that `ldconfig` is linked *statically*. Which means, > its file accesses cannot be intercepted by LDPRELOAD, which is only > for dynamically linked binaries. Thus, wether being in a pseudo > chroot or not, `ldconfig` will always access `/etc/ld.so.cache~` on > the host, which fails. > This is *NOT* a question of the Debian version and not a bug in > `dpkg --configure -a`, which calls `ldconfig` internally. > > * Extremely odd behaviour within `chroot` within `pseudo`: > > ``` > $ pseudo > # chroot rootfs > # export PATH=/sbin:/bin > # ldconfig > Can't create temporary cache file /etc/ld.so.cache~ > ``` > > Idea was then to rename `ldconfig` to `ldconfig_` and create a > symbolic link to `/bin/true` to mimic successful execution of > `ldconfig`. > > ``` > $ sudo mv rootfs/sbin/ldconfig rootfs/sbin/ldconfig_ > $ sudo ln -s /bin/true rootfs/sbin/ldconfig > ``` > > Here, behavior becomes very odd: > > ``` > $ pseudo > # chroot rootfs > # export PATH=/sbin:/bin > # ldconfig > /bin/sh: 16: ldconfig: not found > ``` > Although it is in path... > ``` > # /sbin/ldconfig > /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: > Permission denied > ``` > > So this is not our symbolic link but the real ldconfig from the host > > ``` > # cd /sbin > # ./ldconfig > # > ``` > > This works and returns `true`. > > ``` > # cd / > # /sbin/ldconfig > /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: > Permission denied > # sbin/ldconfig > # > ``` > > So a relative path works, but an absolute path does not. > > Even more funny is: > > ``` > # exec sh > # exit > $ > ``` > > The first `exec` replaces the current shell with `sh` from *OUTSIDE* > of the `chroot`. The `exit` then exits the `pseudo` environment > instead of the `chroot` environment. > > # Summary # > > * operations with `chroot inside pseudo` are completely messed-up. > * `ldconfig` will never work with `pseudo` since it is static. > > But if packets are not configured, initramfs is not generated, etc... > > # Ideas # > > * Yocto Morty uses pseudo with own patches, which may solve some or > all issues > * Do not use multistrap but another tool > * Stracing / Kernel tracing to analyze problem more deeply > > > Kind regards, > Andreas >