Summary: | sys-apps/portage: OSError: [Errno 22] Invalid argument in _optimized_copyfile (ZFS) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Adrien Dessemond <admnd> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anton.gubarkov, info, leonchik1976, sam, sokann |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://github.com/gentoo/portage/pull/647#issuecomment-739712109 https://github.com/openzfs/zfs/issues/11151 https://github.com/openzfs/zfs/issues/12971 https://bugs.gentoo.org/show_bug.cgi?id=760929 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 635020 |
Description
Adrien Dessemond
2020-12-24 15:48:49 UTC
See https://github.com/gentoo/portage/pull/647. I thought we had a bug for this, but it's a ZFS issue. See: https://github.com/gentoo/portage/pull/647#issuecomment-739712109 and: https://github.com/openzfs/zfs/issues/11151 *** Bug 762709 has been marked as a duplicate of this bug. *** I confirm I got the same issue but this isn't related to Linux 5.10 this time. I'm installing a new server, so I pulled a fresh stage3 (stage3-amd64-musl-hardened-20210704T170548Z.tar.xz) on a ZFS volume. After chroot I can install some packeges (vim & gnu-screen worked) but others don't (eix or python) failing with the exact same error reported here. The workaround helped and I successfully emerged eix after commenting the try/catch. I'm using OVH's temporary 'rescue' environment, 'uname -r' gives 4.19.84-mod-std-ipv6-64-rescue Git the issue again this time with ZFS 2.1.2 and a Linux 5.16.0. Same fix: patch /site-packages/portage/util/file_copy/__init__.py to comment the try/except block at the beginning to leave only _file_copy = None (In reply to Adrien Dessemond from comment #5) > Git the issue again this time with ZFS 2.1.2 and a Linux 5.16.0. Same fix: > patch /site-packages/portage/util/file_copy/__init__.py to comment the > try/except block at the beginning to leave only _file_copy = None This is a workaround again, right? Not a fix. Could you poke with strace to see what dies? We'll likely need to report this upstream again. 5.16 support is not declared yet, you are brave =) you can just build portage with USE=-native-extensions to exclude that codepath, without editing the ebuild. but would be nice to see what's going on ofc. Possibly https://github.com/openzfs/zfs/issues/12971 but I can't stress this enough: 1. If you're hitting a bug like this, you need to report it upstream to ZFS and link it back here. They're very nice! 2. Don't run kernels not yet declared as supported. (In reply to Sam James from comment #8) > Possibly https://github.com/openzfs/zfs/issues/12971 but I can't stress this > enough: > 1. If you're hitting a bug like this, you need to report it upstream to ZFS > and link it back here. They're very nice! > 2. Don't run kernels not yet declared as supported. Closing per this. |