The current version of the gentoo handbook recommends to mount the root filesystem with 'noatime' which causese glibc to fail 'tst_atime'. /proc/mounts should be checked and if noatime appears the test should be skipped. I don't know at the moment how to check if build process is running in a chroot environment. Reproducible: Always Steps to Reproduce:
Post the test output, emerge --info and your /etc/fstab, this has been fixed upstream over a year ago. http://sourceware.org/bugzilla/show_bug.cgi?id=1978
Created attachment 106920 [details] emerge --info and /etc/fstab (inside chroot) emerge --info and /etc/fstab (inside chroot)
Created attachment 106921 [details] emerge --info and /etc/fstab (outside chroot) emerge --info and /etc/fstab (outside chroot)
Possibly this happens because I work in a chroot environment. I followed the handbook until '10.d. Rebooting the System' but instead of rebooting into the new system I run 'emerge -eav system' in the chroot. /dev and /proc are mounted inside the chroot: pearl ~ # mount | grep newGentoo none on /data/newGentoo/proc type proc (rw) /dev on /data/newGentoo/dev type none (rw,bind) (chroot) pearl / # /var/tmp/portage/glibc-2.4-r4/work/build-default-i686-pc-linux-gnu-nptl/libio/tst-atime atime has not changed
It's /proc/mounts that gets parsed by statvfs(). It doesn't particularly surprise me this test fails in a chroot; I'm not sure we should suggest changing the tests to do so. However, please post the contents of /proc/mounts, both from a native environment and from within the chroot.
Only the last two lines differ. They show the two mounts for the chroot: pearl ~ # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,noatime,data=ordered 0 0 proc /proc proc rw,nosuid,nodev,noexec 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0 udev /dev tmpfs rw,nosuid 0 0 devpts /dev/pts devpts rw,nosuid,noexec 0 0 /dev/hda3 /data reiserfs rw,noatime 0 0 none /dev/shm tmpfs rw,noexec 0 0 none /data/newGentoo/proc proc rw 0 0 udev /data/newGentoo/dev tmpfs rw,nosuid 0 0 (chroot) pearl / # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,noatime,data=ordered 0 0 proc /proc proc rw,nosuid,nodev,noexec 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0 udev /dev tmpfs rw,nosuid 0 0 devpts /dev/pts devpts rw,nosuid,noexec 0 0 /dev/hda3 /data reiserfs rw,noatime 0 0 none /dev/shm tmpfs rw,noexec 0 0 none /proc proc rw 0 0 udev /dev tmpfs rw,nosuid 0 0
My guess, looking through the glibc code, is that glibc performs syscall statvs on /tmp; however in the chroot that's actually /data/tmp - filesystem reiserfs, which is likely what the kernel correctly returns as the filesystem of /tmp in the chroot. Later in glibc, statvfs compares path '/tmp' and filesystem 'reiserfs' in /proc/mounts (to find the mount options, which are not part of the data returned by the kernel syscall), and it finds nothing that matches. So it falls back to comparing just '/', which matches the rootfs entry which doesn't have the right options (even if it matched the real '/' entry, it would still be wrong as there's no reason both / and the chroot / would be mounted with the same options). So the statvfs() interface provided by glibc just isn't quite up to the job. I don't think there's anything glibc can do - I don't think there's a kernel interface to get the underlying directory from a path in a chroot, which is what it would need to get the right answer.
> My guess, looking through the glibc code, is that glibc performs syscall statvs > on /tmp; however in the chroot that's actually /data/tmp - filesystem reiserfs, > which is likely what the kernel correctly returns as the filesystem of /tmp in > the chroot. /tmp in chroot is /data/newGentoo/tmp in my case. I do not install in the root of a mounted partition but in a subdir called 'newGentoo': '/' is hda2, '/data' is mountpoint of hda3, '/data/newGentoo' is a subdir > I don't think there's anything glibc can do - I don't think there's a kernel > interface to get the underlying directory from a path in a chroot, which is > what it would need to get the right answer. Thinking about that for a while I have the following ideas: - possibly we cannot find the mount options for a chrooted / - but we can test if we are chrooted (-> check inode of /) - we can also check if any mount contains 'noatime' - we can check if atime-change works in the running system So if atime-change does not work at all, there is at least one filesystem mountet with noatime and we are in a chroot-environment, failing tst-atime should be ignored. Thomas
Seems I'm running in more and more failing tests. Is there an easy way to run tests, do not stop on a failed test and get a list of all failed tests afterwards? For now I have: - tst-atime (caused by chroot) - tst-pselect (only failing with -ck kernel?) - tst-fchownat (no idea until now) tst-fchownat.out: file created error for fchownat using descriptor for normal file not ENOTDIR
For tst-pselect and ck-sources also see http://bhhdoa.org.au/pipermail/ck/2007-January/006552.html
(In reply to comment #8) ... > > on /tmp; however in the chroot that's actually /data/tmp - filesystem > /tmp in chroot is /data/newGentoo/tmp in my case. Yep; mis-type by me but that's what I meant. > So if atime-change does not work at all, there is at least one filesystem > mountet with noatime and we are in a chroot-environment, failing tst-atime > should be ignored. Well, that's a bit vague; one filesystem being noatime doesn't indicate whether the test will pass or fail. statvfs() works fine when not in a chroot. My take is that since statvfs() itself isn't 100% correct in a chroot, we should do nothing to the test as it's giving the right answer and telling us something useful. It's better to know that statvfs() is broken, than to hide the fact. IMHO the only way to resolve this correctly, would be to fix statvfs() itself to work correctly in a chroot. If you have to emerge glibc in a chroot, just do it with FEATURES="-test" - it's possibly not the only thing that may fail. BTW regarding other failures - again, I'm not surprised to see other failures when running in a chroot. Fixing glibc to pass its tests in a chroot() is outside our scope, really, and I suspect upstream won't be too interested either.
> So if atime-change does not work at all, there is at least one filesystem > mountet with noatime and we are in a chroot-environment, failing tst-atime > should be ignored. What I wanted to say is, if ... ... changing atime does not work at all in the running system (i.e. outside the testsuite of the newly build glibc) *and* we can confirm via /proc/mounts that there is at least one fs mounted with noatime *and* we can confirm to be inside chroot ... ... we seem to be in a noatime-chroot so ignore tst-atime's failure
But I also accept that (glibc-)tests are not made for running inside chroot, which I didn't know till now. So, apart from tst-pselect under ck-sources, where I hope to get some feedback via the ck-mailing list, I'm quite happy. Thanks, Thomas
ok; I'll close "CANTFIX" for now. Thanks.
