Hi!
On Fri, May 11, 2018 at 2:42 PM, Grzegorz Mierzejewski <[email protected]> wrote: > Hello all, > > I have the following problem concerning the file's ownership. > In my recipe I install the new file to rootfs and change it's ownership in > do_install function: > do_install () { > install -p -m 644 file1 ${D}/ > chmod 777 ${D}/file1 > chown ${USER_DUMMY} ${D}/file1 > } > > USER_DUMMY is properly created with useradd class. > Thing is, that file1 in rootfs do not have the proper ownership - it is > instead owned by root. > > I've checked the pseudo/files.db in recipe's temp folder and ownership is > proper. > Also, "bitbake my_package -c devshell" shows proper ownership (as it uses > files.db). > But, the same thing done in image's temp folder results in bad (root) > ownership. > > Of course, it happens in modified Jethro delivered by vendor. > Everything works fine on official Jethro for Wandboard. > > Could anyone please give me some hints on what to look for as a root-cause > of such behavior? > Or at least describe the process of generating the files.db for image? > Is it generated based on each package's files.db? > I don't know the exact answer. I hope somebody can tell how us to debug the problem systematically. I have debugged similar issues before without full success and here is what I happen to remember from the top of my head 1) Check whether the ipk contains the desired ownership 1a) An ipk is an "ar" file containing 3 files. Extract it like this $ ar -x tmp/work/corei7-64-poky-linux/openssh/7.5p1-r0/deploy-ipks/corei7-64/openssh-foo_7.5p1-r0_corei7-64.ipk 1b) The files are contained in data.tar.gz See their owners in textual form using $ tar tvf data.tar.gz (I'm not 100% sure how this relates the checking pseudo as you mention it. It might lead to the same result. But I feel checking the ipk contents is less dependent on low level implementation details.) 2) Check out file poky/meta/files/fs-perms.txt. It's documented in the mega manual. 3) Could it be some postinst command that changes it? No detailed commands from the top of my head :( 4) Debug what you have in ROOTFS_POSTPROCESS_COMMAND $ bitbake -e my-image-recipe Maybe something there calls chown? 5) If you cannot find/fix the root cause consider some like ROOTFS_POSTPROCESS_COMMAND_append = "; hack_protections" hack_protections () { chown 42:42 /foo/bar } in your image recipe. This is completely untested pseudo code, modify until it works :) I have succcessfully used ROOTFS_POSTPROCESS_COMMANDS, but have never tried for chown. I am not sure whether you have access to symbolic user/group names in your recipe. Depending on what you have done with useradd, the numerical id might not be fixed. I vaguely remember that I have used DEPENDS += "my-useradd" in a recipe. I think that should make the symbolic ids useradd has created available to another recipe. I have not done it in an image recipe. Regards, Uwe Geuder Neuro Event Labs Oy Tampere, Finland [email protected] (Bot check: fix one obvious typo) -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
