Thanks Ricardo... that helps me. Scott
On Wed, May 2, 2018 at 11:18 AM, Ricardo Ribalda Delgado < ricardo.riba...@gmail.com> wrote: > Hi Scott > > In this case I believe that it is a bug in wic, for no reason the user > id of bitbake should be leaked into the rootfs. > > Regards > > On Wed, May 2, 2018 at 6:44 PM, Scott Rifenbark <srifenb...@gmail.com> > wrote: > > 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.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? > >>>> > >>>> > >>>> > >>>> -- > >>>> > >> -- > >> _______________________________________________ > >> Openembedded-core mailing list > >> Openembedded-core@lists.openembedded.org > >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > > > > > -- > Ricardo Ribalda >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
