pivot-root test fails on Ubuntu 16.04

  • Done
  • quality assurance status badge
Details
4 participants
  • Gábor Boskovits
  • Ludovic Courtès
  • Paul Garlick
  • zimoun
Owner
unassigned
Submitted by
Paul Garlick
Severity
normal

Debbugs page

Paul Garlick wrote 8 years ago
(address . bug-guix@gnu.org)
1484760171.3242.7.camel@tourbillion-technology.com
Hi,

I have noticed that the pivot-root test on my development system has
started to fail.  After running 'make check' the result: FAIL is
recorded for the syscalls.scm test.

I have recently updated the system.  It is running Ubuntu 16.04.
 Previously, the test passed.  Now:

$ uname -r
4.4.0-59-generic

Best,

Paul.
Attachment: file
Ludovic Courtès wrote 8 years ago
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)(address . 25476@debbugs.gnu.org)
87shofuihf.fsf@gnu.org
Hi!

Paul Garlick <pgarlick@tourbillion-technology.com> skribis:

Toggle quote (10 lines)
> I have noticed that the pivot-root test on my development system has
> started to fail.  After running 'make check' the result: FAIL is
> recorded for the syscalls.scm test.
>
> I have recently updated the system.  It is running Ubuntu 16.04.
>  Previously, the test passed.  Now:
>
> $ uname -r
> 4.4.0-59-generic

That’s on Git master, right?

Could you post tests/syscalls.log?

This test is known to be problematic with recent kernels, as written
above it:

Toggle snippet (7 lines)
;; XXX: Skip this test when running Linux > 4.7.5 to work around
;; <https://bugzilla.kernel.org/show_bug.cgi?id=183461>.
(when (or (not perform-container-tests?)
(version>? (utsname:release (uname)) "4.7.5"))
(test-skip 1))

AFAIK this particular problem was introduced around 4.7.5, as discussed
in the bug report above, but maybe Ubuntu’s 4.4 has it too?

Thanks for your report!

Ludo’.
Paul Garlick wrote 8 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 25476@debbugs.gnu.org)
1484954418.3990.19.camel@tourbillion-technology.com
Hi Ludo,
Toggle quote (1 lines)
> That’s on Git master, right?
Yes, back on the master branch the test still fails:
$ git describe
v0.11.0-3373-g2df3d14
Toggle quote (3 lines)
> Could you post tests/syscalls.log?
>

Attached.
Best,
Paul.
Attachment: file
Attachment: syscalls.log
Ludovic Courtès wrote 8 years ago
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)(address . 25476@debbugs.gnu.org)
877f5ckwm2.fsf@gnu.org
Paul Garlick <pgarlick@tourbillion-technology.com> skribis:

