[Buildroot] pseudo: remaining issues...

[Buildroot] pseudo: remaining issues...

[Yann E. MORIN]

Hello All,

We recently switched from using fakeroot to using pseudo to generate the
filesystem images.

After fixing the biggest fallouts from the conversion, we're still left
with a few users reporting remaining issues.

We're now starting to better understand what is going on, and it is
pretty messy...

Those issues seem to occur on second-and-subsequent (re)builds, never on
the first (full) build. They manifest themselves as incorrect acces
rights in the generated images, like (as reported by J?r?me), first line
is correct, second line is incorrect:

    rwxr-xr-x 0/0  4700 2016-11-22 16:57 ./usr/sbin/nologin
    rw------- 0/0  4700 2016-11-22 16:57 ./usr/sbin/nologin

Then J?r?me noticed that those files were the ones stripped during
target-finalize. Removing the call to strip fixed the issue for him.

What this means is that, by tweaking the content of target/ outside of
pseudo, we break its internal state that it saved in its DB.

Now, when pseudo reloades its DB and detects inconsistencies, it wil try
to repare it. Sometimes, it guesses correctly; sometimes, it gueses
wrong.

However, we don't really need the pseudo DB because we ensure setting
all acces rights when assembling the filesystem images; we don;t need to
remember anything.

Hence, we could very well get rid of the DB after exiting pseudo.

Except it still breaks one case.

/dev/console is created under pseudo and its {c,5,1} is tored in the DB.
When we remove the DB, a second run under pseudo will see a real file,
not a {c,5,1}. Then makedevs will whine that /dev/console already exist
as a real file and fail.


So, we now have two antagonist needs:

  - keep the "specialness" of some files so that makedevs does not break
    when creating /dev entries; 

  - get rid of the DB to avoid mis-match when pseudo rebuilds its
    internal state.


There is no way we can (easily) satisfy both.


One solution that would make it work in all cases would be:

  - do the target-finalize actions in a copy of target/
  - generate, filesystem images form that copy
  - trash the copy
  - trash pseudo DB

Another possibility would be to always do changes in target/ under
pseudo:
  - installing packages
  - taget-finalize
  - filesystem generation

Neither solution is trivial, especially so close to the release.


Alternatively, we can revert back to using fakeroot for this release, at
the expense of breaking (already previously broken) setups with SELinux
on the host.


Thoughts? Ideas?

(In Cc:, people already aware/working on the issue).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] pseudo: remaining issues...

[Yann E. MORIN]

All,

On 2016-11-22 22:25 +0100, Yann E. MORIN spake thusly:
> We recently switched from using fakeroot to using pseudo to generate the
> filesystem images.
> 
> After fixing the biggest fallouts from the conversion, we're still left
> with a few users reporting remaining issues.

And we have another issue, that Lucille and Ga?l just tracked down.

They are using a docker instance to run their Buildroot builds, and
noticed that the pseudo DB was empty after a build. However, if they
artificially added a little sleep at the end, to prevent the docker
instance to terminate instantly, the pseudo DB was correctly saved.

That's becasue pesuedo spawns itself a server in the background, and
that server is responsible for loading the DB, maintaining the internal
state, and saving the DB.

However, the DB is saved aftrer the last client exits, adn it can t ake
a bit of time, which is enought time for the docker instance to
terminate, killing (-9) the remaining processes, of whihch the pseudo
server, which then does not have a chance to save its DB.


One solution to this issue would be for us to run our own pseudo server,
adn terminat it ourselves, then wait for it, something along those lines:

    # Spawn our server
    pseudo -f
    pseudo_pid=$!

    # Run the actual comand
    pseudo real-command

    # Kil and wait for the server
    pseudo -S
    wait $pseudo_pid


Thoughts? Tests? ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] pseudo: remaining issues...

[Arnout Vandecappelle]

On 22-11-16 22:25, Yann E. MORIN wrote:
> One solution that would make it work in all cases would be:
> 
>   - do the target-finalize actions in a copy of target/
>   - generate, filesystem images form that copy
>   - trash the copy
>   - trash pseudo DB

 This could fit pretty well in a per-package-staging like approach (but then per
package target, obviously). So each package installs in its own version of the
target directory, and at the end everything is put together into the final
target. The latter can be done under pseudo.

 BTW, it's not really needed to repeat all the makedevs etc. steps under pseudo
