Poky: master:9de0ad47462c13ac4a2d73e12e92be6c1b4e0415 Steps: 1. download autobuilder.yoctoproject.org/pub/nightly/20130731-1 beagleboard core-image-sato-sdk image, use it bootup target. 2. cd /opt/ltp 3. start ltp test with below cli: ./runltp -p -f syscalls,fs,fsx,dio,io,mm,ipc,sched,math,nptl,pty,admin_tools,timers,commands -l ltp-arch-YYYYMMDD-result.log -C ltp-arch-YYYYMMDD-failed.log -d /opt/tmp &> ltp-arch-YYYYMMDD-output.log 4. the test failed very soon. And it has below error info: creating a ext4 block device failed mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. FATAL: can't mount block device /dev/loop0 5. try to find mkfs.ext4 command in shell, it does not exist. root@beagleboard:/opt/ltp# which mkfs.ext4 root@beagleboard:/opt/ltp# mkfs. mkfs.bfs mkfs.cramfs mkfs.minix mkfs.minix.util-linux
Should LTP be run on Sato? Is this a new bug? Have we run this on SATO before, I thought this should be run on lsb or basic images that include e2fsprogs, I am not sure sato does.
(In reply to comment #1) > Should LTP be run on Sato? Is this a new bug? Have we run this on SATO > before, I thought this should be run on lsb or basic images that include > e2fsprogs, I am not sure sato does. Hi, Yes, ltp should run on sato-sdk image. This is a new bug for beagleboard. My last test it with 20130618 image, that time the test pass. The reason why this time it failed, because ltp test code has been updated. The new test case need "mkfs.ext4" command. We also do this test on 8315E and routerstation BSP, both of these targets test pass. Because they has the "mkfs.ext4" command. The beagleboard failed because it doesn't have e2fsprogs-mke2fs package.
So this is a new test, core-image-sato is busybox based, which means that most tools will be provided by the busybox tools, what's interesting is you say that the MPC and routerstation have those binaries, that should not be the case, are you using images from the autobuilder? I would need to go in and compare how those images and how they are created.
Nevermind I see the image now!
Ok, I tracked this down, this is currently expected behavior. The qemu image also do not have mkfs.ext4 (specifically the e2fsprogs-mke2fs package), as they don't have the "ext2" MACHINE_FEATURE. So this is a new test for LTP that we are running on core-image-sato. I am not sure it makes sense to enable the ext2 for sato just for a test. Where else do we run the LTP test suite.
Hi Saul, Just want to make it clearly, I did all the test on "core-image-sato-sdk" image. Thanks. (In reply to comment #5) > Ok, I tracked this down, this is currently expected behavior. The qemu > image > also do not have mkfs.ext4 (specifically the e2fsprogs-mke2fs package), as > they > don't have the "ext2" MACHINE_FEATURE. So this is a new test for LTP that > we > are running on core-image-sato. I am not sure it makes sense to enable the > ext2 for sato just for a test. Where else do we run the LTP test suite.
So, I discussed this with Mark Hatle and we are in agreement that we don't want to add the mke2fs package to all Sato Images. We can acceptably say that this test will fail on a given set of platforms since they do not include mke2fs package by default. We do know that it can pass on machines that do use the ext2 MACHINE_FEATURE, which installs the e2fsprogs. So we know that Sato can pass these tests. This is the curse and blessing of flexibility.