[OE-core] Question about multi rootfs UIDs when using wic
Scott Rifenbark
srifenbark at gmail.com
Wed May 2 18:22:26 UTC 2018
Thanks Ricardo... that helps me.
Scott
On Wed, May 2, 2018 at 11:18 AM, Ricardo Ribalda Delgado <
ricardo.ribalda at 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 <srifenbark at 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.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
> >
> >
>
>
>
> --
> Ricardo Ribalda
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180502/2048500e/attachment-0002.html>
More information about the Openembedded-core
mailing list