On Monday, 10 de December de 2018 17:12, Mark Hatle <mark.ha...@windriver.com>
wrote:
> On 12/10/18 4:14 AM, madoga wrote:
>
> > > On 12/5/18 11:12 AM, madoga wrote:
> > >
> > > > Hello List,
> > > > I am trying to configure my entire filesystem by using
> > > > FILESYSTEM_PERMS_TABLES
> > > > variable pointing to my custom fs-perms.txt, but it does not work.
> > > > While I
> > > > debugged package.bbclass looking for any error or failure, I found
> > > > something
> > > > strange with os.chmod & os.lchown methods (at function fix_perms):
> > > >
> > > > Fix the permission, owner and group of path
> > > >
> > > > ============================================
> > > >
> > > > def fix_perms(path, mode, uid, gid, dir):
> > > > if mode and not os.path.islink(path):
> > > > #bb.note("Fixup Perms: chmod 0%o %s" % (mode, dir))
> > > > os.chmod(path, mode)
> > > >
> > > > -1 is a special value that means don't change the uid/gid
> > > >
> > > > ==========================================================
> > > >
> > > > if they are BOTH -1, don't bother to lchown
> > > >
> > > > ============================================
> > > >
> > > > if not (uid == -1 and gid == -1):
> > > > #bb.note("Fixup Perms: lchown %d:%d %s" % (uid, gid, dir))
> > > > os.lchown(path, uid, gid)
> > > > I have hardcoded mode variable to “0333”, just for testing:
> > > > os.chmod(path,
> > > > 0o333)and I have seen that permissions were been configured into a
> > > > “0711”. Also
> > > > I am going to ask about os.lchown, due to my filesystem is still been
> > > > owned by
> > > > my user and my group.
> > > > Does anyone have an idea about what is going on? Has somebody have the
> > > > same
> > > > problem?
> > >
> > > The commands run under the pseudo environment. Pseudo captures these
> > > commands
> > > and stores them in a database it can 'replay' at any time.
> > > It only make them in the actual filesystem if permitted by the host.
> > > You must look at the filesystem results in the live system (running
> > > pseudo) or
> > > in the results of the build -- otherwise what you are looking at is not
> > > valid.
> > > (BTW this is the reason that the commended code was left in that
> > > function. In
> > > case something is wrong, just remove the comments and you'll get notes on
> > > what
> > > it is doing to help debug. This shouldn't be necessary unless you are
> > > developing the function itself.. but that is why they are there.)
> >
> > Thank you for your reply Mark!
>
> pseudo replaces fakeroot. Fakeroot can't capture some of the items that are
> needed [and a few other reasons).
>
> > Does the pseudo environment allow to set the entire rootfs by using
> > fakeroot? Perhaps this is not the right way to make it, I am not pretty
> > sure about that. I would like to obtain my rfs with a concrete permissions
> > when bitbake finishes, folders, executables... Is there another/better way
> > to accomplish?
>
> psuedo is just a LD_PRELOAD library that is connected to a database that
> captures permissions changes to files..
>
What do I need to use Yocto under a pseudo environment?
The problem I was describing before was without using LD_PRELOAD and LD_PREFIX.
Now, I have added both into my local.conf:
LD_PRELOAD = "/usr/lib/x86_64-linux-gnu/pseudo/libpseudo.so"
LD_PREFIX = "/usr/"
But BitBake doesn't like it and I cannot find to much information about this
issue...
Thank you!
Mario
> > About debbuging bb.notes, I have already removed the comments and
> > everything seems working OK.
>
> This tells me that it's likely working properly and you are not in the pseudo
> environment. You need to be in that loaded environment with the correct
> database attached to look at the set permissions. Any task in the system
> prefixed by 'fakeroot' will do this for you.
>
> --Mark
>
> > Best Regards,
> > Mario
> >
> > > --Mark
> > >
> > > > Thank you
> > > > Best Regards,
> > > > Mario
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
