At latest tinderbox image setup I run into an issue like the following : # ls -ld /var/cache/eix drwxr-xr-x 1 root root 0 Jan 9 19:11 /var/cache/eix # eix-update Reading Portage settings... Building database (/var/cache/eix/portage.eix)... [0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat) Reading category 164|164 (100) Finished [1] "local" /usr/local/portage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 164|164 (100) Finished Applying masks... Calculating hash tables... Writing database file /var/cache/eix/portage.eix... cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb') solved by : chown portage:portage /var/cache/eix
The ownership is defined in /usr/lib/tmpfiles.d/eix.conf Thus, the ownership will correct whenever this file is processed. This should happen at boot (at least), but it also happens in pkg_postinst if you are not prefix. I suppose one of these conditions is not satisfied on the tinderbox.
(In reply to Martin Väth from comment #1) >This should happen at boot And this is not the case for my chroot images But I do wonder why I didn't run into this earlier ?
> And this is not the case for my chroot images In this case, I do not understand why you have /var/cache/eix with wrong permissions: After installation of eix, it should have been generated with correct permissions (due to pkg_postinst) unless you have USE=prefix on your tinderbox. If you remove /var/cache regularly, you should not have /var/cache/eix at all. If you don't remove /var/cache, I cannot understand why its permissions change. Only explanation which I have is that you have USE=prefix (in which case I would say the behaviour is correct to require you manually changing of permissions) or that the function tmpfiles_process eix.conf (from tmpfiles.eclass) does for some reason not work for you as it should.
(In reply to Martin Väth from comment #3) I do not use USE=prefix. This issue happens with every new tinderbox setup now - I circumvent with chown portage:portage /var/cache/eix for now during setup of a new image.
can be repeated at every system by: t44 ~ # mv /var/cache/eix /tmp/ t44 ~ # eix-update Reading Portage settings... Building database (/var/cache/eix/portage.eix)... [0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat) Reading category 164|164 (100) Finished [1] "local" /usr/local/portage (cache: parse|ebuild*#metadata-md5#metadata-flat#assign) Reading category 164|164 (100) Finished Applying masks... Calculating hash tables... Writing database file /var/cache/eix/portage.eix... cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb')
(In reply to Toralf Förster from comment #5) > can be repeated at every system by > # mv /var/cache/eix /tmp/ This is not related: eix-update simply tries to write to the file /var/cache/eix/portage.eix which is not possible since the corresponding folder was just removed.
I'm in a chroot trying to get Gentoo installed on a workstation, and came across this same issue: (workstation chroot) sysresccd / # eix-update Reading Portage settings... Building database (/var/cache/eix/portage.eix)... [0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat) Reading category 164|164 (100) Finished Applying masks... Calculating hash tables... Writing database file /var/cache/eix/portage.eix... cannot open database file /var/cache/eix/portage.eix for writing (mode = 'wb') (workstation chroot) sysresccd / # ls -ld /var/cache/eix drwxr-xr-x 2 root root 37 Jan 23 17:49 /var/cache/eix (workstation chroot) sysresccd / # cat /usr/lib/tmpfiles.d/eix.conf d /var/cache/eix 0775 portage portage - (workstation chroot) sysresccd / # emerge --info | grep ^USE | grep prefix | cut -d\" -f2 (workstation chroot) sysresccd / # emerge -pv sys-apps/openrc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/openrc-0.34.11::gentoo USE="ncurses netifrc pam unicode -audit -debug -newnet (-prefix) (-selinux) -static-libs" 223 KiB Total: 1 package (1 reinstall), Size of downloads: 223 KiB * IMPORTANT: 9 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. (workstation chroot) sysresccd / #
I don't consider it an eix bug: It is a bug by whatever /var/cache/eix Since quite some versions, eix does neither create /var/cache/eix nor change its permissions (exactly to avoid permission problems like these). So the user is responsible to create this folder and set its permissions appropriately, but you are not left alone with this: If you install eix from the ebuild, it will create this folder once and set its permissions (unless you are on prefix where this might be dangerous). If you are on a system where /var/cache is cleaned on booting and you use an init-system with tmpfiles.d support (e.g. systemd or openrc) then this init-system will use tmpfiles.d/eix.conf to generate the folder and set its permissions.
"It is a bug by whatever /var/cache/eix" should have read "It is a bug by whatever created /var/cache/eix" (the point being that eix does not do this anymore since many versions).
I would just like to note, only the portage group is required. The user may remain root.
Well, so it is related to chroot images, but I do not see any differences in USE=prefix or so compared to my host.
prefix might be completely on user-level, that is, $EPREFIX/var/cache/eix probably has the user's permissions, and eix should be configured to not attempt to change permissions (probably it even cannot). Perhaps the latter should be set by default in the ebuild with USE=prefix. I think that I will update eix to make the latter configurable by the build system.
Although not directly related to this bug: The current eix master branch (>=eix-0.33.3) now contains ./configure and meson switches to set the default EIX_{USER,GROUP,UID,GID}. The beta and live ebuilds in the mv overlay have been updated to set them in the "use prefix" case to the empty value or -1, respectively. (The main ebuild in the mv overlay will be updated only on the next release, of course.)
Created attachment 526164 [details, diff] eix-0.33.2.ebuild.patch The following patch unbreaks eix install for me.
I was surprised that this fixes it. Upon investigating, I now found the real cause: tmpfiles --create from opentmpfiles does not update permissions if the directory already exists. This is in contrast to systemd-tmpfiles which does. Since the tmpfiles.eclass uses systemd-tmpfiles when both implementations are available, in order to produce the bug the following consditions must be met: 1. systemd must not be installed. 2. /var/cache/eix exists already. In this case emerging eix does not fix the permissions. The issue could be solved by the suggested patch, but I would consider it cleaner to change the behaviour of opentmpfiles which IMHO is a bug. I opened a corresponding PR https://github.com/OpenRC/opentmpfiles/pull/6
Depending on the implementation of the tinderbox, it might be that fixing the ebuild alone would not even fix the issue: If /var/cache/eix exists on some image with wrong permissions which is regularly restored, these permission do have to be fixed when starting up the tinderbox (i.e. by tmpfiles --create or otherwise by a manual fix in the startup scripts).
(In reply to Sergei Trofimovich from comment #14) yep, doing this manually here at my tinderbox now since few weeks (since the issue started to happen) . if I need eix within an image
Still happens with 0.33.4 :(
A customer ran into this today. While I agree that this ultimately needs to be fixed upstream, the related pull request has been left unmerged for months, and who knows when it will be processed. I have therefore created a Gentoo PR as a workaround.
Still seen today with an installation that started from a fresh stage3.
williamh was asked to release newer opentmpfiles version, and so did he. Newer release fixes behaviour with Martin's path included.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=676d615922f4849695f426de68ce6a6f9b985828
