Created attachment 556646 [details]
While doing 'emerge -u system' as one the last steps of Stage 3 of the boostrap of Gentoo Prefix (EPREFIX being /tmp/gentoo) emerging sys-apps/which-2.21 fails with:
ERROR:root:Failed to copy file: _parsed_options=Namespace(group=-1, mode=420, owner=-1, preserve_timestamps=False), source=b'README', dest_dir=b'/tmp/gentoo/var/tmp/portage/sys-apps/which-2.21/image/tmp/gentoo/usr/share/doc/which-2.21'
Traceback (most recent call last):
File "/tmp/gentoo/usr/lib/portage/python3.6/doins.py", line 209, in run
File "/tmp/gentoo/usr/lib64/python3.6/site-packages/portage/util/file_copy/__init__.py", line 30, in _optimized_copyfile
PermissionError: [Errno 1] Operation not permitted
* ERROR: sys-apps/which-2.21::gentoo failed (install phase):
* dodoc failed
I've checked that /tmp/gentoo/var/tmp/portage/sys-apps/which-2.21/image/tmp/gentoo/usr/share/doc/which-2.21 exists and has correct permissions:
ls -lah /tmp/gentoo/var/tmp/portage/sys-apps/which-2.21/image/tmp/gentoo/usr/share/doc/which-2.21
drwxr-xr-x 2 user user 4.0K Nov 28 21:58 .
drwxr-xr-x 3 user user 4.0K Nov 28 21:58 ..
-rw-r--r-- 1 user user 0 Nov 28 21:58 AUTHORS
-rw-r--r-- 1 user user 0 Nov 28 21:58 NEWS
-rw-r--r-- 1 user user 0 Nov 28 21:58 README
-rw-r--r-- 1 user user 0 Nov 28 21:58 README.alias
I tried to write in the folder and I could write.
Created attachment 556648 [details]
emerge info command
Created attachment 556650 [details]
emerge pqv command
Doing a workaround to skip the emerging of this package got me in the same exact error in the next one.
I was advised to check:
To check if I had available inodes... But I didn't have a machine in the state to try. I've managed to get thru this problem in one machine, so maybe it was that specific machine that had the problem.
I'm bootstrapping in a couple of other machines. I'll update with the result.
This really is a prefix bug, unrelated to the package.
I'm back in this bug. Or very similar.
I succesfully managed to bootstrap a Gentoo Prefix on amd64 and another one on x86.
Currently I'm trying to build upon them. The amd64 is doing fine. But the x86 is stuck with this error.
While trying to emerge dev-vcs/git I get on dev-perl/TimeDate-2.300.0
# ERROR:root:Failed to copy file: _parsed_options=Namespace(group=-1, mode=420, owner=-1, preserve_timestamps=False), source='ChangeLog', dest_dir='/home/user/gentoo/var/tmp/portage/dev-perl/TimeDate-2.300.0/image/tmp/gentoo/usr/share/doc/TimeDate-2.300.0'
# Traceback (most recent call last):
# File "/tmp/gentoo/usr/lib/portage/python2.7/doins.py", line 209, in run
# copyfile(source, dest)
# File "/home/user/gentoo/usr/lib/python2.7/site-packages/portage/util/file_copy/__init__.py", line 30, in _optimized_copyfile
# _file_copy(src_file.fileno(), dst_file.fileno())
# OSError: [Errno 1] Operation not permitted
If I try to workaround it (using $EPREFIX/etc/portage/profile/package.provided) I end up in the same error with the packages:
And from there I cannot continue as the next package ( dev-perl/Error-0.170.250 ) needs dev-perl/Module-Build and I have no workaround on that.
Any ideas? It works correctly on amd64...
You can find yourself in a Docker environment in just that state by doing (currently being uploaded):
docker pull awesomebytes/debug_dodoc
docker run -it awesomebytes/debug_dodoc /bin/bash
[Here you are in the prefixed environment (in /tmp/gentoo) and you can do anything you want]
Or, if you don't have Docker, you can download the .tar.gz with the bootstrapped system from the latest release:
Just do: tar xvf gentoo_on_tmp*.tar.gz; ./gentoo/startprefix
Aaaand... the problem is gone. I made it work in a different machine (still running it thru the same docker tho).
Then when I tried to build again in the machine that was giving me problems... the problem hasn't happened again.
I really have no clue of what is going on. Maybe the hard disk has problems? The kernel is messing with me?
This is a very strange problem which we also experience sporadically, but with other packages than which. Lately, we have had doins failed on shadow and portage itself.
We have patched portage to make it able to avoid aborting with the mentioned error on various packages. More info here:
I believe this is a rare portage bug.