Created attachment 4765 [details] On the attached file i have both persistent.bbclass and persistent-data.wks.in contents. please add them in meta/classes and scripts/lib/wic/canned-wks/ directories We are getting a pseudo abort while building wic images using gatesgarth branch. I have attached a simpler version of wks and bbclass that we use. This issue isn't present in dunfell. Current master also has this issue. Console Error: | output: mke2fs 1.45.6 (20-Mar-2020) | Discarding device blocks: done | Creating filesystem with 157892 1k blocks and 19840 inodes | Filesystem UUID: 2b06a58d-ba0c-410f-8e0b-84d285bdfb3f | Superblock backups stored on blocks: | 8193, 24577, 40961, 57345, 73729 | | Allocating group tables: done | Writing inode tables: done | Creating journal (4096 blocks): done | Copying files into the device: abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this. | Check logfile: /infrastructure/rgeddysx/OE-CORE/build/tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0-r0/tmp-wic/pseudo1/pseudo.log | Aborted | | WARNING: exit code 1 from a shell command. | ERROR: Task (/infrastructure/rgeddysx/OE-CORE/oe-core/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1' NOTE: Tasks Summary: Attempted 2736 tasks of which 1 didn't need to be rerun and 1 failed. Below are the steps to reproduce the issue: #git clone git://git.openembedded.org/openembedded-core-contrib -b stable/gatesgarth-next oe-core #cd oe-core #git clone git://git.openembedded.org/bitbake -b 1.48 #cd .. #mkdir build #cd build #. ../oe-core/oe-init-build-env . ## Added persistent.bbclass and "persistent-data.wks.in" in the respective dir ## Add the below lines in local.conf PACKAGE_CLASSES ?= "package_rpm" (should be rpm . by default it is ipk) IMAGE_FSTYPES = "wic wic.bmap" EFI_PREFIX = "/boot/efi" WKS_FILE = "persistent-data.wks.in" IMGCLASSES_append = " persistent" IMAGE_ROOTFS_EXCLUDE_PATH_append = " etc/" IMAGE_FEATURES += " package-management" Run the target #bitbake core-image-minimal
Changed the Product from OE-Core to Pseudo since the bug is more related to Pseudo
happen on oe-core master too meta = "HEAD:3a4fed4ae0e8a0d1bd62ea5fa1ef12925e1f20f5"
Could you share the contents of the log file as mentioned in the error: /infrastructure/rgeddysx/OE-CORE/build/tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0-r0/tmp-wic/pseudo1/pseudo.log
Though the console says, Check logfile: /infrastructure/rgeddysx/OE-CORE/build/tmp-glibc/work/qemux86_64-oe-linux/core-image-minimal/1.0-r0/tmp-wic/pseudo1/pseudo.log But the same tmp-wic folder is missing in the build directory. It might have got cleanedup otherwise with do_image_wic task on failure.
Created attachment 4769 [details] Pseudo log file attached pseudo log. i comment out this line so wic keeps the tmp and log files. +++ b/scripts/lib/wic/plugins/imager/direct.py @@ -275,7 +275,7 @@ class DirectPlugin(ImagerPlugin): shutil.move(path, os.path.join(self.outdir, fname)) # remove work directory - shutil.rmtree(self.workdir, ignore_errors=True) + #shutil.rmtree(self.workdir, ignore_errors=True) # Overhead of the MBR partitioning scheme (just one sector) MBR_OVERHEAD = 1
To summarise, you're splitting out part of the rootfs into a separate data directory which is in its own wic partition. The pseudo log is helpful as it is saying: path mismatch [2 links]: ino 258881762 db '/var/lib/rpm/.dbenv.lock' req '/data/persistent/var/lib/rpm/.dbenv.lock'. i.e. that a file is in the pseudo database as being in one location but on disk its been moved. I notice this path looks the same as the symlink trick that the attached class is adding. The issue is likely somewhere in and around how pseudo is monitoring these different paths and this rpm trick not being something used elsewhere. It does sound more like a misconfiguration/misuse of pseudo rather than a bug in pseudo itself but it will need further debugging.
current workaround is to switch the task (do_persistent_fixup) from IMAGE_PREPROCESS_COMMAND to "after do_rootfs before do_flush_pseudodb". IMAGE_PREPROCESS_COMMAND are part of do_image. Gatesgarth after "classes/image_types_wic: Reorder do_flush_pseudodb"[1], the pseudodb flushed before do_image. While in dunfell(3.1.5), pseudodb are flush after do_image. i think this is why it error in gatesgarth but not in dunfell. task_order on dunfell(3.1.5): do_rootfs (68770): log.do_rootfs.68770 do_image_qa (76656): log.do_image_qa.76656 do_write_qemuboot_conf (76660): log.do_write_qemuboot_conf.76660 do_image (76667): log.do_image.76667 do_write_wks_template (77027): log.do_write_wks_template.77027 do_rootfs_wicenv (77028): log.do_rootfs_wicenv.77028 do_flush_pseudodb (77029): log.do_flush_pseudodb.77029 do_image_ext4 (77032): log.do_image_ext4.77032 do_image_tar (77039): log.do_image_tar.77039 do_image_wic (77045): log.do_image_wic.77045 [1] https://git.openembedded.org/openembedded-core/commit/meta/classes?h=gatesgarth&id=445b0a9544b55735496bbb23dbff3399b3b9e9a4
Close this as not a bug, not issue with pseudo tools. This is more to problem with configuration for task sequence. the activity moving files in rootfs should be done in ROOTFS command like ROOTFS_POSTPROCESS_COMMAND, ROOTFS_POSTINSTALL_COMMAND, add to do_rootfs or set the task in between do_rootfs and do_flush_pseudodb. in wks, use --rootfs-dir when the rootfs is build/prepared at other path with its own pseudo.db. use --change-directory for a partition to take a subdirectory within current rootfs (/data in this case) while keeping the correct uid/gid. it should use --change-directory in this case. part /data --source rootfs --fstype=ext4 --label data --align 4096 --use-uuid --change-directory=data --fsoptions rw,noatime