for every filesystem, we could just do that once, and then generate each
filesystem (under pseudo again of course). But that doesn't fix the issues with
rebuilding, of course.


> Another possibility would be to always do changes in target/ under
> pseudo:
>   - installing packages
>   - taget-finalize
>   - filesystem generation

 I think this option is where we want to go long-term. Packages are meant to be
installed under sudo, so installing them under pseudo is a good idea.

 It's not so trivial for us, though. In openembedded they can easily do the
equivalent of install-target under pseudo, but we can't because the commands run
under individual shells in make. There are a few possibilities to work around
that, but it needs some thinking.

> Neither solution is trivial, especially so close to the release.
> 
> 
> Alternatively, we can revert back to using fakeroot for this release, at
> the expense of breaking (already previously broken) setups with SELinux
> on the host.

 It looks like that will be the way to go :-(

 Note that we'll also need to revert c85cd189dc1d (as discussed on IRC), because
of the /dev/console thing you described. That used to work under fakeroot
because the mknod() was done even if the (normal) file existed already, but with
c85cd189dc1d it won't work anymore under fakeroot (because there we don't store
the database).


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] pseudo: remaining issues...

[Gaël PORTAY]

Yann,

On Tue, Nov 22, 2016 at 11:16:30PM +0100, Yann E. MORIN wrote:
> And we have another issue, that Lucille and Ga?l just tracked down.
> 
> They are using a docker instance to run their Buildroot builds, and
> noticed that the pseudo DB was empty after a build. However, if they
> artificially added a little sleep at the end, to prevent the docker
> instance to terminate instantly, the pseudo DB was correctly saved.
> 
> That's becasue pesuedo spawns itself a server in the background, and
> that server is responsible for loading the DB, maintaining the internal
> state, and saving the DB.
> 
> However, the DB is saved aftrer the last client exits, adn it can t ake
> a bit of time, which is enought time for the docker instance to
> terminate, killing (-9) the remaining processes, of whihch the pseudo
> server, which then does not have a chance to save its DB.
> 
> 
> One solution to this issue would be for us to run our own pseudo server,
> adn terminat it ourselves, then wait for it, something along those lines:
> 
>     # Spawn our server
>     pseudo -f
>     pseudo_pid=$!
> 
>     # Run the actual comand
>     pseudo real-command
> 
>     # Kil and wait for the server
>     pseudo -S
>     wait $pseudo_pid
> 

I was thinking the same thing... spawning our own server to make sure it
terminates before the wrapper completion.

> 
> Thoughts? Tests? ;-)

After regarding the code of pseudo, the easiest workaround is to update the
wrapper script to do what you mentionned above.

I have suggested a patch named:
[PATCH] pseudo-wrapper: fix console issue

This works on my setup either with a traditional build (on host) or with our
docker wrapper.

[Buildroot] pseudo: remaining issues...

[Gaël PORTAY]

Hi all,

On Tue, Nov 22, 2016 at 10:25:34PM +0100, Yann E. MORIN wrote:
> Those issues seem to occur on second-and-subsequent (re)builds, never on
> the first (full) build. They manifest themselves as incorrect acces
> rights in the generated images, like (as reported by J?r?me), first line
> is correct, second line is incorrect:
> 
>     rwxr-xr-x 0/0  4700 2016-11-22 16:57 ./usr/sbin/nologin
>     rw------- 0/0  4700 2016-11-22 16:57 ./usr/sbin/nologin
> 
> Then J?r?me noticed that those files were the ones stripped during
> target-finalize. Removing the call to strip fixed the issue for him.
> 

I am a bit confused of why the strip is altering the file permissions...

Is it sure the strip causes this issue? I cannot reproduce the issue.

J?r?me: could you tell me how to reproduce easily your issue?

> What this means is that, by tweaking the content of target/ outside of
> pseudo, we break its internal state that it saved in its DB.
> 

Indeed...

But we can still change files from target directory as soon as we make sure we
are not altering data stored in its database, ie.:

