11662 2017-06-14 15:19:10 +0000 wic should mount /boot 2017-07-30 10:37:58 +0000 1 1 7 Build System, Metadata & Runtime OE-Core Scripts and Tools 2.3 x86 Multiple RESOLVED FIXED Medium+ normal 2.4 M2 11291 1 ross.burton eduard.bartosh ross.burton --- --- No (bug/feature does not impact docs) oldest_to_newest 74149 0 ross.burton 2017-06-14 15:19:10 +0000 wic currently doesn't add /boot to the fstab, but it should. 74195 1 eduard.bartosh 2017-06-15 12:29:47 +0000 Should be fixed by this patch: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138228.html 74334 2 eduard.bartosh 2017-06-19 16:59:05 +0000 looks like my patch uncovered old wic bug: RP 13:05 ed2: Does wic write to /etc when its building an image? 13:05 ed2: https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/1183/steps/BuildImages_1/logs/stdio - "tar: ./etc: file changed as we read it" 13:06 ed2: something changed while do_image_tar was running, the other tasks were do_image_jffs2 and do_image_wic. I was wondering if wic would make changes? ed2: so how are other tasks meant to run in parallel without the files changing? 13:08 ed2: nothing is meant to write to the rootfs during do_image_xxx :( Everything looked good so far because wic didn't update / and /boot partitions and 100% of oe images have only 2 partitions - / and /boot However, for more than 2 partitions or even for anything different from / and /boot the bug would cause conflicts similar to above. To properly fix this we need to copy rootfs to temporary directory, update fstab there and make rootfs image out of that directory. I'm going to do that in the next revision of the patchset. 74346 3 ross.burton 2017-06-19 18:37:22 +0000 Copying the entire rootfs sounds very painful: best case you hardlink the entire thing at it's just slow. Can we not use e2fsprogs to manipulate the fs directly? 74384 4 eduard.bartosh 2017-06-20 11:25:09 +0000 yes, that's what I'm going to do. I'll use copyhardlinktree API for that. It's already used in rootfs plugin in the implementation of --exclude option. It works quite fast and doesn't require a lot of code changes. 74385 5 eduard.bartosh 2017-06-20 11:30:43 +0000 I can use debugfs to modify fstab if harlinking is slow. Will test it on sato image to understand if this is the case. 74459 6 eduard.bartosh 2017-06-22 11:09:44 +0000 tested hardlinking approach. It's pretty fast from my point of view: copying sato image takes only 1.3s $ time PYTHONPATH=../meta/lib/:../bitbake/lib/ python3 -c 'from oe.path import copyhardlinktree; import bb; copyhardlinktree("tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs", "/tmp/rootfs-sato")' real 0m1.328s user 0m0.632s sys 0m0.752s $ du -sh tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs 235M tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs $ du -sh /tmp/rootfs-sato/ 235M /tmp/rootfs-sato/ I'm going to use this at least for now. 74567 7 eduard.bartosh 2017-06-27 10:02:05 +0000 done, please review: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138771.html 75341 8 eduard.bartosh 2017-07-27 14:31:35 +0000 Hardlinking roofs directory content using copyhardlinktree API makes do_image_tar task to exit with error "file changed as we read it" as making hardlink changes file ctime. In v4 we copy rootfs content instead of hardlinking it: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/140167.html It's slower a bit, but not very slow. For example it takes 1.5 sec for core-image-sato-dev rootfs with size around 500Mb. 75382 9 eduard.bartosh 2017-07-28 09:55:02 +0000 v5: back to hardlinking: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/140199.html 75435 10 eduard.bartosh 2017-07-30 10:37:58 +0000 the patchset has been accepted to poky master. commit id: ae4ee4d51158eb43f770debf6e41646ef8ed9817