Summary: | sys-kernel/genkernel-next-70 and/or dev-util/ccache-3.7.7-r1 and/or sys-kernel/gentoo-sources-5.5.8 is replacing /dev/null with a file | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dan Goodliffe <gentoo> |
Component: | Current packages | Assignee: | Ettore Di Giacinto (RETIRED) <mudler> |
Status: | RESOLVED OBSOLETE | ||
Severity: | major | CC: | genkernel, jstein, kernel |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
genkernel configuration
"ccache -p" as root Kernel .config strace when run as root strace when run as user |
Description
Dan Goodliffe
2020-03-10 19:45:24 UTC
Created attachment 617946 [details]
genkernel configuration
Created attachment 617948 [details]
"ccache -p" as root
Created attachment 617950 [details]
Kernel .config
No, it's this... just haven't figured out yet what process that is. 151070 rename("/dev/null", "/dev/null.rm.akira.151070.XXXXXX") = 0 151070 unlink("/dev/null.rm.akira.151070.XXXXXX") = 0 Ah, basically the same. 151070 execve("/usr/lib/ccache/bin/cc", ["/usr/lib/ccache/bin/cc", "-Werror", "-Wmaybe-uninitialized", "-S", "-x", "c", "/dev/null", "-o", "/dev/null"], 0x561819dbd000 /* 142 vars */) = 0 Runing as user command $ strace -y -f /usr/lib/ccache/bin/cc -Werror -Wmaybe-uninitialized -S -x c /dev/null -o /dev/null |& fgrep dev/null |& fgrep -i unli I don't see an attempt to delete /dev/null. Do you observe that command to delete a file for you? If it does please attach full strace output. Created attachment 619256 [details]
strace when run as root
See line 450, rename of /dev/null.
Created attachment 619258 [details]
strace when run as user
It's different by paths and addresses, but vimdiff can match enough to make sense. The rename at 450 is never attempted.
Yeah, it's a ccache's deficiency. genkernel-next should not run builds as root either though. I guess genkernel itself is also able to trigger that because we don't use sandbox when building kernel. Looks like it's specific to 'hard_link = true' option. Filed https://github.com/ccache/ccache/issues/564 for ccache upstream. But even if it gets fixed I would expect more problems like that if you run builds as root. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=650d7b15773aea3eda20f2b870ad3266ddeefa6d commit 650d7b15773aea3eda20f2b870ad3266ddeefa6d Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-03-24 22:27:06 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-03-24 22:29:55 +0000 dev-util/ccache: backport workaround for /dev/null clobber In bug #712080 'hard_link = true' mode of ccache unlinked /dev/null as ccache was running as root. This workaround allows /dev/null to survive. Other special files still stay affected. Bug: https://bugs.gentoo.org/712080 Package-Manager: Portage-2.3.95, Repoman-2.3.21 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> dev-util/ccache/ccache-3.7.8-r1.ebuild | 71 +++++++++++++++++++++++ dev-util/ccache/files/ccache-3.7.8-dev-null.patch | 57 ++++++++++++++++++ 2 files changed, 128 insertions(+) Removing toolchain@ from CC. Fell free to readd for further ccache-related questions. Package removed. |