Host contamination that isn't
I'm getting a lot of messages like this:
amanda: /amanda/usr/sbin/amtoc is owned by uid 1000, which is the same as the user running bitbake. This may be due
to host contamination
amanda: /amanda/usr/sbin/amcrypt-ossl is owned by uid 1000, which is the same as the user running bitbake. This may
be due to host contamination
amanda: /amanda/usr/sbin/amvault is owned by uid 1000, which is the same as the user running bitbake. This may be due
to host contamination
In reality, this is not really a problem. I'm building a recipe which adds a user to my system image that just happens to have the same UID as mine (first user added, go figure). So the messages in this case are quite bogus.
How can I avoid them? When I add my extra user to my image, is there a way to force the UID/GID to something I know is "safe"?
Thanks
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 8 lines · Gary Thomas
I'm getting a lot of messages like this:
amanda: /amanda/usr/sbin/amtoc is owned by uid 1000, which is the same as the user running bitbake. This may be due
to host contamination
amanda: /amanda/usr/sbin/amcrypt-ossl is owned by uid 1000, which is the same as the user running bitbake. This may
be due to host contamination
amanda: /amanda/usr/sbin/amvault is owned by uid 1000, which is the same as the user running bitbake. This may be due
to host contamination
Quoted 7 lines
In reality, this is not really a problem. I'm building a recipe which adds a user to my system image that just happens to have the same UID as mine (first user added, go figure). So the messages in this case are quite bogus.
How can I avoid them? When I add my extra user to my image, is there a way to force the UID/GID to something I know is "safe"?
I solved this by adding '--system' to my USERADD setup.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 14 lines · Gary Thomas
Quoted 13 lines · Gary Thomas
I'm getting a lot of messages like this:
amanda: /amanda/usr/sbin/amtoc is owned by uid 1000, which is the same as the user running bitbake. This may be due
to host contamination
amanda: /amanda/usr/sbin/amcrypt-ossl is owned by uid 1000, which is the same as the user running bitbake. This may
be due to host contamination
amanda: /amanda/usr/sbin/amvault is owned by uid 1000, which is the same as the user running bitbake. This may be due
to host contaminationIn reality, this is not really a problem. I'm building a recipe which adds a user to my system image that just happens to have the same UID as mine (first user added, go figure). So the messages in this case are quite bogus.
Quoted 5 lines
Quoted 2 lines
How can I avoid them? When I add my extra user to my image, is there a way to force the UID/GID to something I know is "safe"?
I solved this by adding '--system' to my USERADD setup.
BTW, if I run 'bitbake <package> -c cleanall' where <package> is the name of my recipe that is creating a user (in this case amanda), shouldn't that user/group be removed from the sysroot? It's not and it took me a long time to realize this - my first attempts at adjusting the USERADD parameters were simply being ignored because the user still existed.
Maybe this is a bug [that I should file]?
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 8 lines · Gary Thomas
BTW, if I run 'bitbake <package> -c cleanall' where <package> is the name of my recipe that is creating a user (in this case amanda), shouldn't that user/group be removed from the sysroot? It's not and it took me a long time to realize this - my first attempts at adjusting the USERADD parameters were simply being ignored because the user still existed.
Maybe this is a bug [that I should file]?
Probably, and yes please.
Ross
Quoted 9 lines · Ross
On 9 March 2016 at 08:28, Gary Thomas <[email protected] <mailto:[email protected]>> wrote:
BTW, if I run 'bitbake <package> -c cleanall' where <package> is the name of my recipe that is creating a user (in this case amanda), shouldn't that user/group be removed from the sysroot? It's not and it took me a long time to realize this - my first attempts at adjusting the USERADD parameters were simply being ignored because the user still existed.
Quoted 4 lines
Maybe this is a bug [that I should file]?
Probably, and yes please.
Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9262
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------