Bug #10998
closedTestIO#test_seek fails in chroot with Linux 3.19
Description
Recently, Ruby builds driven by CI started to fail on Fedora builders [1] with following error [6]:
2) Error:
TestIO#test_seek:
Errno::ENOENT: No such file or directory - no matching entry
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1711:in `fsname'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1711:in `can_seek_data'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1752:in `block (2 levels) in test_seek'
/builddir/build/BUILD/ruby-2.2.1/lib/open-uri.rb:36:in `open'
/builddir/build/BUILD/ruby-2.2.1/lib/open-uri.rb:36:in `open'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1751:in `block in test_seek'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1470:in `make_tempfile'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1728:in `test_seek'
3) Error:
TestIO#test_seek_symwhence:
Errno::ENOENT: No such file or directory - no matching entry
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1711:in `fsname'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1711:in `can_seek_data'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1800:in `block (2 levels) in test_seek_symwhence'
/builddir/build/BUILD/ruby-2.2.1/lib/open-uri.rb:36:in `open'
/builddir/build/BUILD/ruby-2.2.1/lib/open-uri.rb:36:in `open'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1799:in `block in test_seek_symwhence'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1470:in `make_tempfile'
/builddir/build/BUILD/ruby-2.2.1/test/ruby/test_io.rb:1781:in `test_seek_symwhence'
We tracked down the issue and we believe that it is due to upgrade of Kernel from 3.17.8 to 3.19.1. In recent kernel, this commit [2] influences content of mtab in chroot (which we are using to setup our build roots). This is content of /etc/mtab using 3.17 kernel [3] and this is with 3.19 kernel [4]. As you can see, with recent kernel, there is no trace of root directory and hence the fsname method [5] can't find the underlying filesystem and the test case fails.
Is there any chance identify the FS by different/more reliable means.
BTW As I understand after discussion with colleagues, I believe that the /etc/mtab is kept around just for backward compatibility and there are several parties which would like to see this file dead entirely. It is currently just symlink anyway. So it might be just about time to stop using it.
[1] http://koschei.cloud.fedoraproject.org/package/ruby
[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d4d6574
[3] http://paste.fedoraproject.org/201571/42712927/
[4] http://paste.fedoraproject.org/201618/14271327/
[5] https://github.com/ruby/ruby/blob/trunk/ext/-test-/file/fs.c#L14
[6] https://kojipkgs.fedoraproject.org/work/tasks/3012/9303012/build.log
Updated by vo.x (Vit Ondruch) over 9 years ago
statfs(2) might be good candidate to replace the current mtab implementation.
Updated by nobu (Nobuyoshi Nakada) over 9 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Applied in changeset r50071.
fs.c: use statfs/statvfs
- ext/-test-/file/fs.c (get_fsname): return filesystem name by
statfs/statvfs. [ruby-core:68624] [Bug #10998]
Updated by vo.x (Vit Ondruch) over 9 years ago
- Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN to 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: REQUIRED
The fix is passing on Fedora builders [1]. Thank you.
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=9310557
Updated by ngoto (Naohisa Goto) over 9 years ago
- Related to Bug #11000: r50071以降、Solarisにてext/-test-/file/fs.cのコンパイルができない added
Updated by nagachika (Tomoyuki Chikanaga) about 9 years ago
- Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: REQUIRED to 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: DONE
Backported into ruby_2_2
branch at r50621.
Updated by usa (Usaku NAKAMURA) about 9 years ago
- Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: DONE to 2.0.0: DONTNEED, 2.1: DONTNEED, 2.2: DONE