cc: ed
Is it a very bad idea to revert your patch?
Thanks!
On Wed, May 2, 2018 at 8:17 PM, Ricardo Ribalda Delgado
<ricardo.riba...@gmail.com> wrote:
> Hi
>
> I do not know how many people is actively using wic. We have started
> using it from last week, it is hard to replace old scripts that work
> :)
>
> Try sending it as a proper patch, I can help you if you need it.
>
> Regards
>
> On Wed, May 2, 2018 at 6:31 PM, Volker Vogelhuber
> <v.vogelhu...@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.vogelhu...@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?
>>>>
>>>>
>>>>
>>>> --
>>>>
>>
>
>
>
> --
> Ricardo Ribalda
--
Ricardo Ribalda
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