Toggle quote (37 lines)
> test-name: pivot-root
> location: /data/paul/sourceCode/guix/tests/syscalls.scm:154
> source:
> + (test-equal
> + "pivot-root"
> + #t
> + (match (pipe)
> + ((in . out)
> + (match (clone (logior CLONE_NEWUSER CLONE_NEWNS SIGCHLD))
> + (0
> + (dynamic-wind
> + (const #t)
> + (lambda ()
> + (close in)
> + (call-with-temporary-directory
> + (lambda (root)
> + (let ((put-old (string-append root "/real-root")))
> + (mount "none" root "tmpfs")
> + (mkdir put-old)
> + (call-with-output-file
> + (string-append root "/test")
> + (lambda (port) (display "testing\n" port)))
> + (pivot-root root put-old)
> + (write (file-exists? "/test") out)
> + (close out)))))
> + (lambda () (primitive-exit 0))))
> + (pid (close out)
> + (let ((result (read in)))
> + (close in)
> + (and (zero? (match (waitpid pid)
> + ((_ . status)
> + (status:exit-val status))))
> + (eq? #t result))))))))
> expected-value: #t
> actual-value: #f
> result: FAIL

Hmm, not sure why this is failing. Most likely (file-exists? "/test")
returns #f.

Could you change “(eq? #t result)” to “result”, rerun the test, and send
syscalls.log?

Thanks,
Ludo’.
Paul Garlick wrote 8 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 25476@debbugs.gnu.org)
1485881327.12269.10.camel@tourbillion-technology.com
Toggle quote (6 lines)
>
> Could you change “(eq? #t result)” to “result”, rerun the test, and
> send
> syscalls.log?
>
>
Hi Ludo,
After a 'git pull --rebase' I now have:
$ git describe
v0.12.0-984-gabb7eb7
The pivot-root test still fails.  The 'actual-value' is now #<eof>.  I
have attached the syscalls.log file.  
In fact there is also a new FAIL result, for utmpx-entries.  Is this
unrelated?
Best,
Paul.
Attachment: file
Attachment: syscalls.log
Ludovic Courtès wrote 8 years ago
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)(address . 25476@debbugs.gnu.org)
87wpdaawjb.fsf@gnu.org
Hi,

Paul Garlick <pgarlick@tourbillion-technology.com> skribis:

Toggle quote (37 lines)
> test-name: pivot-root
> location: /data/paul/sourceCode/guix/tests/syscalls.scm:154
> source:
> + (test-equal
> + "pivot-root"
> + #t
> + (match (pipe)
> + ((in . out)
> + (match (clone (logior CLONE_NEWUSER CLONE_NEWNS SIGCHLD))
> + (0
> + (dynamic-wind
> + (const #t)
> + (lambda ()
> + (close in)
> + (call-with-temporary-directory
> + (lambda (root)
> + (let ((put-old (string-append root "/real-root")))
> + (mount "none" root "tmpfs")
> + (mkdir put-old)
> + (call-with-output-file
> + (string-append root "/test")
> + (lambda (port) (display "testing\n" port)))
> + (pivot-root root put-old)
> + (write (file-exists? "/test") out)
> + (close out)))))
> + (lambda () (primitive-exit 0))))
> + (pid (close out)
> + (let ((result (read in)))
> + (close in)
> + (and (zero? (match (waitpid pid)
> + ((_ . status)
> + (status:exit-val status))))
> + result)))))))
> expected-value: #t
> actual-value: #<eof>
> result: FAIL

That would mean the child process exited with 0, yet it didn’t write
anything to stdout. Not sure how this can happen.

Toggle quote (15 lines)
> test-name: utmpx-entries
> location: /data/paul/sourceCode/guix/tests/syscalls.scm:444
> source:
> + (test-assert
> + "utmpx-entries"
> + (match (utmpx-entries)
> + (((? utmpx? entries) ...)
> + (every (lambda (entry)
> + (match (utmpx-user entry)
> + ((? string?) (> (utmpx-pid entry) 0))
> + (#f #t)))
> + entries))))
> actual-value: #f
> result: FAIL

This one is unrelated.

Could you try this:

Toggle snippet (17 lines)
$ ./pre-inst-env guile
GNU Guile 2.0.13
Copyright (C) 1995-2016 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use(guix build syscalls)
scheme@(guile-user)> (utmpx-entries)
$1 = (#<<utmpx-entry> type: 6 …> …)
scheme@(guile-user)> ,use(srfi srfi-1)
scheme@(guile-user)> (find (lambda (entry) (and (string? (utmpx-user entry))(zero? (utmpx-pid entry)))) (utmpx-entries))
$2 = #f

Most likely the assumption made in this test doesn’t hold on your system
for some reason.

Thank you,
Ludo’.
Paul Garlick wrote 8 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 25476@debbugs.gnu.org)
1485963231.29096.4.camel@tourbillion-technology.com
Hi Ludo,

Here is the output from the guile session:

paul$ ./pre-inst-env guile
GNU Guile 2.0.13
Copyright (C) 1995-2016 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,use(guix build syscalls)
scheme@(guile-user)> (utmpx-entries)
$1 = (#<<utmpx-entry> type: 2 pid: 0 line: "~" id: (126 126 0 0) user:
"reboot" host: "4.4.0-59-generic" termination: 0 exit: 0 session: 0
time: #<time type: time-utc nanosecond: 627310000 second: 1485945677>
address: (0 0 0 0)> #<<utmpx-entry> type: 1 pid: 53 line: "~" id: (126
126 0 0) user: "runlevel" host: "4.4.0-59-generic" termination: 0 exit:
0 session: 0 time: #<time type: time-utc nanosecond: 441012000 second:
1485945740> address: (0 0 0 0)> #<<utmpx-entry> type: 6 pid: 1589 line:
"tty1" id: (116 116 121 49) user: "LOGIN" host: #f termination: 0 exit:
0 session: 1589 time: #<time type: time-utc nanosecond: 643444000
second: 1485945740> address: (0 0 0 0)> #<<utmpx-entry> type: 7 pid:
1908 line: "tty7" id: (58 48 0 0) user: "paul" host: ":0" termination:
0 exit: 0 session: 0 time: #<time type: time-utc nanosecond: 705038000
second: 1485945754> address: (0 0 0 0)> #<<utmpx-entry> type: 7 pid:
2486 line: "pts/11" id: (47 49 49 0) user: "paul" host: ":0.0"
termination: 0 exit: 0 session: 0 time: #<time type: time-utc
nanosecond: 115640000 second: 1485945809> address: (0 0 0 0)> #<<utmpx-
entry> type: 7 pid: 2486 line: "pts/2" id: (47 50 0 0) user: "paul"
host: ":0.0" termination: 0 exit: 0 session: 0 time: #<time type: time-
utc nanosecond: 916844000 second: 1485947271> address: (0 0 0 0)>)
scheme@(guile-user)> ,use(srfi srfi-1)
scheme@(guile-user)> (find (lambda (entry) (and (string? (utmpx-user 
entry))(zero? (utmpx-pid entry)))) (utmpx-entries))
$2 = #<<utmpx-entry> type: 2 pid: 0 line: "~" id: (126 126 0 0) user:
"reboot" host: "4.4.0-59-generic" termination: 0 exit: 0 session: 0
time: #<time type: time-utc nanosecond: 627310000 second: 1485945677>
address: (0 0 0 0)>

The $2 ##SELECTION_END##output is not false in this case.

Paul.
Attachment: file
Ludovic Courtès wrote 8 years ago
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)(address . 25476@debbugs.gnu.org)
878tpc1knl.fsf@gnu.org
Paul Garlick <pgarlick@tourbillion-technology.com> skribis:

Toggle quote (7 lines)
> scheme@(guile-user)> (find (lambda (entry) (and (string? (utmpx-user
> entry))(zero? (utmpx-pid entry)))) (utmpx-entries))
> $2 = #<<utmpx-entry> type: 2 pid: 0 line: "~" id: (126 126 0 0) user: "reboot" host: "4.4.0-59-generic" termination: 0 exit: 0 session: 0 time: #<time type: time-utc nanosecond: 627310000 second:
> 1485945677> address: (0 0 0 0)>
>
> The $2 output is not false in this case.

I think a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 fixes this.

Thanks!

Ludo’.
Paul Garlick wrote 8 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 25476@debbugs.gnu.org)
1487024186.24925.5.camel@tourbillion-technology.com
Toggle quote (3 lines)
> I think a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 fixes this.
>
>
Yes, confirmed.  The utmpx-entries test now passes.
The pivot-root test still fails.  One thought; I made a change to the
guix-daemon.service file, at about the same time as updating Ubuntu to
16.04, setting TMPDIR to /data/tmp.  Could that be related?
Paul.
Attachment: file
Ludovic Courtès wrote 8 years ago
(name . Paul Garlick)(address . pgarlick@tourbillion-technology.com)(address . 25476@debbugs.gnu.org)
87bmu5racu.fsf@gnu.org
Hi Paul,

Paul Garlick <pgarlick@tourbillion-technology.com> skribis:

Toggle quote (5 lines)
>> I think a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 fixes this.
>>
>>
> Yes, confirmed.  The utmpx-entries test now passes.

Great, thanks for checking.

Toggle quote (4 lines)
> The pivot-root test still fails.  One thought; I made a change to the
> guix-daemon.service file, at about the same time as updating Ubuntu to
> 16.04, setting TMPDIR to /data/tmp.  Could that be related?

I don’t think so: ‘make check’ spawns its own daemon, which uses a store
at $builddir/test-tmp. And this particular test does not rely on the
daemon.

Ludo’.
Ludovic Courtès wrote 7 years ago
Re: Test fail
(name . Maria Sidorova)(address . hydromasha@gmail.com)(address . 25476@debbugs.gnu.org)(name . Gábor Boskovits)(address . boskovits@gmail.com)(name . help-guix)(address . help-guix@gnu.org)
87lge9ldpm.fsf@gnu.org
Hi Maria,

Thanks for your report. In practice you can safely ignore this test
failure. We had a similar report earlier that this fails on Ubuntu:

Something we should do, though, is to at least skip the test when we
know we’re using a faulty kernel. Currently we already have:

;; XXX: Skip this test when running Linux > 4.7.5 to work around
(when (or (not perform-container-tests?)
(version>? (utsname:release (uname)) "4.7.5"))
(test-skip 1))

Gábor, given what you wrote about Ubuntu’s 4.4 kernel, should we
explicitly flag “4.4.0-116-generic” in a similar way? Would it be
enough?

Thank you both!

Ludo’.
Gábor Boskovits wrote 7 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 25476@debbugs.gnu.org)(name . help-guix)(address . help-guix@gnu.org)(name . Maria Sidorova)(address . hydromasha@gmail.com)
CAE4v=pgZ_2LywG9WZnEB7ea1qOVi7ORBzr-9arGEi8=_f2KEhA@mail.gmail.com
Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2018. márc. 30., P 18:39):

Toggle quote (21 lines)
> Hi Maria,
>
> Thanks for your report. In practice you can safely ignore this test
> failure. We had a similar report earlier that this fails on Ubuntu:
> <https://bugs.gnu.org/25476>.
>
> Something we should do, though, is to at least skip the test when we
> know we’re using a faulty kernel. Currently we already have:
>
> ;; XXX: Skip this test when running Linux > 4.7.5 to work around
> ;; <https://bugzilla.kernel.org/show_bug.cgi?id=183461>.
> (when (or (not perform-container-tests?)
> (version>? (utsname:release (uname)) "4.7.5"))
> (test-skip 1))
>
> Gábor, given what you wrote about Ubuntu’s 4.4 kernel, should we
> explicitly flag “4.4.0-116-generic” in a similar way? Would it be
> enough?
>
>
>
Yes, it seems that would be enough.
We also have this "4.4.0-21-generic" for not x86.

Alternatively we can point Ubuntu users to the LTSEnablementStack.
This provides a 4.8 kernel since 16.04.2. (feb. 2017.)


Toggle quote (4 lines)
> Thank you both!
>
> Ludo’.
>
Attachment: file
Ludovic Courtès wrote 7 years ago
(name . Gábor Boskovits)(address . boskovits@gmail.com)(address . 25476@debbugs.gnu.org)(name . help-guix)(address . help-guix@gnu.org)(name . Maria Sidorova)(address . hydromasha@gmail.com)
87sh8a2fqt.fsf@gnu.org
Hello,

Gábor Boskovits <boskovits@gmail.com> skribis:

Toggle quote (26 lines)
> Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2018. márc. 30., P 18:39):
>
>> Hi Maria,
>>
>> Thanks for your report. In practice you can safely ignore this test
>> failure. We had a similar report earlier that this fails on Ubuntu:
>> <https://bugs.gnu.org/25476>.
>>
>> Something we should do, though, is to at least skip the test when we
>> know we’re using a faulty kernel. Currently we already have:
>>
>> ;; XXX: Skip this test when running Linux > 4.7.5 to work around
>> ;; <https://bugzilla.kernel.org/show_bug.cgi?id=183461>.
>> (when (or (not perform-container-tests?)
>> (version>? (utsname:release (uname)) "4.7.5"))
>> (test-skip 1))
>>
>> Gábor, given what you wrote about Ubuntu’s 4.4 kernel, should we
>> explicitly flag “4.4.0-116-generic” in a similar way? Would it be
>> enough?
>>
>>
>>
> Yes, it seems that would be enough.
> We also have this "4.4.0-21-generic" for not x86.

OK, done.

As time passes, this test can no longer run given the constraints
above. We should probably rethink it…

Toggle quote (3 lines)
> Alternatively we can point Ubuntu users to the LTSEnablementStack.
> This provides a 4.8 kernel since 16.04.2. (feb. 2017.)

Yeah, well, no big deal.

Thanks,
Ludo’.
zimoun wrote 5 years ago
Bug#25476 Hunting: pivot-root test fails on foreign distro
(address . 25476@debbugs.gnu.org)(name . Gábor Boskovits)(address . boskovits@gmail.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(address . pgarlick@tourbillion-technology.com)(address . hydromasha@gmail.com)
CAJ3okZ0Ds6BKFoZLWeE6dgL0BWvvp+jazAKr9Yxu=-x2CyUQ5w@mail.gmail.com
Dear,

This bug seems fixed by a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 as
explained here [1].

Any objection to close it?
Or new information blocking the closing?



Thank you in advance.

All the best,
simon
Ludovic Courtès wrote 5 years ago
(name . zimoun)(address . zimon.toutoune@gmail.com)(name . Gábor Boskovits)(address . boskovits@gmail.com)(address . 25476-done@debbugs.gnu.org)(address . pgarlick@tourbillion-technology.com)(address . hydromasha@gmail.com)
878sl973x8.fsf@gnu.org
Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (3 lines)
> This bug seems fixed by a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 as
> explained here [1].

Well this commit fixes one of the issues discussed here (the utmpx test
failure), but not the ‘pivot-root’ test failure itself.

However, it seems that the ‘pivot-root’ test is now skipped in practice
on most systems so…

Turns out I found how to make it work again in commit
1deca767be1b84b96633e317f3fcdd5165f95df3. Let me know if anything’s
amiss.

Finally closing! :-)

Ludo’.
Closed
zimoun wrote 5 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 25476-done@debbugs.gnu.org)
CAJ3okZ3UiFPa8a0LpnAfU0KA36rzOG1h1EWLkrJ6rgq512dLLg@mail.gmail.com
Hi Ludo,

On Tue, 11 Feb 2020 at 12:35, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (8 lines)
> zimoun <zimon.toutoune@gmail.com> skribis:
>
> > This bug seems fixed by a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 as
> > explained here [1].
>
> Well this commit fixes one of the issues discussed here (the utmpx test
> failure), but not the ‘pivot-root’ test failure itself.

D'oh!
I missed this part.


Toggle quote (3 lines)
> However, it seems that the ‘pivot-root’ test is now skipped in practice
> on most systems so…

Ok so let if the bug show up again. :-)


Toggle quote (4 lines)
> Turns out I found how to make it work again in commit
> 1deca767be1b84b96633e317f3fcdd5165f95df3. Let me know if anything’s
> amiss.

Cool!

Thank you for the fix.


Cheers,
simon
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 25476@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 25476
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help