<div dir="ltr"><div>Thanks Ricardo... that helps me.<br><br></div>Scott<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 2, 2018 at 11:18 AM, Ricardo Ribalda Delgado <span dir="ltr"><<a href="mailto:ricardo.ribalda@gmail.com" target="_blank">ricardo.ribalda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Scott<br>
<br>
In this case I believe that it is a bug in wic, for no reason the user<br>
id of bitbake should be leaked into the rootfs.<br>
<br>
Regards<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, May 2, 2018 at 6:44 PM, Scott Rifenbark <<a href="mailto:srifenbark@gmail.com">srifenbark@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> I have a couple Wic-related areas in the Yocto documentation. Wondering if<br>
> this affects documentation. I don't particularly have sections dedicated to<br>
> using specific canned wic files such as the "directdisk-multi-rootfs" file.<br>
> However, if there is some mentioning or changing of the docs to help avoid<br>
> this I could see what I could do.<br>
><br>
> The sections related to Wic are:<br>
><br>
> *<br>
> <a href="https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-partitioned-images-using-wic" rel="noreferrer" target="_blank">https://www.yoctoproject.org/<wbr>docs/2.5/dev-manual/dev-<wbr>manual.html#creating-<wbr>partitioned-images-using-wic</a><br>
> *<br>
> <a href="https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-kickstart" rel="noreferrer" target="_blank">https://www.yoctoproject.org/<wbr>docs/2.5/ref-manual/ref-<wbr>manual.html#ref-kickstart</a><br>
><br>
> Thanks,<br>
> Scott<br>
><br>
> On Wed, May 2, 2018 at 9:31 AM, Volker Vogelhuber<br>
> <<a href="mailto:v.vogelhuber@digitalendoscopy.de">v.vogelhuber@<wbr>digitalendoscopy.de</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I never got any response to my message (until now). So AFAIK I solved the<br>
>> problem with the following patch:<br>
>><br>
>> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py<br>
>> index 84fe85d62b..66ab757aec 100644<br>
>> --- a/scripts/lib/wic/partition.py<br>
>> +++ b/scripts/lib/wic/partition.py<br>
>> @@ -204,15 +204,10 @@ class Partition():<br>
>><br>
>> Currently handles ext2/3/4, btrfs and vfat.<br>
>> """<br>
>> - p_prefix = os.environ.get("PSEUDO_PREFIX"<wbr>, "%s/usr" %<br>
>> native_sysroot)<br>
>> - p_localstatedir = os.environ.get("PSEUDO_<wbr>LOCALSTATEDIR",<br>
>> - "%s/../pseudo" %<br>
>> get_bitbake_var("IMAGE_ROOTFS"<wbr>))<br>
>> - p_passwd = os.environ.get("PSEUDO_PASSWD"<wbr>, rootfs_dir)<br>
>> + pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot<br>
>> + pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../<wbr>pseudo;" %<br>
>> self.rootfs_dir<br>
>> + pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir<br>
>> p_nosymlinkexp = os.environ.get("PSEUDO_<wbr>NOSYMLINKEXP", "1")<br>
>> - pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix<br>
>> - pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir<br>
>> - pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd<br>
>> - pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp<br>
>> pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")<br>
>><br>
>> rootfs = "%s/rootfs_%s.%s.%s" % (cr_workdir, self.label,<br>
>><br>
>><br>
>><br>
>> On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote:<br>
>>><br>
>>> Hi<br>
>>><br>
>>> I just got hit by this one. It is specially nasty because nfsroot<br>
>>> fails to boot if the uids are wrong.<br>
>>><br>
>>> What is the status on this?<br>
>>><br>
>>> On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber<br>
>>> <<a href="mailto:v.vogelhuber@digitalendoscopy.de">v.vogelhuber@<wbr>digitalendoscopy.de</a>> wrote:<br>
>>>><br>
>>>> I finally found out, what's the reason why the included recovery rootfs<br>
>>>> has<br>
>>>> the wrong UIDs, while the main image has the correct one. The reason<br>
>>>> seems<br>
>>>> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of<br>
>>>> the<br>
>>>> main image in both cases.<br>
>>>> I debugged all the calls up to the environment setup in partition.py's<br>
>>>> prepare_rootfs method where a check for an existing PSEUDO_LOCALSTATEDIR<br>
>>>> environment variable is done. That seems to be the problem.<br>
>>>> Instead of using the correct value passed to the prepare_rootfs method,<br>
>>>> an<br>
>>>> existing ENV value is used that points to the state dir of the main<br>
>>>> image<br>
>>>> instead of the recovery one's. I guess the reason is that in<br>
>>>> bitbake.conf<br>
>>>> the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is<br>
>>>> the<br>
>>>> main image and not the recovery image only referenced by the main<br>
>>>> image). So<br>
>>>> because that environment variable is already set, the call to mkfs.ext4<br>
>>>> for<br>
>>>> the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not<br>
>>>> apply<br>
>>>> the correct UID.<br>
>>>><br>
>>>> Any ideas how to fix that? I tend to just remove the patch introduced by<br>
>>>> Ed<br>
>>>> Bartosh three years ago<br>
>>>> (<a href="https://patchwork.openembedded.org/patch/90419/" rel="noreferrer" target="_blank">https://patchwork.<wbr>openembedded.org/patch/90419/</a>)<br>
>>>> because I don't need a custom PSEUDO_PREFIX. But maybe not everyone<br>
>>>> agrees.<br>
>>>><br>
>>>> On 19.01.2018 17:00, Volker Vogelhuber wrote:<br>
>>>>><br>
>>>>><br>
>>>>> I'm currently trying to create a multi RootFS WIC image as mentioned in<br>
>>>>> directdisk-multi-rootfs.wks. For that I have two image recipes. One<br>
>>>>> that<br>
>>>>> is creating only an ext4 image (image-recovery), and the second that is<br>
>>>>> also<br>
>>>>> creating a WIC image (image-main). I used the IMAGE_FSTYPES variable<br>
>>>>> for<br>
>>>>> that. The WKS file for the second image is integrating the recovery<br>
>>>>> image by<br>
>>>>> specifying --rootfs-dir=image-recovery in it's part description.<br>
>>>>><br>
>>>>> # primary / recovery image<br>
>>>>> part / --source rootfs --rootfs-dir=image-main --exclude-path mnt/data/<br>
>>>>> mnt/data2/ --fstype=ext4 --label primary_rootfs --align 1024 --size 700<br>
>>>>> --overhead-factor=1.0<br>
>>>>> part /recovery --source rootfs --rootfs-dir=image-recovery<br>
>>>>> --fstype=ext4<br>
>>>>> --label recovery_rootfs --align 1024 --size 640 --overhead-factor=1.0<br>
>>>>><br>
>>>>> The UIDs of the second rootfs (image-main) are correctly set to 0<br>
>>>>> within<br>
>>>>> the file system when calling mkfs.ext4 during prepare_rootfs_ext. For<br>
>>>>> the<br>
>>>>> recovery rootfs the UID is always set to my own (host) one which is of<br>
>>>>> course not valid for the image where that UID does not exist.<br>
>>>>> I tried calling the mkfs.ext4 command myself from a terminal and for<br>
>>>>> whatever reason an image created out of the rootfs folder of the second<br>
>>>>> image (image-main) recipe is deployed with the correct UID 0, while the<br>
>>>>> rootfs folder of the first image (image-recovery) recipe always uses<br>
>>>>> the UID<br>
>>>>> of the source folder/files.<br>
>>>>><br>
>>>>> I search the code of e2fsprogs for the line that sets the UID and added<br>
>>>>> a<br>
>>>>> printf in set_inode_extra. There I can see clearly that the source UID<br>
>>>>> for<br>
>>>>> the file is 0 for the rootfs of the image-main rootfs folder while it<br>
>>>>> is<br>
>>>>> 10000 (my own UID) for the image-recovery. I wonder how the UID of the<br>
>>>>> image-main rootfs folder can be zero when I don't call any command with<br>
>>>>> root<br>
>>>>> permissions. I searched for a preparation step where the UIDs are<br>
>>>>> managed in<br>
>>>>> the scripts folder of Yocto, but didn't found any hint for the whole<br>
>>>>> behavior. So while it is good that the rootfs partition of the main<br>
>>>>> rootfs<br>
>>>>> has the UID set correctly to zero, I can't understand why it happens.<br>
>>>>> On the<br>
>>>>> other side I can understand why the UID of the recovery rootfs is set<br>
>>>>> to my<br>
>>>>> own one, but it stops me from booting that rootfs because the UIDs of<br>
>>>>> the<br>
>>>>> files and folders are set to a user that does not exist on the target<br>
>>>>> system.<br>
>>>>><br>
>>>>> Can someone please explain to me, how that UID handling is meant to be<br>
>>>>> done?<br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>><br>
>> --<br>
>> ______________________________<wbr>_________________<br>
>> Openembedded-core mailing list<br>
>> <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
>> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">-- <br>
Ricardo Ribalda<br>
</font></span></blockquote></div><br></div>