Re: Integration of Pseudo into Isar

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

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