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.riba...@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.riba...@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.riba...@gmail.com> wrote: >> Hi >> >> I do not know how many people is actively using wic. We have started >> using it from last week, it is hard to replace old scripts that work >> :) >> >> Try sending it as a proper patch, I can help you if you need it. >> >> Regards >> >> On Wed, May 2, 2018 at 6:31 PM, Volker Vogelhuber >> <v.vogelhu...@digitalendoscopy.de> wrote: >>> Hi, >>> >>> I never got any response to my message (until now). So AFAIK I solved the >>> problem with the following patch: >>> >>> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py >>> index 84fe85d62b..66ab757aec 100644 >>> --- a/scripts/lib/wic/partition.py >>> +++ b/scripts/lib/wic/partition.py >>> @@ -204,15 +204,10 @@ class Partition(): >>> >>> Currently handles ext2/3/4, btrfs and vfat. >>> """ >>> - p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" % >>> native_sysroot) >>> - p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR", >>> - "%s/../pseudo" % >>> get_bitbake_var("IMAGE_ROOTFS")) >>> - p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir) >>> + pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot >>> + pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" % >>> self.rootfs_dir >>> + pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir >>> p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1") >>> - pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix >>> - pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir >>> - pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd >>> - pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp >>> pseudo += "%s " % get_bitbake_var("FAKEROOTCMD") >>> >>> rootfs = "%s/rootfs_%s.%s.%s" % (cr_workdir, self.label, >>> >>> >>> >>> On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote: >>>> >>>> Hi >>>> >>>> I just got hit by this one. It is specially nasty because nfsroot >>>> fails to boot if the uids are wrong. >>>> >>>> What is the status on this? >>>> >>>> On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber >>>> <v.vogelhu...@digitalendoscopy.de> wrote: >>>>> >>>>> I finally found out, what's the reason why the included recovery rootfs >>>>> has >>>>> the wrong UIDs, while the main image has the correct one. The reason >>>>> seems >>>>> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of >>>>> the >>>>> main image in both cases. >>>>> I debugged all the calls up to the environment setup in partition.py's >>>>> prepare_rootfs method where a check for an existing PSEUDO_LOCALSTATEDIR >>>>> environment variable is done. That seems to be the problem. >>>>> Instead of using the correct value passed to the prepare_rootfs method, >>>>> an >>>>> existing ENV value is used that points to the state dir of the main image >>>>> instead of the recovery one's. I guess the reason is that in bitbake.conf >>>>> the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is >>>>> the >>>>> main image and not the recovery image only referenced by the main image). >>>>> So >>>>> because that environment variable is already set, the call to mkfs.ext4 >>>>> for >>>>> the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not apply >>>>> the correct UID. >>>>> >>>>> Any ideas how to fix that? I tend to just remove the patch introduced by >>>>> Ed >>>>> Bartosh three years ago (https://patchwork.openembedded.org/patch/90419/) >>>>> because I don't need a custom PSEUDO_PREFIX. But maybe not everyone >>>>> agrees. >>>>> >>>>> On 19.01.2018 17:00, Volker Vogelhuber wrote: >>>>>> >>>>>> >>>>>> I'm currently trying to create a multi RootFS WIC image as mentioned in >>>>>> directdisk-multi-rootfs.wks. For that I have two image recipes. One that >>>>>> is creating only an ext4 image (image-recovery), and the second that is >>>>>> also >>>>>> creating a WIC image (image-main). I used the IMAGE_FSTYPES variable for >>>>>> that. The WKS file for the second image is integrating the recovery >>>>>> image by >>>>>> specifying --rootfs-dir=image-recovery in it's part description. >>>>>> >>>>>> # primary / recovery image >>>>>> part / --source rootfs --rootfs-dir=image-main --exclude-path mnt/data/ >>>>>> mnt/data2/ --fstype=ext4 --label primary_rootfs --align 1024 --size 700 >>>>>> --overhead-factor=1.0 >>>>>> part /recovery --source rootfs --rootfs-dir=image-recovery --fstype=ext4 >>>>>> --label recovery_rootfs --align 1024 --size 640 --overhead-factor=1.0 >>>>>> >>>>>> The UIDs of the second rootfs (image-main) are correctly set to 0 within >>>>>> the file system when calling mkfs.ext4 during prepare_rootfs_ext. For >>>>>> the >>>>>> recovery rootfs the UID is always set to my own (host) one which is of >>>>>> course not valid for the image where that UID does not exist. >>>>>> I tried calling the mkfs.ext4 command myself from a terminal and for >>>>>> whatever reason an image created out of the rootfs folder of the second >>>>>> image (image-main) recipe is deployed with the correct UID 0, while the >>>>>> rootfs folder of the first image (image-recovery) recipe always uses the >>>>>> UID >>>>>> of the source folder/files. >>>>>> >>>>>> I search the code of e2fsprogs for the line that sets the UID and added >>>>>> a >>>>>> printf in set_inode_extra. There I can see clearly that the source UID >>>>>> for >>>>>> the file is 0 for the rootfs of the image-main rootfs folder while it is >>>>>> 10000 (my own UID) for the image-recovery. I wonder how the UID of the >>>>>> image-main rootfs folder can be zero when I don't call any command with >>>>>> root >>>>>> permissions. I searched for a preparation step where the UIDs are >>>>>> managed in >>>>>> the scripts folder of Yocto, but didn't found any hint for the whole >>>>>> behavior. So while it is good that the rootfs partition of the main >>>>>> rootfs >>>>>> has the UID set correctly to zero, I can't understand why it happens. On >>>>>> the >>>>>> other side I can understand why the UID of the recovery rootfs is set to >>>>>> my >>>>>> own one, but it stops me from booting that rootfs because the UIDs of >>>>>> the >>>>>> files and folders are set to a user that does not exist on the target >>>>>> system. >>>>>> >>>>>> Can someone please explain to me, how that UID handling is meant to be >>>>>> done? >>>>> >>>>> >>>>> >>>>> -- >>>>> >>> >> >> >> >> -- >> Ricardo Ribalda > > > > -- > Ricardo Ribalda -- Ricardo Ribalda -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core