Summary: | sys-fs/e2fsprogs: util/subst randomly fails during install with: e2fsck.conf.5.new: Permission denied | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | LABBE Corentin <clabbe.montjoie> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
URL: | http://thread.gmane.org/gmane.comp.standards.posix.austin.general/11413 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log for sys-fs/e2fsprogs emerge |
Description
LABBE Corentin
2015-06-02 08:25:35 UTC
is this really an arm system or are you using qemu ? please look at the file system permissions on the dir: /var/tmp/portage/portage/sys-fs/e2fsprogs-1.42.12/work/e2fsprogs-1.42.12/e2fsck and make sure there isn't a e2fsck.conf.5.new file in there. It is a real arm device. ls -l /var/tmp/portage/portage/sys-fs/e2fsprogs-1.42.12/work/e2fsprogs-1.42.12/e2fsck/e2fsck.conf.5.new -r--r--r-- 1 portage portage 0 mai 27 14:28 /var/tmp/portage/portage/sys-fs/e2fsprogs-1.42.12/work/e2fsprogs-1.42.12/e2fsck/e2fsck.conf.5.new I have a similar bug emerging e2fsprogs-1.42.13 on a qemu virtual system. Here's a bit of the error message, it changes at each try. e2freefrag.8.new: Permission denied Makefile:733: recipe for target 'e2freefrag.8' failed make[2]: *** [e2freefrag.8] Error 1 I'm using ccache and the portage dirs (portage tree, tmp portage) are on an nfs share. Hope this helps. LABBE: are you also using nfs ? the subst tool does: fd = open(newfn, O_CREAT|O_TRUNC|O_RDWR, 0444); the .new file should not already exist (it's not in the tarball nor created) which means it should create it for the first time. if the file already existed, then you would get a permission denied error, but that shouldn't happen. perhaps NFS is screwing things up and there's a race/desync between the client & server as to the state of the file. i imagine if we changed the 0444 to 0644, it'd make things work, but i think the NFS behavior is still wrong (not POSIX compliant). if you don't use NFS in the temp dir, does it build ? (In reply to SpanKY from comment #4) > LABBE: are you also using nfs ? > > the subst tool does: > fd = open(newfn, O_CREAT|O_TRUNC|O_RDWR, 0444); > > the .new file should not already exist (it's not in the tarball nor created) > which means it should create it for the first time. if the file already > existed, then you would get a permission denied error, but that shouldn't > happen. > > perhaps NFS is screwing things up and there's a race/desync between the > client & server as to the state of the file. i imagine if we changed the > 0444 to 0644, it'd make things work, but i think the NFS behavior is still > wrong (not POSIX compliant). > > if you don't use NFS in the temp dir, does it build ? Indeed, not using the NFS tmp dir for portage makes it build. should be fixed by: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff98e2caac4f8e53b51b602de9d9be06782622e6 please try it out w/NFS I confirm that it builds now with NFS. Thanks for the patch. |