From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6449667588399038464 X-Received: by 10.46.80.84 with SMTP id v20mr2811541ljd.19.1501684661046; Wed, 02 Aug 2017 07:37:41 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.7.10 with SMTP id 10ls1125934ljh.29.gmail; Wed, 02 Aug 2017 07:37:40 -0700 (PDT) X-Received: by 10.46.32.81 with SMTP id g78mr2800573ljg.10.1501684660468; Wed, 02 Aug 2017 07:37:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501684660; cv=none; d=google.com; s=arc-20160816; b=w0sA7KEd8WbJIprjRSehM7UzfOegyqRMS/LJyJNT3SD+D+nddcrYbiproYFmOgofiY HdGOZRnwlFbm87dsuO7sUcK/fgZcAaGzkvn89sE9//U37u0EaVKW4jroy0yMSUniGqOJ 99oF8wiNoxSrjL7Ba7QELZCuiPxER8zHsK0ZHxhasQvT8w6mlWO30qBvMndLXkH1Ou3O RDq+PF7EmuCdm/6cFn5KGCXaSGqb8p3z0RaEKstLbTdwMSc99c3C7oeLqVdE+wkStKhE plv2DrKK8fmRkntpd5e17IPuj6oL75ej6LCt5GT9z13PWKcAjMdyGkocCHSk5zlCq8c1 HtNQ== 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=SHEWnAl8HOCDRlhyCl3Pt5p0a6dt+860C5J1ee9VkCY=; b=IRL4vPEeXQnEIVbJp992K4tpl0W6lbuEjYTrA6gsWAxbzRPH5iGa1Cn3NhCOsdRqSH JUqIDgOE6P1SdXSwMF7aHI3hEp2L4eXRj5oAZG++EoVERQDPp18CE0UK7I0sujHZLzCz ooL187xJsGDkjC+CeE6wUVAynMwlvsL3bNyS0aU/xdMnrqNjQiLpxu+um4j9GxQNVUya 3gMQZyAGDSz6QNbX9G9fln3RSGiu4wAwg0GrALny95b9/83T48qWUoftrev3onJNVQ8n ah7tVk6dhqb3CVFAZvi2OrGaKZHttMyIIVEJA5OaypZqUy6dt1c91Aswgg8dEsG1Zg12 PBOQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 192.35.17.28 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 goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id t129si1044435wmt.2.2017.08.02.07.37.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 07:37:40 -0700 (PDT) Received-SPF: neutral (google.com: 192.35.17.28 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 192.35.17.28 is neither permitted nor denied by best guess record for domain of henning.schild@siemens.com) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id v72Ebdhp023798 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 2 Aug 2017 16:37:40 +0200 Received: from md1em3qc ([139.25.68.40]) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id v72Ebdaq003258; Wed, 2 Aug 2017 16:37:39 +0200 Date: Wed, 2 Aug 2017 16:39:34 +0200 From: Henning Schild To: "Andreas Reichel" Cc: Subject: Re: Integration of Pseudo into Isar Message-ID: <20170802163934.39fb8351@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: 3yVQ+JeEjqR3 Hey, not very good news. But somehow OE made it work and they do not control /sbin/ldconfig of the host either. I suggest you rephrase this mail a bit and send it to the pseudo and maybe OE community with concrete questions. Having isar-users on CC. Identify a few people for CC with git-blame if needbe. Henning Am Wed, 2 Aug 2017 15:24:14 +0200 schrieb "[ext] 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 >