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

Wed May 2 16:44:45 UTC 2018

Hi,

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.

The sections related to Wic are:

   *
https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-partitioned-images-using-wic
   *
https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-kickstart

Thanks,
Scott

On Wed, May 2, 2018 at 9:31 AM, Volker Vogelhuber <
v.vogelhuber at digitalendoscopy.de> wrote:

> 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?
>>>>
>>>
>>>
>>> --
>>>
>>> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180502/48baf11a/attachment-0002.html>