6.21 E2fsprogs-1.41.10 101 Tests failured -make check

Bill Brown wubrown at gmail.com
Wed May 5 21:23:12 PDT 2010


Ken, thanks for the suggestions.  The mount for /mnt/lfs is full r/w 
with no other parameters.  Your directions to source code locations was 
helpful.  What I find odd is how much in each test seems to pass.  
Indeed, in many of the failed tests I can't see a difference between the 
expect and the corresponding log file.  I have not tried to go on in the 
lfs process having that many errors.

Any other suggestions?

On 5/5/2010 8:48 AM, Ken Moffat wrote:
> On 5 May 2010 01:36, Bill Brown<wubrown at gmail.com>  wrote:
>    
>> Chris, thanks for the prompt response.  I have spent a good chunk of
>> time looking at the tests\*.log&  .failed files.  If like the DOS world,
>> anything but exit status 0 is an error, I suspect the Exit status 127's
>> are failures.
>>      
>   Testsuites vary between packages, and are often very hard to debug.
> I'm not sure about your distinction between errors and failures - a status
> of 0 is a successful test, everything else failed (in some packages, some
> failures are 'expected').  My own view is that status>= 127 often means
> a program is missing.
>
>   In this case, the "meat" of the test is in tests/r_move_itable/script, but
>
>
>    
>>   Here is a snippet from r_move_itable.failed that points
>> to "super-block" issues:
>> root:/sources/e2fsprogs-1.41.10/build/tests# more r_move_itable.failed
>> --- ../../tests/r_move_itable/expect    2009-08-13 01:39:58.000000000 +0000
>> +++ r_move_itable.log    2010-05-05 15:22:33.000000000 +0000
>> @@ -1,2622 +1,28 @@
>>   mke2fs -q -F -o Linux -b 1024 -g 256 test.img 1024
>>   resize2fs -p test.img 10000
>> -Resizing the filesystem on ./test.img to 10000 (1k) blocks.
>> -Begin pass 1 (max = 35)
>> -Extending the inode table     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>> -The filesystem on ./test.img is now 9985 blocks long.
>> -
>> -Pass 1: Checking inodes, blocks, and sizes
>> -Pass 2: Checking directory structure
>> -Pass 3: Checking directory connectivity
>> -Pass 4: Checking reference counts
>> -Pass 5: Checking group summary information
>> -test_filesys: 11/1248 files (0.0% non-contiguous), 1281/9985 blocks
>> -Exit status is 0
>> +../resize/resize2fs: Bad magic number in super-block while trying to
>> open ./tes
>> t.img
>> +Couldn't find valid filesystem superblock.
>> +Exit status is 127
>> ----------------------
>> Looking at the test script if I understand it correctly,  it creates a
>> test file system, resizes it and then checks the resulting fs.  It looks
>> like the fsck completes OK it is not clear at what open of ./test.img is
>> resulting in the magic number error.  At this point I do not have an
>> /etc/fstab file in chroot environment.  There is an empty /etc/mtab
>> file.  I do have the libmagic link libraries in /usr/lib Does this point
>> anyone to the problem causing the 101 e2fsprogs test failures?
>>
>>      
> The "bad magic number" message is EXT2_ET_BAD_MAGIC in
> ./lib/ext2fs/ext2_err.et.in and is probably called from lib/ext2fs/openfs.c
> in ext2fs_open2.  But as to why it would fail, I've no idea.
>
> If in doubt, I normally blame virtual machines :)  But in this case, I
> wonder if you have managed to mount /mnt/lfs with excessive
> restrictions (perhaps 'nodev') ?
>
> ĸen
>    



More information about the lfs-support mailing list