<div dir="ltr"><div><div><div><div>Hi, <br><br></div>I have a couple Wic-related areas in the Yocto documentation. Wondering if this affects documentation. I don't particularly have sections dedicated to using specific canned wic files such as the "directdisk-multi-rootfs" file. However, if there is some mentioning or changing of the docs to help avoid this I could see what I could do.<br><br></div>The sections related to Wic are:<br><br> * <a href="https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-partitioned-images-using-wic">https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-partitioned-images-using-wic</a><br> * <a href="https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-kickstart">https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-kickstart</a><br><br></div>Thanks,<br></div>Scott<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 2, 2018 at 9:31 AM, Volker Vogelhuber <span dir="ltr"><<a href="mailto:v.vogelhuber@digitalendoscopy.de" target="_blank">v.vogelhuber@digitalendoscopy.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I never got any response to my message (until now). So AFAIK I solved the 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" % native_sysroot)<br>
- p_localstatedir = os.environ.get("PSEUDO_LOCALST<wbr>ATEDIR",<br>
- "%s/../pseudo" % 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/../pse<wbr>udo;" % self.rootfs_dir<br>
+ pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir<br>
p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLI<wbr>NKEXP", "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,<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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" target="_blank">v.vogelhuber@digitalendoscopy<wbr>.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I finally found out, what's the reason why the included recovery rootfs has<br>
the wrong UIDs, while the main image has the correct one. The reason seems<br>
to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of 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, an<br>
existing ENV value is used that points to the state dir of the main image<br>
instead of the recovery one's. I guess the reason is that in bitbake.conf<br>
the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is the<br>
main image and not the recovery image only referenced by the main image). So<br>
because that environment variable is already set, the call to mkfs.ext4 for<br>
the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not apply<br>
the correct UID.<br>
<br>
Any ideas how to fix that? I tend to just remove the patch introduced by Ed<br>
Bartosh three years ago (<a href="https://patchwork.openembedded.org/patch/90419/" rel="noreferrer" target="_blank">https://patchwork.openembedde<wbr>d.org/patch/90419/</a>)<br>
because I don't need a custom PSEUDO_PREFIX. But maybe not everyone agrees.<br>
<br>
On 19.01.2018 17:00, Volker Vogelhuber wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 that<br>
is creating only an ext4 image (image-recovery), and the second that is also<br>
creating a WIC image (image-main). I used the IMAGE_FSTYPES variable for<br>
that. The WKS file for the second image is integrating the recovery 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 --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 within<br>
the file system when calling mkfs.ext4 during prepare_rootfs_ext. For 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 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 a<br>
printf in set_inode_extra. There I can see clearly that the source UID for<br>
the file is 0 for the rootfs of the image-main rootfs folder while it 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 root<br>
permissions. I searched for a preparation step where the UIDs are 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 rootfs<br>
has the UID set correctly to zero, I can't understand why it happens. On the<br>
other side I can understand why the UID of the recovery rootfs is set to my<br>
own one, but it stops me from booting that rootfs because the UIDs of 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>
</blockquote>
<br>
<br>
--<br>
<br>
</blockquote></blockquote></div></div><div class="HOEnZb"><div class="h5">
-- <br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openem<wbr>bedded.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>
</div></div></blockquote></div><br></div>