2017-10-25 17:29 GMT+02:00 Alexander Smirnov <asmirnov@ilbers.de>:


On 10/25/2017 05:58 PM, 'Benedikt Niedermayr' via isar-users wrote:
Am 25.10.2017 um 11:48 schrieb Alexander Smirnov:


On 10/24/2017 11:22 PM, Jan Kiszka wrote:
On 2017-10-24 21:34, Alexander Smirnov wrote:
Hello all,

I've successfully dropped 'sudo' around buildchroot operations:

  - Create buildchroot
  - Build dpkg-base package (hello)
  - Build dpkg-raw package (example-raw)

The patch is quite small, proot works out-of-the box. I've tested the
following configurations:

  - multiconfig:qemuarm-wheezy:isar-image-base
  - multiconfig:qemuarm-jessie:isar-image-base
  - multiconfig:qemuarm-stretch:isar-image-base
  - multiconfig:qemui386-jessie:isar-image-base
  - multiconfig:qemui386-stretch:isar-image-base
  - multiconfig:qemuamd64-jessie:isar-image-base
  - multiconfig:qemuamd64-stretch:isar-image-base

So proot is really good tool :-)

If you'd like to reproduce the test, please try my branch: asmirnov/devel

NOTE: do not forget to install proot: apt-get install proot

Build command:
$ bitbake multiconfig:qemuarm-wheezy:isar-image-base
multiconfig:qemuarm-jessie:isar-image-base
multiconfig:qemuarm-stretch:isar-image-base
multiconfig:qemui386-jessie:isar-image-base
multiconfig:qemui386-stretch:isar-image-base
multiconfig:qemuamd64-jessie:isar-image-base
multiconfig:qemuamd64-stretch:isar-image-base


Great news! Hope this passes all tests and then makes it into master soon!


I've tested QEMU machines for images listed above, no difference observed in comparison with original 'sudo' approach. But anyway, it would be nice if somebody else will test this, especially in customer project environment.

May there be a problem when all files belonging to the build user and not to root?

That's exactly the topic why I started proot with buildchroot and why I'm asking about various test results (did you try? :-)).

In the VM that I've built with proot patch I see the following:

root@isar:~# ls -l /usr/bin/ | grep hello
-rwxr-xr-x 1 root root   18068 Oct 24 18:52 hello
root@isar:~#

So the file from hello package (which is built using proot) has root ownership.


In theory the problems could occur during generation of target filesystem, will see. But anyway, Yocto will do this without sudo, so probably here also this could be done.

Alex


What I was trying, was to run a proot based build, from my current Isar fork. Then I had the problem with file permissions (files belonging to build user instead to root).


The Problem can be located at the point when installing the deb packages to the rootfs (do_deploy() with fake root permissions). After exiting the proot all files there have the permissions
of my build user. And after that wic will generate the rootfilesystem image with those permissions.

So when the deb package is generated, all (faked) root permissions are stored but get lost in case of installing that package as normal user, or after exiting the proot.

Yocto does somethin similiar but better:
It starts pseudo, which in turn stores all (faked) file permissions and later runs mkfs.ext3 with the -d option, within pseudo environment.
The -d <rootfs_dir> option makes mkfs to copy all files directly into the created filesystem in a single step.
When mounting that filesystem image (which is only possible as root) I can see the correct file permissions.

I think this similar to creating tar archives. When creating files as root within the fakeroot and compress them as fakeroot user, all root permissions where also stored within the archive. 
When extracting that archive as root, all files have root permissions.
When extracting that archive as user, all files have user permissions.

So the -d option is similiar to compressing files into an archive, I think.

I have not tested that behavior with proot, yet.

Reagards,
Benedikt