[OE-core] Question about multi rootfs UIDs when using wic

[Volker Vogelhuber]

Hi,

I never got any response to my message (until now). So AFAIK I solved 
the problem with the following patch:

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 84fe85d62b..66ab757aec 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -204,15 +204,10 @@ class Partition():

          Currently handles ext2/3/4, btrfs and vfat.
          """
-        p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" % 
native_sysroot)
-        p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
-                                         "%s/../pseudo" % 
get_bitbake_var("IMAGE_ROOTFS"))
-        p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
+        pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
+        pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" % 
self.rootfs_dir
+        pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir
          p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
-        pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
-        pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir
-        pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd
-        pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp
          pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")

          rootfs = "%s/rootfs_%s.%s.%s" % (cr_workdir, self.label,


On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote:
> Hi
> 
> I just got hit by this one. It is specially nasty because nfsroot
> fails to boot if the uids are wrong.
> 
> What is the status on this?
> 
> On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber
> <v.vogelhuber at digitalendoscopy.de> wrote:
>> I finally found out, what's the reason why the included recovery rootfs has
>> the wrong UIDs, while the main image has the correct one. The reason seems
>> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of the
>> main image in both cases.
>> I debugged all the calls up to the environment setup in partition.py's
>> prepare_rootfs method where a check for an existing PSEUDO_LOCALSTATEDIR
>> environment variable is done. That seems to be the problem.
>> Instead of using the correct value passed to the prepare_rootfs method, an
>> existing ENV value is used that points to the state dir of the main image
>> instead of the recovery one's. I guess the reason is that in bitbake.conf
>> the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is the
>> main image and not the recovery image only referenced by the main image). So
>> because that environment variable is already set, the call to mkfs.ext4 for
>> the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not apply
>> the correct UID.
>>
>> Any ideas how to fix that? I tend to just remove the patch introduced by Ed
>> Bartosh three years ago (https://patchwork.openembedded.org/patch/90419/)
>> because I don't need a custom PSEUDO_PREFIX. But maybe not everyone agrees.
>>
>> On 19.01.2018 17:00, Volker Vogelhuber wrote:
>>>
>>> I'm currently trying to create a multi RootFS WIC image as mentioned in
>>> directdisk-multi-rootfs.wks. For that I have two image recipes. One that
>>> is creating only an ext4 image (image-recovery), and the second that is also
>>> creating a WIC image (image-main). I used the IMAGE_FSTYPES variable for
>>> that. The WKS file for the second image is integrating the recovery image by
>>> specifying --rootfs-dir=image-recovery in it's part description.
>>>
>>> # primary / recovery image
>>> part / --source rootfs --rootfs-dir=image-main --exclude-path mnt/data/
>>> mnt/data2/ --fstype=ext4 --label primary_rootfs --align 1024 --size 700
>>> --overhead-factor=1.0
>>> part /recovery --source rootfs --rootfs-dir=image-recovery --fstype=ext4
>>> --label recovery_rootfs --align 1024 --size 640 --overhead-factor=1.0
>>>
>>> The UIDs of the second rootfs (image-main) are correctly set to 0 within
>>> the file system when calling mkfs.ext4 during prepare_rootfs_ext. For the
>>> recovery rootfs the UID is always set to my own (host) one which is of
>>> course not valid for the image where that UID does not exist.
>>> I tried calling the mkfs.ext4 command myself from a terminal and for
>>> whatever reason an image created out of the rootfs folder of the second
>>> image (image-main) recipe is deployed with the correct UID 0, while the
>>> rootfs folder of the first image (image-recovery) recipe always uses the UID
>>> of the source folder/files.
>>>
>>> I search the code of e2fsprogs for the line that sets the UID and added a
>>> printf in set_inode_extra. There I can see clearly that the source UID for
>>> the file is 0 for the rootfs of the image-main rootfs folder while it is
>>> 10000 (my own UID) for the image-recovery. I wonder how the UID of the
>>> image-main rootfs folder can be zero when I don't call any command with root
>>> permissions. I searched for a preparation step where the UIDs are managed in
>>> the scripts folder of Yocto, but didn't found any hint for the whole
>>> behavior. So while it is good that the rootfs partition of the main rootfs
>>> has the UID set correctly to zero, I can't understand why it happens. On the
>>> other side I can understand why the UID of the recovery rootfs is set to my
>>> own one, but it stops me from booting that rootfs because the UIDs of the
>>> files and folders are set to a user that does not exist on the target
>>> system.
>>>
>>> Can someone please explain to me, how that UID handling is meant to be
>>> done?
>>
>>
>> --
>>