9937 2016-07-14 13:04:12 +0000 Make use of pseudo optional, under certain conditions 2016-09-15 12:45:40 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple RESOLVED WONTFIX Medium enhancement Future 1 igor.stoppa richard.purdie poky.bs.watcher poky.watcher sgw --- --- Yes (doc changes required) oldest_to_newest 63972 0 igor.stoppa 2016-07-14 13:04:12 +0000 Premise ------- * Bitbake expects to be used as regular user and relies on pseudo to simulate various activity that would be possible only if it was running as root. * This makes sense when running a build natively, to prevent, among other things, that a broken recipe damages the host installation. * the price paid is that pseudo will introduce an overhead whenever it hijacks a call that would otherwise fail because it would require root privileges. Problems -------- * In some cases, the overhead is just too much. * One might prefer to run bitbake _anyway_ inside a VM or a container, for example for ensuring that the host environment is stable. Or to have an easy way to replicate builder instances. In this case one would easily afford to run as root, because the VM/container can/will be trashed and restored. So the overhead introduced by pseudo is completely unnecessary. Proposal -------- Allow users to run bitbake as root, without pseudo. This can be gated by a liberal amount of checks/warnings, but it should be available for power users who do know what they are doing. It could be even conditioned to the presence of telltales that clearly let the bitbake instance to identify itself as running in a VM/container and therefore accept that they are run as root user. The execution of pseudo could be conditioned to the user running bitbake: keep it if the user is not root, drop it if the user is root. 64167 1 igor.stoppa 2016-07-19 16:20:45 +0000 Based on bug #9449 I would propose to increase the importance of this feature and to take it in consideration for implementation, instead of leaving it parked for "future" releases. 65917 2 igor.stoppa 2016-09-08 11:44:55 +0000 Here are some numbers that back the request. Building an Ostro image with support for swupd took multiple hours, even if the entire content of the image was available already as part of the SSTATE. This was caused mostly by pseudo and the way it handles concurrent accesse to its internal database. After using a hacked version of pseudo that doesn't hijack ownership, the very same build process, run inside a container, took about 20 minutes. The improvement is about 2 orders of magnitude, on a time scale that is very relevant for human beings. 65918 3 igor.stoppa 2016-09-08 11:46:08 +0000 Sorry, 1 order of magnitude. Still quite dramatic, though. 66052 4 richard.purdie 2016-09-12 20:51:32 +0000 Didn't this issue get fixed by some of the changes to pseudo internals? 66069 5 igor.stoppa 2016-09-13 07:22:13 +0000 AFAIK no, it's still open. At least, we could reproduce it about 1 month ago with the latest Ostro. Is there any specific patch/revision we should aim for? As generic comment: as long as the issue persist (pseudo queuing parallel access to the filesystem because of the DB handling), it will not only affect swupd, but any attempt of generating updates for YP, because of the intrinsic nature of the problem. 66075 6 richard.purdie 2016-09-13 09:00:43 +0000 Sadly, even if you allow bitbake to run as root you have several problems: a) recipes need to create their own users which they do with adduser/deluser. In the root model, this would have to be reflected in the underlying user accounts, meaning that a given system had to be dedicated to a given build. b) You can't really obtain a "clean" set of base user/group files since most distros do already have some underlying users which could conflict with those setup by the build. c) You'd have to be very sure that the filesystem you were building on supported things like xattr to match the requirements of the build exactly. Whilst many of these are surmountable by using a specifically developed VM image, it would require very precise setup from the user with a much greater potential for errors. It would go against the ethos of not requiring root access and it would introduce two different ways of running a build, meaning we'd have to double our QA test plan to test everything in both scenarios. For all those reasons, I think we'll have to find a way to fix pseudo to perform better, or swupd to have some pseudo knowledge to help it avoid the performance issues (run different commands in separate pseudo instances?) and that we will not be supporting builds as root, if for no other reason that the impact on the testing matrix. 66078 7 igor.stoppa 2016-09-13 10:43:18 +0000 I won't reopen this, because we clearly have different perspective about what would be more user-friendly and the discussion would not be technical anymore. But I personally think the container based solution would be preferable. Example: It might be by design, yet I find it confusing, that when I build -native packages, they are *not* built with a -native bootstrapped compiler. Instead they are built with the host compiler, leading to any sort of different outcome when 2 people have different host distros. The container approach would put everyone on the same ground and make much more effective use of the SSTATE for -native component. Right now, if I happen to have a host distro which is different from the one used to populate a shared SSTATE, I'm left out in the cold and I have to rebuild all the -native components that are affected. 66192 8 richard.purdie 2016-09-15 10:19:49 +0000 (In reply to comment #7) > It might be by design, yet I find it confusing, that when I build -native > packages, they are *not* built with a -native bootstrapped compiler. > Instead they are built with the host compiler, leading to any sort of > different outcome when 2 people have different host distros. > > The container approach would put everyone on the same ground and make much > more effective use of the SSTATE for -native component. > > Right now, if I happen to have a host distro which is different from the one > used to populate a shared SSTATE, I'm left out in the cold and I have to > rebuild all the -native components that are affected. We do have the concept of "uninative" which does in fact allow one sstate feed to feed native sstate objects to all users. This problem you describe of sstate reuse for native objects therefore doesn't exist any more. 66198 9 igor.stoppa 2016-09-15 12:45:40 +0000 > We do have the concept of "uninative" which does in fact allow one sstate feed to > feed native sstate objects to all users. This problem you describe of sstate > reuse for native objects therefore doesn't exist any more. Yes, I'm aware of uninative, however it doesn't seem to work on my setup. My host distro is SUSE 42.1 (yes, I do get the warning that it's not officially supported) and other people in my team use typically RedHat. According to my understanding, even if the sstate claims that native files built on different hosts are compatible, because they use the same uninative libraries, in place of those coming with the host compiler, yet the compilers used are different (because different distros ship different compilers, usually) and they do produce different binary files. A recent example of this, I believe, is how OTMPFILE is handled. On my SUSE42.1, running code from ostree on the host was generating an error saying that OTMPFILE was not supported. Running basically the same command in a recipe was instead showing that OTMPFILE was supported, but it failed halfway. On fedora, the detection succeeded consistently both in the host and in the pseudo environment.