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<[email protected]> 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 > -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
