Running: [balister@thuvia build]$ wic create ../oe-core/scripts/lib/image/canned-wks/sdimage-bootpart.wks -e uhd-dev-image leads to the following error building the ext4 root fs. [balister@thuvia build]$ sudo ./tmp-glibc/sysroots/x86_64-linux/sbin/mkfs.ext4 -F -i 8192 /var/tmp/wic/build/rootfs_root.ext4 -d /home/balister/src/oe-core/build/tmp-glibc/work/ettus_e300-oe-linux-gnueabi/uhd-dev-image/1.0-r0/rootfs mke2fs 1.42.9 (28-Dec-2013) Discarding device blocks: done Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 90528 inodes, 180930 blocks 9046 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=188743680 6 block groups 32768 blocks per group, 32768 fragments per group 15088 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Copying files into the device: copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem ext2fs_mkdir: Could not allocate block in ext2 filesystem populate_fs: Could not allocate block in ext2 filesystem while making dir "support" populate_fs: Could not allocate block in ext2 filesystem while adding dir "phoenix" populate_fs: Could not allocate block in ext2 filesystem while adding dir "boost" populate_fs: Could not allocate block in ext2 filesystem while adding dir "include" populate_fs: Could not allocate block in ext2 filesystem while adding dir "usr" Error while populating file system The resulting file system has a corrupt file system. Using core-image-minimal I was successful getting a rootfs built. It feels like the issue appears for large root file systems.
This is very similar to several bugs that were supposed to have been fixed in the past by upgrading to the new ext2fs - I need find them to compare. I also need to work on reproducing this once I have info on that.
The info needed to create the image needed to reproduce this is apparently all here: https://github.com/balister/meta-sdr/blob/master/README
This bug shows the same error message: copy_file: Could not allocate block in ext2 filesystem However, that bug referred to the old populate-extfs.sh mechanism. According to that bug, this problem should no longer exist: "We use the "mke2fs -d" to instead of populate-extfs.sh to fix this issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5797 So either mke2fs is broken in the same way, or the old method is somehow sitll being used.
OK, built uhd-dev-image and now trying to create the image, seems I need to set IMAGE_BOOT_FILES to something. What do I need for that? $ wic create ../scripts/lib/image/canned-wks/sdimage-bootpart.wks -e uhd-dev-image Checking basic build environment... Done. Creating image(s)... Error: No boot files defined, IMAGE_BOOT_FILES unset
Sorry, I have : IMAGE_BOOT_FILES = "boot.bin u-boot.img" as a local change. I'm still figuring this wic stuff out :)
(In reply to comment #5) > Sorry, I have : > > IMAGE_BOOT_FILES = "boot.bin u-boot.img" > > as a local change. I'm still figuring this wic stuff out :) No problem. But one more thing at this point - I obviously need a build that produces those artifacts, and am not finding ettus_e300 in any layer. Do I need meta-ettus or something? Or could I use another machine e.g. beaglebone? I know you mentioned that you should be able to use any machine/large rootfs, but I'd like if possible to reproduce exactly what you have so we don't have to guess if I don't see the same thing, etc.
Adding the size option to: part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4 --size 2048 Allows me to create an sd card and have both partitions mount. I do not think this is the correct solution, but does get me unstuck for now.
I think I've reproduced the problem using an sdk image without meta-sdr, but for the uhd-dev-image, I get a do_rootfs error - I won't bother attaching the huge error output, just wondering if it looks familiar and has an easy fix. -r0@armv7a_vfp_neon wireless-tools-doc-1:30.pre9-r0@armv7a_vfp_neon wpa-supplicant-2.2-r0@armv7a_vfp_neon wpa-supplicant-cli-2.2-r0@armv7a_vfp_neon wpa-supplicant-dbg-2.2-r0@armv7a_vfp_neon wpa-supplicant-dev-2.2-r0@armv7a_vfp_neon wpa-supplicant-doc-2.2-r0@armv7a_vfp_neon wpa-supplicant-passphrase-2.2-r0@armv7a_vfp_neon xcb-proto-dbg-1.10-r0@armv7a_vfp_neon xcb-proto-dev-1.10-r0@armv7a_vfp_neon xextproto-dbg-1:7.3.0-r0@armv7a_vfp_neon xextproto-dev-1:7.3.0-r0@armv7a_vfp_neon xproto-dbg-1:7.0.26-r0@armv7a_vfp_neon xproto-dev-1:7.0.26-r0@armv7a_vfp_neon xtrans-dbg-1:1.3.4-r0@armv7a_vfp_neon xtrans-dev-1:1.3.4-r0@armv7a_vfp_neon xtrans-doc-1:1.3.4-r0@armv7a_vfp_neon ERROR: Function failed: do_rootfs ERROR: Logfile of failure stored in: /usr/local/dev/yocto/sdr-wic/build/tmp/work/zc702_zynq7-poky-linux-gnueabi/uhd-dev-image/1.0-r0/temp/log.do_rootfs.20714 ERROR: Task 7 (/usr/local/dev/yocto/sdr-wic/meta-sdr/recipes-images/images/uhd-dev-image.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 3873 tasks of which 32 didn't need to be rerun and 1 failed. No currently running tasks (3873 of 3874) Summary: 1 task failed: /usr/local/dev/yocto/sdr-wic/meta-sdr/recipes-images/images/uhd-dev-image.bb, do_rootfs Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
I think the underlying problem is that the size of the empty partition dd'ed to hold all the rootfs files copied by mkfs -d is determined by 'du -ks' and that value is too small, and isn't target-fileystem-specific. As the wic code for this is based on the oe-core image-creation code, I'd expect the same problems to also be seen for oe-core image-creation, but they're not. I think this has to do with the fact that the oe-core multiplies the rootfs size by an overhead factor whereas wic doeesn't e.g.: IMAGE_OVERHEAD_FACTOR ?= "1.3" I'll experiment with this, and in the worst case, we can do the same thing in wic, but it really should be possible to determine with exact accuracy exactly how many blocks we need for a given rootfs for a given fileystem. Perhaps that should be a separate bug, since it doesn't affect only wic, and will take more research than the quick hack to have wic match oe-core.
And indeeed, changing the overhead factor to no overhead gives the same error bulding core-image-sato-sdk (core-image-sato works fine though): IMAGE_OVERHEAD_FACTOR ?= "1.0" ERROR: Error: The image creation script '/usr/local/dev/yocto/wictest-pcbios/build/tmp/work/genericx86-poky-linux/core-image-sato-sdk/1.0-r0/temp/create_image.ext3' returned 72: 0+0 records in 0+0 records out 0 bytes (0 B) copied, 4.8961e-05 s, 0.0 kB/s mke2fs 1.42.9 (28-Dec-2013) Discarding device blocks: done Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 381504 inodes, 381352 blocks 19067 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=394264576 12 block groups 32768 blocks per group, 32768 fragments per group 31792 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Copying files into the device: copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem copy_file: Could not allocate block in ext2 filesystem ext2fs_mkdir: Could not allocate block in ext2 filesystem populate_fs: Could not allocate block in ext2 filesystem while making dir "bnx2x" populate_fs: Could not allocate block in ext2 filesystem while adding dir "firmware" populate_fs: Could not allocate block in ext2 filesystem while adding dir "lib" Error while populating file system WARNING: /usr/local/dev/yocto/wictest-pcbios/build/tmp/work/genericx86-poky-linux/core-image-sato-sdk/1.0-r0/temp/create_image.ext3:1 exit 72 from mkfs.$fstype -F $extra_imagecmd /usr/local/dev/yocto/wictest-pcbios/build/tmp/deploy/images/genericx86/core-image-sato-sdk-genericx86-20141025041839.rootfs.$fstype -d /usr/local/dev/yocto/wictest-pcbios/build/tmp/work/genericx86-poky-linux/core-image-sato-sdk/1.0-r0/rootfs ERROR: Function failed: do_rootfs ERROR: Logfile of failure stored in: /usr/local/dev/yocto/wictest-pcbios/build/tmp/work/genericx86-poky-linux/core-image-sato-sdk/1.0-r0/temp/log.do_rootfs.15175 ERROR: Task 7 (/usr/local/dev/yocto/wictest-pcbios/meta/recipes-sato/images/core-image-sato-sdk.bb, do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 6482 tasks of which 50 didn't need to be rerun and 1 failed. No currently running tasks (6482 of 6484) Summary: 1 task failed: /usr/local/dev/yocto/wictest-pcbios/meta/recipes-sato/images/core-image-sato-sdk.bb, do_rootfs Summary: There were 81816 WARNING messages shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Would anyone object if I submitted a patch for a fixed size card targetted at 4GB cards? This would be very convenient for people who want avoid resizing the linux partion after boot, and help work around this issue.
I have a patchset ready to submit - I was going to do more testing but let me submit it and then go from there.
Posted patchset which has now been pulled in: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=005d81da2b069672a240b612fbddd0ad9dcead52
Hello, Tested on latest poky master: ae736dbdd140975ba43f06e635b461dbf36a117e, on a core-image-sato-sdk for a genericx86 BSP. Everything worked fine. Steps performed: 1) cloned a fresh copy of poky 2) changed MACHINE to genericx86 in local.conf 3) bitbake core-image-sato-sdk 4) wic create /media/poky/3poky/scripts/lib/image/canned-wks/directdisk.wks -e core-image-sato-sdk Marking as verified. In order to solve this bug, i had a look on 7122 (thanks Tom Z for the hint) Costin
Hello, I forgot to add that between steps 3) and 4)there is an other one: bitbake parted-native Costin