Re: Integration of Pseudo into Isar

[Henning Schild <henning.schild@siemens.com>]

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" <andreas.reichel.ext@siemens.com>:

> # 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
>