* Question about multi rootfs UIDs when using wic @ 2018-01-19 16:00 Volker Vogelhuber 2018-01-22 10:39 ` Volker Vogelhuber 0 siblings, 1 reply; 12+ messages in thread From: Volker Vogelhuber @ 2018-01-19 16:00 UTC (permalink / raw) To: openembedded-core 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-01-19 16:00 Question about multi rootfs UIDs when using wic Volker Vogelhuber @ 2018-01-22 10:39 ` Volker Vogelhuber 2018-05-02 15:51 ` Ricardo Ribalda Delgado 0 siblings, 1 reply; 12+ messages in thread From: Volker Vogelhuber @ 2018-01-22 10:39 UTC (permalink / raw) To: openembedded-core 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-01-22 10:39 ` Volker Vogelhuber @ 2018-05-02 15:51 ` Ricardo Ribalda Delgado 2018-05-02 16:31 ` Volker Vogelhuber 0 siblings, 1 reply; 12+ messages in thread From: Ricardo Ribalda Delgado @ 2018-05-02 15:51 UTC (permalink / raw) To: Volker Vogelhuber; +Cc: openembedded-core 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@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? > > > -- > > > > > * * > > *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 -- Ricardo Ribalda ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-02 15:51 ` Ricardo Ribalda Delgado @ 2018-05-02 16:31 ` Volker Vogelhuber 2018-05-02 16:44 ` Scott Rifenbark 2018-05-02 18:17 ` Ricardo Ribalda Delgado 0 siblings, 2 replies; 12+ messages in thread From: Volker Vogelhuber @ 2018-05-02 16:31 UTC (permalink / raw) To: Ricardo Ribalda Delgado; +Cc: openembedded-core 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@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? >> >> >> -- >> ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-02 16:31 ` Volker Vogelhuber @ 2018-05-02 16:44 ` Scott Rifenbark 2018-05-02 18:18 ` Ricardo Ribalda Delgado 2018-05-02 18:17 ` Ricardo Ribalda Delgado 1 sibling, 1 reply; 12+ messages in thread From: Scott Rifenbark @ 2018-05-02 16:44 UTC (permalink / raw) To: Volker Vogelhuber; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 6812 bytes --] 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@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@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 > [-- Attachment #2: Type: text/html, Size: 8493 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-02 16:44 ` Scott Rifenbark @ 2018-05-02 18:18 ` Ricardo Ribalda Delgado 2018-05-02 18:22 ` Scott Rifenbark 0 siblings, 1 reply; 12+ messages in thread From: Ricardo Ribalda Delgado @ 2018-05-02 18:18 UTC (permalink / raw) To: Scott Rifenbark; +Cc: Volker Vogelhuber, openembedded-core 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@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@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@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-02 18:18 ` Ricardo Ribalda Delgado @ 2018-05-02 18:22 ` Scott Rifenbark 0 siblings, 0 replies; 12+ messages in thread From: Scott Rifenbark @ 2018-05-02 18:22 UTC (permalink / raw) To: Ricardo Ribalda Delgado; +Cc: Volker Vogelhuber, openembedded-core [-- Attachment #1: Type: text/plain, Size: 7884 bytes --] Thanks Ricardo... that helps me. Scott On Wed, May 2, 2018 at 11:18 AM, Ricardo Ribalda Delgado < ricardo.ribalda@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@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@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@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 > [-- Attachment #2: Type: text/html, Size: 11503 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-02 16:31 ` Volker Vogelhuber 2018-05-02 16:44 ` Scott Rifenbark @ 2018-05-02 18:17 ` Ricardo Ribalda Delgado 2018-05-02 18:25 ` Ricardo Ribalda Delgado 1 sibling, 1 reply; 12+ messages in thread From: Ricardo Ribalda Delgado @ 2018-05-02 18:17 UTC (permalink / raw) To: Volker Vogelhuber; +Cc: openembedded-core 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.vogelhuber@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@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-02 18:17 ` Ricardo Ribalda Delgado @ 2018-05-02 18:25 ` Ricardo Ribalda Delgado 2018-05-07 13:22 ` Ricardo Ribalda Delgado 0 siblings, 1 reply; 12+ messages in thread From: Ricardo Ribalda Delgado @ 2018-05-02 18:25 UTC (permalink / raw) To: Volker Vogelhuber, ed.bartosh; +Cc: openembedded-core 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.ribalda@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.vogelhuber@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@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-02 18:25 ` Ricardo Ribalda Delgado @ 2018-05-07 13:22 ` Ricardo Ribalda Delgado 2018-05-08 13:38 ` Volker Vogelhuber 0 siblings, 1 reply; 12+ messages in thread From: Ricardo Ribalda Delgado @ 2018-05-07 13:22 UTC (permalink / raw) To: Volker Vogelhuber, ed.bartosh; +Cc: openembedded-core Hi Volker I have tried your patch and does not work for me :(. My configuration is a little bit more complex, I have two different machines. The images are generated with: host-kiosk.wks: part /boot/bootloader --source qbootimg-efi --ondisk sda --active --align 1024 --use-uuid --fsoptions defaults,ro part /export --source rootfs --rootfs-dir=kiosk-image --ondisk sda --fstype=ext4 --label export --align 1024 --use-uuid --fsoptions defaults,ro part / --source rootfs --ondisk sda --fstype=ext4 --label rootfs --align 1024 --use-uuid --fsoptions defaults,ro bootloader --ptable gpt --timeout=1 --append="ro rootfstype=ext4 qtec_mem.size=64 MACHINE=qt5022 bitbake host-image ; MACHINE=qt5122 bitbake kiosk-image wic create host-kiosk -e host-image --rootfs-dir kiosk-image=/workdir/build/tmp/work/qt5122-poky-linux/kiosk-image/1.0-r0/rootfs/ --rootfs-dir /workdir/build/tmp/work/qt5022-poky-linux/host-image/1.0-r0/rootfs/ -m In my case this patch does the trick commit 269334f2400c6ee0c7b4fec7d9bf0f701e50c329 (HEAD -> europa, origin/europa) Author: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Date: Mon May 7 13:54:15 2018 +0200 wic: Fix partition files UIDs on multi rootfs images diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py index 84fe85d62b..49921e7494 100644 --- a/scripts/lib/wic/partition.py +++ b/scripts/lib/wic/partition.py @@ -206,7 +206,7 @@ class Partition(): """ 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")) + "%s/../pseudo" % rootfs_dir) p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir) p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1") pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix diff --git a/scripts/lib/wic/plugins/imager/direct.py b/scripts/lib/wic/plugins/imager/direct.py index da1c061063..a90a47c926 100644 --- a/scripts/lib/wic/plugins/imager/direct.py +++ b/scripts/lib/wic/plugins/imager/direct.py @@ -121,6 +121,10 @@ class DirectPlugin(ImagerPlugin): if self._update_fstab(fstab_lines, self.parts): # copy rootfs dir to workdir to update fstab # as rootfs can be used by other tasks and can't be modified + new_pseudo = os.path.realpath(os.path.join(self.workdir, "pseudo")) + from_dir = os.path.join(os.path.join(image_rootfs, ".."), "pseudo") + from_dir = os.path.realpath(from_dir) + copyhardlinktree(from_dir, new_pseudo) new_rootfs = os.path.realpath(os.path.join(self.workdir, "rootfs_copy")) copyhardlinktree(image_rootfs, new_rootfs) fstab_path = os.path.join(new_rootfs, 'etc/fstab') Can you try it on your setup? If it also works for you I will work on getting it merged. Cheers! On Wed, May 2, 2018 at 8:25 PM, Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> wrote: > 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.ribalda@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.vogelhuber@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@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 -- Ricardo Ribalda ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-07 13:22 ` Ricardo Ribalda Delgado @ 2018-05-08 13:38 ` Volker Vogelhuber 2018-05-11 14:27 ` Ricardo Ribalda Delgado 0 siblings, 1 reply; 12+ messages in thread From: Volker Vogelhuber @ 2018-05-08 13:38 UTC (permalink / raw) To: Ricardo Ribalda Delgado, ed.bartosh; +Cc: openembedded-core Hi Ricardo, On 07.05.2018 15:22, Ricardo Ribalda Delgado wrote: > In my case this patch does the trick Unfortunately your patch results in having the recovery image's UID and GID settings to be set to my current user instead of root. So no, your patch does not seem to work for me. I didn't have the time to check in detail what's wrong with your version. > > commit 269334f2400c6ee0c7b4fec7d9bf0f701e50c329 (HEAD -> europa, origin/europa) > Author: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> > Date: Mon May 7 13:54:15 2018 +0200 > > wic: Fix partition files UIDs on multi rootfs images > > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > index 84fe85d62b..49921e7494 100644 > --- a/scripts/lib/wic/partition.py > +++ b/scripts/lib/wic/partition.py > @@ -206,7 +206,7 @@ class Partition(): > """ > 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")) > + "%s/../pseudo" % rootfs_dir) > p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir) > p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1") > pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix > diff --git a/scripts/lib/wic/plugins/imager/direct.py > b/scripts/lib/wic/plugins/imager/direct.py > index da1c061063..a90a47c926 100644 > --- a/scripts/lib/wic/plugins/imager/direct.py > +++ b/scripts/lib/wic/plugins/imager/direct.py > @@ -121,6 +121,10 @@ class DirectPlugin(ImagerPlugin): > if self._update_fstab(fstab_lines, self.parts): > # copy rootfs dir to workdir to update fstab > # as rootfs can be used by other tasks and can't be modified > + new_pseudo = os.path.realpath(os.path.join(self.workdir, "pseudo")) > + from_dir = os.path.join(os.path.join(image_rootfs, ".."), "pseudo") > + from_dir = os.path.realpath(from_dir) > + copyhardlinktree(from_dir, new_pseudo) > new_rootfs = os.path.realpath(os.path.join(self.workdir, > "rootfs_copy")) > copyhardlinktree(image_rootfs, new_rootfs) > fstab_path = os.path.join(new_rootfs, 'etc/fstab') > > > > Can you try it on your setup? If it also works for you I will work on > getting it merged. > > > Cheers! > > On Wed, May 2, 2018 at 8:25 PM, Ricardo Ribalda Delgado > <ricardo.ribalda@gmail.com> wrote: >> 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.ribalda@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.vogelhuber@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@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 > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Question about multi rootfs UIDs when using wic 2018-05-08 13:38 ` Volker Vogelhuber @ 2018-05-11 14:27 ` Ricardo Ribalda Delgado 0 siblings, 0 replies; 12+ messages in thread From: Ricardo Ribalda Delgado @ 2018-05-11 14:27 UTC (permalink / raw) To: Volker Vogelhuber; +Cc: openembedded-core, ed.bartosh Hello So this is what I have tried out: I have downloaded master from openembedded-core (f04e6bd144deb0c8fe2742f66b18904b6619a502) then: bitbake core-image-minimal core-image-base syslinux Create a file test.wks part / --source rootfs --fstype=ext4 --rootfs-dir=core-image-base part /mnt/data1/ --fstype=ext4 --source rootfs --rootfs-dir=core-image-minimal part /mnt/data2/ --fstype=ext4 --source rootfs --rootfs-dir=core-image-minimal bootloader --timeout=0 Then: losetup --partscan --find --read-only --show test*direct sudo mount /dev/loop0p1 /mnt ls -lan /mnt total 40 drwxr-xr-x 18 0 0 1024 May 11 16:11 . drwxr-xr-x 25 0 0 4096 May 6 06:31 .. drwxr-xr-x 2 1000 1000 3072 May 11 15:51 bin drwxr-xr-x 2 1000 1000 1024 May 11 13:59 boot drwxr-xr-x 2 1000 1000 1024 May 11 13:59 dev drwxr-xr-x 25 1000 1000 3072 May 11 15:51 etc drwxr-xr-x 3 1000 1000 1024 May 11 13:59 home drwxr-xr-x 6 1000 1000 3072 May 11 15:51 lib drwx------ 2 0 0 12288 May 11 16:11 lost+found drwxr-xr-x 2 1000 1000 1024 May 11 13:59 media drwxr-xr-x 3 1000 1000 1024 May 11 15:50 mnt drwxr-xr-x 2 1000 1000 1024 May 11 13:59 proc drwxr-xr-x 2 1000 1000 1024 May 11 15:51 run drwxr-xr-x 2 1000 1000 3072 May 11 15:51 sbin drwxr-xr-x 2 1000 1000 1024 May 11 13:59 sys drwxr-xr-t 2 1000 1000 1024 May 11 13:59 tmp drwxr-xr-x 10 1000 1000 1024 May 11 14:54 usr drwxr-xr-x 8 1000 1000 1024 May 11 14:55 var With my patch: ricardo@neopili:/tmp/openembedded-core/build$ ls -lan /mnt total 40 drwxr-xr-x 18 0 0 1024 May 11 16:18 . drwxr-xr-x 25 0 0 4096 May 6 06:31 .. drwxr-xr-x 2 0 0 3072 May 11 15:51 bin drwxr-xr-x 2 0 0 1024 May 11 13:59 boot drwxr-xr-x 2 0 0 1024 May 11 13:59 dev drwxr-xr-x 25 0 0 3072 May 11 15:51 etc drwxr-xr-x 3 0 0 1024 May 11 13:59 home drwxr-xr-x 6 0 0 3072 May 11 15:51 lib drwx------ 2 0 0 12288 May 11 16:18 lost+found drwxr-xr-x 2 0 0 1024 May 11 13:59 media drwxr-xr-x 3 0 0 1024 May 11 15:50 mnt drwxr-xr-x 2 0 0 1024 May 11 13:59 proc drwxr-xr-x 2 0 0 1024 May 11 15:51 run drwxr-xr-x 2 0 0 3072 May 11 15:51 sbin drwxr-xr-x 2 0 0 1024 May 11 13:59 sys drwxrwxrwt 2 0 0 1024 May 11 13:59 tmp drwxr-xr-x 10 0 0 1024 May 11 14:54 usr drwxr-xr-x 8 0 0 1024 May 11 14:55 var I think that I am going to send a formal patch to the mailing list and see if we get some feedback Cheers! On Tue, May 8, 2018 at 3:39 PM Volker Vogelhuber < v.vogelhuber@digitalendoscopy.de> wrote: > Hi Ricardo, > On 07.05.2018 15:22, Ricardo Ribalda Delgado wrote: > > In my case this patch does the trick > Unfortunately your patch results in having the recovery image's UID and > GID settings to be set to my current user instead of root. So no, your > patch does not seem to work for me. > I didn't have the time to check in detail what's wrong with your version. > > > > commit 269334f2400c6ee0c7b4fec7d9bf0f701e50c329 (HEAD -> europa, origin/europa) > > Author: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> > > Date: Mon May 7 13:54:15 2018 +0200 > > > > wic: Fix partition files UIDs on multi rootfs images > > > > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py > > index 84fe85d62b..49921e7494 100644 > > --- a/scripts/lib/wic/partition.py > > +++ b/scripts/lib/wic/partition.py > > @@ -206,7 +206,7 @@ class Partition(): > > """ > > 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")) > > + "%s/../pseudo" % rootfs_dir) > > p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir) > > p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1") > > pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix > > diff --git a/scripts/lib/wic/plugins/imager/direct.py > > b/scripts/lib/wic/plugins/imager/direct.py > > index da1c061063..a90a47c926 100644 > > --- a/scripts/lib/wic/plugins/imager/direct.py > > +++ b/scripts/lib/wic/plugins/imager/direct.py > > @@ -121,6 +121,10 @@ class DirectPlugin(ImagerPlugin): > > if self._update_fstab(fstab_lines, self.parts): > > # copy rootfs dir to workdir to update fstab > > # as rootfs can be used by other tasks and can't be modified > > + new_pseudo = os.path.realpath(os.path.join(self.workdir, "pseudo")) > > + from_dir = os.path.join(os.path.join(image_rootfs, ".."), "pseudo") > > + from_dir = os.path.realpath(from_dir) > > + copyhardlinktree(from_dir, new_pseudo) > > new_rootfs = os.path.realpath(os.path.join(self.workdir, > > "rootfs_copy")) > > copyhardlinktree(image_rootfs, new_rootfs) > > fstab_path = os.path.join(new_rootfs, 'etc/fstab') > > > > > > > > Can you try it on your setup? If it also works for you I will work on > > getting it merged. > > > > > > Cheers! > > > > On Wed, May 2, 2018 at 8:25 PM, Ricardo Ribalda Delgado > > <ricardo.ribalda@gmail.com> wrote: > >> 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.ribalda@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.vogelhuber@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@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 > > > > > > -- Ricardo Ribalda ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-05-11 14:28 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-19 16:00 Question about multi rootfs UIDs when using wic Volker Vogelhuber 2018-01-22 10:39 ` Volker Vogelhuber 2018-05-02 15:51 ` Ricardo Ribalda Delgado 2018-05-02 16:31 ` Volker Vogelhuber 2018-05-02 16:44 ` Scott Rifenbark 2018-05-02 18:18 ` Ricardo Ribalda Delgado 2018-05-02 18:22 ` Scott Rifenbark 2018-05-02 18:17 ` Ricardo Ribalda Delgado 2018-05-02 18:25 ` Ricardo Ribalda Delgado 2018-05-07 13:22 ` Ricardo Ribalda Delgado 2018-05-08 13:38 ` Volker Vogelhuber 2018-05-11 14:27 ` Ricardo Ribalda Delgado
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.