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?
--
* *
*Volker Vogelhuber* | Head of Software Design
*PENTAX**Medical
*/Excellence in Focus/
*T:* // +49 (0)821 650566-18 | *F:* +49 (0)821 650566-20
Hoya Corporation – Pentax Medical Division
*Digital Endoscopy GmbH*
Paul-Lenz-Str. 5
86316 Friedberg – Germany
pentaxmedical.com
*Curious*about new *PENTAX*Medical products and activities?
*Follow us*on our Social Media channels!
<https://www.linkedin.com/company/pentax-medical-company>
<https://www.youtube.com/channel/UCn2Ge1Wr7YsPZQiZ25nCkuA>
Handelsregister HRB 27226
Amtsgericht Augsburg
Geschäftsführer: Michael Drexel, Gerald Bottero
_____________________________________
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