$ echo ".schema" | sqlite3 output/build/.pseudodb/files.db 
CREATE TABLE files ( id INTEGER PRIMARY KEY, path VARCHAR, dev INTEGER, ino INTEGER, uid INTEGER, gid INTEGER, mode INTEGER, rdev INTEGER, deleting INTEGER );
CREATE TABLE xattrs ( id INTEGER PRIMARY KEY, dev INTEGER, ino INTEGER, name VARCHAR, value VARCHAR );
CREATE TABLE migrations ( id INTEGER PRIMARY KEY, version INTEGER, stamp INTEGER, sql VARCHAR );
CREATE INDEX files__path_dev_ino ON files ( path, dev, ino );
CREATE INDEX files__dev_ino ON files ( dev, ino );
CREATE INDEX xattrs_dev_ino ON xattrs ( dev, ino );
CREATE INDEX xattrs_dev_ino_name ON xattrs ( dev, ino, name );
CREATE INDEX migration__version ON migrations ( version );

Damn... does the stamp fields from the migrations table is the file timestamp?

If so, we are fucked up :( (it depends also of the meaning of migration).

> Now, when pseudo reloades its DB and detects inconsistencies, it wil try
> to repare it. Sometimes, it guesses correctly; sometimes, it gueses
> wrong.
> 
> However, we don't really need the pseudo DB because we ensure setting
> all acces rights when assembling the filesystem images; we don;t need to
> remember anything.

Except for the file we create using pseudo... ie. makedevs

> 
> Hence, we could very well get rid of the DB after exiting pseudo.
> 
> Except it still breaks one case.
> 
> /dev/console is created under pseudo and its {c,5,1} is tored in the DB.
> When we remove the DB, a second run under pseudo will see a real file,
> not a {c,5,1}. Then makedevs will whine that /dev/console already exist
> as a real file and fail.
> 

:)

... so not a good idea to drop the db without dropping the files created by the
script under pseudo (ie. makedevs, at least).

> 
> So, we now have two antagonist needs:
> 
>   - keep the "specialness" of some files so that makedevs does not break
>     when creating /dev entries; 
> 
>   - get rid of the DB to avoid mis-match when pseudo rebuilds its
>     internal state.
> 
> 
> There is no way we can (easily) satisfy both.
> 
> 
> One solution that would make it work in all cases would be:
> 
>   - do the target-finalize actions in a copy of target/
>   - generate, filesystem images form that copy
>   - trash the copy
>   - trash pseudo DB
> 

I am not a big fan of that solution... I do not like copy :(

> Another possibility would be to always do changes in target/ under
> pseudo:
>   - installing packages
>   - taget-finalize
>   - filesystem generation
> 

I am quite new to buildroot (a 2-weeks young hobbiest), but I guess only
target-finalize alters the target directory; I mean for customization.

So maybe, if it helps, only target-finalize can be run under pseudo.

But I agree those steps should all be run under pseudo.

> Neither solution is trivial, especially so close to the release.
> 
> 
> Alternatively, we can revert back to using fakeroot for this release, at
> the expense of breaking (already previously broken) setups with SELinux
> on the host.
> 

Every patches we made, take us closer to the perfect intergration of pseudo into
BR :)

> 
> Thoughts? Ideas?
> 

