Summary: | sys-apps/portage-2.2.18: read-only package directory blocks installation of packages from package directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Klaftenegger <davidweb> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | np-hardass |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=549324 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 484436 |
Description
David Klaftenegger
2015-05-10 14:49:52 UTC
Worth noting, on my system where I --getbinpkg, it puts a copy of every binpkg there. I have a nagging suspicion that portage attempts to place a copy of the binpkg in PKGDIR, and then dies (since it is read-only). To test this idea, I ro mounted my PKGDIR, and attempted to --getbinpkg, and it also failed. So, I'd suspect that this is the source of the issue. That's my theory, at least. In my particular setup this is a kerberized NFS share only available readonly. This setup avoids putting a copy of the packages on every virtual machine without having to deal with security issues on the binpkgs and still only compiling each package once on a VM with write access to the directory but only ssh running. If you need more information or I can help by testing specific things please tell me, as this bug currently prevents me from updating my machines. Currently, it will allow PKGDIR to be readonly if you use the --usepkgonly/-K option: https://gitweb.gentoo.org/proj/portage.git/commit/?id=0b453300f4da44a8a32e05f6d75da18847806739 Looking at the code, it looks like it might be a user config error. in emerge.actions.action_build(): if need_write_bindb and \ ("buildpkg" in trees[eroot]["root_config"]. settings.features or "buildsyspkg" in trees[eroot]["root_config"]. settings.features) and \ not trees[eroot]["bintree"].dbapi.writable: writemsg_level("!!! %s\n" % _("Read-only file system: %s") % trees[eroot]["bintree"].pkgdir, level=logging.ERROR, noiselevel=-1) return 1 So, Do you have either of those features set in the consumer VM's? Your Read only file system error message implies it is coming from that function and the above code. Looking at the bintree.py code, it only checks for permissions when it has to write the index or inject a pkg into it (thereby needing to write the index) I'll try to set my system up to do some testing. But if you could ensure those features are not set and that it still fails. That would be great. Removing buildpkg from FEATURES does solve the issue, and if I am told that my setup is a clear misconfiguration I will consider changing it. The reason FEATUES=buildpkg is set is that this way I can keep make.conf in sync between the producer and consumer VMs. As I do not intend to normally "build" on the consumer VMs I would expect the FEATURE to have no effect. I would in fact appreciate the "read only filesystem" error, if I was trying to install a non-binary package! For now, I can also work with running "emerge -pvk" to check whether all packages are available in binary form, and then proceeding with "emerge -K" to finalize it, instead of "emerge -avk" that I was using previously. (I also tested this, it works.) Thanks Zac for pointing to that one. just some more options for you: [18:00] <dol-sen> isn't make.conf still a stacked value? [18:01] <dol-sen> he could have a /etc/make.conf for general use, add one in /etc/portage adding buildpkg for the build vm [18:02] <zmedico> yeah, incrementals like FEATURES are stacked automatically [18:02] <dol-sen> I know others were using that technique for multi-instance use [18:02] <zmedico> make.conf can be a directory nowadays [18:02] <dol-sen> it sounds like he might be sharing /etc/portage via nfs as well [18:04] <dol-sen> so if he symlinked /etc/make.conf to /etc/make.conf/consumer.conf on the build system [18:05] <dol-sen> and added pkgbuilder.conf in /etc/portage/make.conf/ [18:05] <dol-sen> then they still share the consumer.conf and only add anything special for the build vm [18:07] <zmedico> sure This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=ddf341ef86c0939026818a231f79086f0ae2ecfe Released in portage-2.2.19 |