| Summary: | Gracefully bailout if repo directory is not writable/immutable | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Joshua Kinard <kumba> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Traceback from emerge --sync when repo dir is immutable | ||
Created attachment 717252 [details] Traceback from emerge --sync when repo dir is immutable For my setup, I host the main Gentoo repo on a FreeBSD-based NAS server that my Gentoo systems all mount over NFSv4. My fast amd64 dev box handles syncing the tree when needed, while the slower systems just read from the mount point where the repo is mounted (/usr/portage). On my amd64 machine, the repo is not always mounted, so if I accidentally run "emerge --sync" when it is unmounted, it'll attempt to populate a new repo locally. I fixed this by setting the mountpoint to be immutable, but emerge does not handle this terribly well, throwing out a traceback. The core error is actually caused by rsync trying to create a hidden file at the mountpoint: rsync: [Receiver] mkdir "/usr/portage/.tmp-unverified-download-quarantine" failed: Operation not permitted (1) rsync error: error in file IO (code 11) at main.c(784) [Receiver=3.2.3] emerge then bails out with a traceback at this point: File "/usr/lib/python3.9/site-packages/portage/util/_async/AsyncFunction.py", line 39, in _run result = self.target(*(self.args or []), **(self.kwargs or {})) Followed by a longer traceback list, which is attached to this bug. emerge should instead catch the failure from rsync and fail in a more graceful manner, perhaps by showing a friendly error message and possibly even testing for writeability or immutability and displaying an error message tailored for that case.