The bug concerning the issue with device attribute is certainely solved.
See my patch `[PATCH] pseudo-wrapper: fix console issue' which is an
intergration of what you suggested.

... so lets fixup the bug reported by Jerome!

[Buildroot] pseudo: remaining issues...

[Gaël PORTAY]

On Wed, Nov 23, 2016 at 12:02:19AM +0100, Arnout Vandecappelle wrote:
> 
> 
> On 22-11-16 22:25, Yann E. MORIN wrote:
> > One solution that would make it work in all cases would be:
> > 
> >   - do the target-finalize actions in a copy of target/
> >   - generate, filesystem images form that copy
> >   - trash the copy
> >   - trash pseudo DB
> 
>  This could fit pretty well in a per-package-staging like approach (but then per
> package target, obviously). So each package installs in its own version of the
> target directory, and at the end everything is put together into the final
> target. The latter can be done under pseudo.
> 
>  BTW, it's not really needed to repeat all the makedevs etc. steps under pseudo
> for every filesystem, we could just do that once, and then generate each
> filesystem (under pseudo again of course). But that doesn't fix the issues with
> rebuilding, of course.
> 

Indeed... or (even better?), run makdevs every time the makedevs_table.txt is
updated.

> > Another possibility would be to always do changes in target/ under
> > pseudo:
> >   - installing packages
> >   - taget-finalize
> >   - filesystem generation
> 
>  I think this option is where we want to go long-term. Packages are meant to be
> installed under sudo, so installing them under pseudo is a good idea.
> 

Agree.

>  It's not so trivial for us, though. In openembedded they can easily do the
> equivalent of install-target under pseudo, but we can't because the commands run
> under individual shells in make. There are a few possibilities to work around
> that, but it needs some thinking.

I am not sure to understand...

[Buildroot] pseudo: remaining issues...

[Thomas Petazzoni]

Hello,

On Tue, 22 Nov 2016 22:25:34 +0100, Yann E. MORIN wrote:

> Alternatively, we can revert back to using fakeroot for this release, at
> the expense of breaking (already previously broken) setups with SELinux
> on the host.

I am more and more thinking that this is what we should do. Not only
pseudo still has issues, but even once all issues will be fixed, it is
a much much more complicated and annoying solution than fakeroot:

 - It requires additional dependencies (host-sqlite, host-attr)

 - It requires a complicated setup, with a daemon, that you need to
   manually start and stop (because the internal pseudo mechanism to
   start/stop the daemon doesn't work properly)

So I really believe we should revert to fakeroot, and investigate what
this SELinux problem is exactly. Looking more at the original bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1238802, what is the actual
problem for us? Why do we care about preserving the SELinux labels of
files within the fakeroot environment? We don't support SELinux, and
even if we did, most likely the SELinux labels that exist on the host
machine would not make sense for the target filesystem.

So is the real problem with fakeroot on Fedora related to SELinux?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] pseudo: remaining issues...

[Maxime Hadjinlian]

Hi everyone,

I have experienced the same problem as Jerome on some machines, in my
cases I haven't noticed that it was the striped files but it's pretty
hard to reproduce.

The issues is that random files gets random rights on random machines,
ideal scenario.

On Wed, Nov 23, 2016 at 9:35 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 22 Nov 2016 22:25:34 +0100, Yann E. MORIN wrote:
>
>> Alternatively, we can revert back to using fakeroot for this release, at
>> the expense of breaking (already previously broken) setups with SELinux
>> on the host.
>
> I am more and more thinking that this is what we should do. Not only
> pseudo still has issues, but even once all issues will be fixed, it is
> a much much more complicated and annoying solution than fakeroot:
Here's my 2 cents from someone planning to use the next release to
build a product:
If the community decide to keep pseudo, I will keep my patches that
revert them until everything's fixed (I am willing to do test, I do
not have time to investigate though). There's too much issues too
close to the release deadline and I don't really care about SELinux
(as I said my opinion is from my professional point of view, I
perfectly understand why it's an issues and it should be addressed
from the BR point of view).
>
>  - It requires additional dependencies (host-sqlite, host-attr)
>
>  - It requires a complicated setup, with a daemon, that you need to
>    manually start and stop (because the internal pseudo mechanism to
>    start/stop the daemon doesn't work properly)
>
> So I really believe we should revert to fakeroot, and investigate what
> this SELinux problem is exactly. Looking more at the original bug at
> https://bugzilla.redhat.com/show_bug.cgi?id=1238802, what is the actual
> problem for us? Why do we care about preserving the SELinux labels of
> files within the fakeroot environment? We don't support SELinux, and
> even if we did, most likely the SELinux labels that exist on the host
> machine would not make sense for the target filesystem.
>
> So is the real problem with fakeroot on Fedora related to SELinux?
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] pseudo: remaining issues...

[Arnout Vandecappelle]

On 23-11-16 07:37, Ga?l PORTAY wrote:
> On Wed, Nov 23, 2016 at 12:02:19AM +0100, Arnout Vandecappelle wrote:
>>
>>
>> On 22-11-16 22:25, Yann E. MORIN wrote:
>>> One solution that would make it work in all cases would be:
>>>
>>>   - do the target-finalize actions in a copy of target/
>>>   - generate, filesystem images form that copy
>>>   - trash the copy
>>>   - trash pseudo DB
>>
>>  This could fit pretty well in a per-package-staging like approach (but then per
>> package target, obviously). So each package installs in its own version of the
>> target directory, and at the end everything is put together into the final
>> target. The latter can be done under pseudo.
>>
>>  BTW, it's not really needed to repeat all the makedevs etc. steps under pseudo
>> for every filesystem, we could just do that once, and then generate each
>> filesystem (under pseudo again of course). But that doesn't fix the issues with
>> rebuilding, of course.
>>
> 
> Indeed... or (even better?), run makdevs every time the makedevs_table.txt is
> updated.

 Well, makedevs *will* rerun in every target-finalize (i.e. every time you do
'make'). I see no reason to stop doing that. We just don't need to run it
separately for every filesystem.


>>> Another possibility would be to always do changes in target/ under
>>> pseudo:
>>>   - installing packages
>>>   - taget-finalize
>>>   - filesystem generation
>>
>>  I think this option is where we want to go long-term. Packages are meant to be
>> installed under sudo, so installing them under pseudo is a good idea.
>>
> 
> Agree.
> 
>>  It's not so trivial for us, though. In openembedded they can easily do the
>> equivalent of install-target under pseudo, but we can't because the commands run
>> under individual shells in make. There are a few possibilities to work around
>> that, but it needs some thinking.
> 
> I am not sure to understand...

 Look at the install-target step:

> # Install to target dir
> $(BUILD_DIR)/%/.stamp_target_installed:
>         @$(call step_start,install-target)
>         @$(call MESSAGE,"Installing to target")
>         $(foreach hook,$($(PKG)_PRE_INSTALL_TARGET_HOOKS),$(call $(hook))$(sep))
>         +$($(PKG)_INSTALL_TARGET_CMDS)

We can't simply replace this one with
	+pseudo $($(PKG)_INSTALL_TARGET_CMDS)
because INSTALL_TARGET_CMDS may consist of *several* commands. With the above
change, only the first one would be done under pseudo.

 As I wrote, there are several solutions, but it's far from trivial.


 Note that another issue is that packages may mess with TARGET_DIR outside of
install-target. They shouldn't, of course, but you never know... So we should
also add some protection that detects this.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] pseudo: remaining issues...

[Yann E. MORIN]

Arnout, All,

On 2016-11-23 00:02 +0100, Arnout Vandecappelle spake thusly:
> On 22-11-16 22:25, Yann E. MORIN wrote:
> > One solution that would make it work in all cases would be:
> > 
> >   - do the target-finalize actions in a copy of target/
> >   - generate, filesystem images form that copy
> >   - trash the copy
> >   - trash pseudo DB
> 
>  This could fit pretty well in a per-package-staging like approach (but then per
> package target, obviously). So each package installs in its own version of the
> target directory, and at the end everything is put together into the final
> target. The latter can be done under pseudo.
> 
>  BTW, it's not really needed to repeat all the makedevs etc. steps under pseudo
> for every filesystem, we could just do that once, and then generate each
> filesystem (under pseudo again of course). But that doesn't fix the issues with
> rebuilding, of course.

You mean, like a patch I sent more than one year ago ;-)
    http://lists.busybox.net/pipermail/buildroot/2015-September/140525.html

Ok, this one still calls makedevs in each fs image generation, because
we were still using fakeroot at the time. We could now also move the
makedevs in the common part.

/me should probablky re-spin this series...

> > Another possibility would be to always do changes in target/ under
> > pseudo:
> >   - installing packages
> >   - taget-finalize
> >   - filesystem generation
> 
>  I think this option is where we want to go long-term. Packages are meant to be
> installed under sudo, so installing them under pseudo is a good idea.

Yes, and this is still quite interesting for the per-package-target, as
you hinted above.

>  It's not so trivial for us, though. In openembedded they can easily do the
> equivalent of install-target under pseudo, but we can't because the commands run
> under individual shells in make. There are a few possibilities to work around
> that, but it needs some thinking.

No, it's not trivial.

We could quite easily move target-finalize to a helper script and call
that through pseudo, but the individual package commands are more
complex to pseudo-ify... Not impossible, though, if we look at how this
is done for the filesystems (but I'd find it ugly)...

> > Neither solution is trivial, especially so close to the release.
> > 
> > 
> > Alternatively, we can revert back to using fakeroot for this release, at
> > the expense of breaking (already previously broken) setups with SELinux
> > on the host.
> 
>  It looks like that will be the way to go :-(
> 
>  Note that we'll also need to revert c85cd189dc1d (as discussed on IRC), because
> of the /dev/console thing you described. That used to work under fakeroot
> because the mknod() was done even if the (normal) file existed already, but with
> c85cd189dc1d it won't work anymore under fakeroot (because there we don't store
> the database).

Yup... :-/

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] pseudo: remaining issues...

[Yann E. MORIN]

Arnout, All,

On 2016-11-23 11:10 +0100, Arnout Vandecappelle spake thusly:
[--SNIP--]
>  Note that another issue is that packages may mess with TARGET_DIR outside of
> install-target. They shouldn't, of course, but you never know... So we should
> also add some protection that detects this.

Yup, redirect TARGET_DIR to a temporary place during the staging and
host installs, and detect if this is not empty (ditto for staging during
target install...).

But for some packages (toolchain?) we install both in staging and target
in the same command set... (I had started a aseries that did the split
some two years ago, I just trashed it for various reasons).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] pseudo: remaining issues...

[Waldemar Brodkorb]

Hi,
Thomas Petazzoni wrote,

> Hello,
> 
> On Tue, 22 Nov 2016 22:25:34 +0100, Yann E. MORIN wrote:
> 
> > Alternatively, we can revert back to using fakeroot for this release, at
> > the expense of breaking (already previously broken) setups with SELinux
> > on the host.
> 
> I am more and more thinking that this is what we should do. Not only
> pseudo still has issues, but even once all issues will be fixed, it is
> a much much more complicated and annoying solution than fakeroot:
> 
>  - It requires additional dependencies (host-sqlite, host-attr)
> 
>  - It requires a complicated setup, with a daemon, that you need to
>    manually start and stop (because the internal pseudo mechanism to
>    start/stop the daemon doesn't work properly)
> 
> So I really believe we should revert to fakeroot, and investigate what
> this SELinux problem is exactly. Looking more at the original bug at
> https://bugzilla.redhat.com/show_bug.cgi?id=1238802, what is the actual
> problem for us? Why do we care about preserving the SELinux labels of
> files within the fakeroot environment? We don't support SELinux, and
> even if we did, most likely the SELinux labels that exist on the host
> machine would not make sense for the target filesystem.
> 
> So is the real problem with fakeroot on Fedora related to SELinux?

If my 2 cent counts, I would revert the pseudo stuff.
It is so complex just shortly before release, just to have some
exotic configurations fixed.

I am also starting some new project with the next release and would
like to have the old fakeroot stuff.

best regards
 Waldemar

[Buildroot] pseudo: remaining issues...

[Peter Korsgaard]

On Wed, Nov 23, 2016 at 9:35 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> I am more and more thinking that this is what we should do. Not only
> pseudo still has issues, but even once all issues will be fixed, it is
> a much much more complicated and annoying solution than fakeroot:
>
>  - It requires additional dependencies (host-sqlite, host-attr)
>
>  - It requires a complicated setup, with a daemon, that you need to
>    manually start and stop (because the internal pseudo mechanism to
>    start/stop the daemon doesn't work properly)
>
> So I really believe we should revert to fakeroot, and investigate what
> this SELinux problem is exactly.

I agree. Lets play it safe and stick to fakeroot for now. I'm not sure
what pseudo really buys us for all this extra complexity (besides the
selinux issue, but see below).


> Looking more at the original bug at
> https://bugzilla.redhat.com/show_bug.cgi?id=1238802, what is the actual
> problem for us? Why do we care about preserving the SELinux labels of
> files within the fakeroot environment? We don't support SELinux, and
> even if we did, most likely the SELinux labels that exist on the host
> machine would not make sense for the target filesystem.
>
> So is the real problem with fakeroot on Fedora related to SELinux?

I've set up a Fedora VM and looked closer at the issue. The problem
isn't directly related to fakeroot. Instead it is (arguably) a bug in
'sed -i'. Fedora uses SELinux and sed on Fedora is built with SELinux
support. When sed detects that SELinux is enabled, then it tries to
copy the SELinux xattrs from whe source file to the new temporary file
it creates when the -i option is used. As fakeroot isn't built with
xattr support this fails, and we end up with output/build/ubinize.cfg
with zero permissions, causing ubinize to fail when it cannot read it.

A workaround is to simply not use sed -i inside ROOTFS_UBI_CMD, E.G.
replace the install + sed -i with a single sed >
output/build/ubinize.cfg.

I will send a patch to do that, so we can keep #9386 fixed after
reverting to fakeroot.

-- 
Bye, Peter Korsgaard