Summary: | =sys-apps/systemd-205 - ACCESS DENIED: unlinkat: /usr/src/linux-3.10.0-gentoo/.5819.tmp | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Franz Trischberger <franz.trischberger> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Miscellaneous <kernel-misc> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | franz.trischberger, kirelagin, systemd |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | environment.bz2 |
Description
Franz Trischberger
2013-07-06 06:41:49 UTC
Are you able to provide a full logfile? Also, a dump of the ebuild environment would be helpful. With portage, the would be located in ${PORTAGE_TMPDIR}/portage/sys-apps/systemd-205/temp/environment. Created attachment 352740 [details]
environment.bz2
I hope that what you want (using paludis, so your hint did not help ;))
I do not have any form of log, that output is all. As I said regular build works just fine. It is just some sort of checks it fails. I think this is an error in paludis, though this was the first time I saw this. Previous systemd-versions (installed using the same paludis version) just worked fine.
Unfortunately, I don't see a way to tell what the ebuild is doing at that point unless we can get some more detailed output. Does paludis have a "debug" mode, similar to emerge --debug? --debug (-d) Tells emerge to run the emerge command in --debug mode. In this mode the bash build environment will run with the -x option, causing it to output verbose debugging information to stdout. This also enables a plethora of other output (mostly dependency resolution messages). Alternatively, you could try adding some echo statements to various places in linux-info.eclass to try and narrow it down. 5819 / 5824 sounds like a PID to me; under the assumption that this is a PID, can we try to figure out which process this is? Might be interesting to run this through `strace -f paludis ...`. Failing that, you could grep for .tmp in our eclasses and Paludis to see if it comes from there. (De-CC-ed myself to avoid duplicate mails, I'm listening on kernel-misc@g.o) I created the trace as requested (strace -f cave resolve --dump systemd). But compressed with with xz --extreme it still has 1.34 MB. How should I proceed? (In reply to Franz Fellner from comment #5) > How should I proceed? You could upload the file somewhere an link it. Or find some other way to get us information on what is actually happening here. Finally decided to create a dropbox account ;) Here you are: https://www.dropbox.com/s/dzb1wpbg9kqlz64/cave_resolve_systemd.strace.xz I did not manage to get the actual portage error messages into the file, but searching for "/usr/src/linux" should be enough (IMHO). [pid 5531] execve("/bin/rm", ["rm", "-f", ".5529.tmp", ".5529.o"], [/* 302 vars */]) = 0 [pid 5531] getcwd("/usr/src/linux-3.10.0-gentoo", 4096) = 29 [pid 5531] lstat("/usr/src/linux-3.10.0-gentoo/.5529.tmp", 0x7fff60073630) = -1 ENOENT (No such fil e or directory) So something is running "/bin/rm -f .5529.tmp .5529.o" from /usr/src/linux-3.10.0-gentoo. I believe it is probably this target in linux/scripts/Kbuild.include: # try-run # Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise) # Exit code chooses option. "$$TMP" is can be used as temporary file and # is automatically cleaned up. try-run = $(shell set -e; \ TMP="$(TMPOUT).$$$$.tmp"; \ TMPO="$(TMPOUT).$$$$.o"; \ if ($(1)) >/dev/null 2>&1; \ then echo "$(2)"; \ else echo "$(3)"; \ fi; \ rm -f "$$TMP" "$$TMPO") And this is probably being triggered by the getfilevar function in linux-info.eclass. Maybe we should export TMPOUT="${T}" in getfilevar? Or maybe add that to BUILDFIXES for all arches? This is linux-info.eclass' fault, correct? (In reply to Michał Górny from comment #10) > This is linux-info.eclass' fault, correct? I believe so. Reassigning. Hello? I'm migrating to paludis right now, and yeah, there is a bunch of access violations… *** This bug has been marked as a duplicate of bug 469210 *** (In reply to Kirill Elagin from comment #12) > Hello? > > I'm migrating to paludis right now, and yeah, there is a bunch of access > violations… Kirill, until this gets fixed you can use this overlay: https://github.com/holliday/holliday |