[gentoo-user] Start conflict "elogind" vs "fwupd"
Greetings, since my last routine Gentoo upgrade on 2021-02-01 "fwupd" is no longer started in the "default" run level. Reason is that "fwupd" erroneously thinks its prerequisite "elogind" is not yet running, starts it again, interprets the error message "already started" and the non-zero exit code as "not startable", and gives in. In order to allow "fwupd" to start" I had to -- temporarily -- remove the "elogind" prerequisite in file "/etc/init.d/fwupd". Did anybody else observe this behaviour? Is this a known problem? Sincerely, Rainer
Re: [gentoo-user] Failing to emerge "sys-apps/fwupd-1.8.1"
On Thu, 2 Jun 2022 at 17:33, Dr Rainer Woitok wrote: > Greetings, > > my last successful build of "sys-apps/fwupd" was 1.7.7-r2. Immediately > before my vacation 1.8.0 failed on 2022-05-10, and today 1.8.1 failed, > too. > > Since the build log says at its end > > * If you need support, post the output of `emerge --info > '=sys-apps/fwupd-1.8.1::gentoo'`, > * the complete build log and the output of `emerge -pqv > '=sys-apps/fwupd-1.8.1::gentoo'`. > > and since I am currently absolutely clueless, I'm including the output > from these two commands as well as the complete build log (except for > ANSI control characters) as requested above. Hopefully, somebody has an > idea what's going wrong here. > According to https://bugs.gentoo.org/841767 this could possibly be fixed for you by either activating the gusb USE flag, or de-activating the modemmanager USE flag. Regards, Arve
[SOLVED] Re: [gentoo-user] Failing to emerge "sys-apps/fwupd-1.8.1"
Arve, On Thursday, 2022-06-02 17:46:14 +0200, you wrote: > ... > According to https://bugs.gentoo.org/841767 this could possibly be fixed > for you by either activating the gusb USE flag, or de-activating the > modemmanager USE flag. Bingo! Activating the "gusb" USE flag did the trick! Many thanks :-D Sincerely, Rainer
[gentoo-user] Re: Problem understanding "eix"
Dr Rainer Woitok wrote:
>
> Yes. To satisfy the requirements of package "sys-apps/fwupd" I long ago
> added the line
>
>>=app-crypt/tpm2-tss-2.2.3-r1 ~amd64
Ah! That explains it.
> But this only means that I accept an unstable package here, not that
> these versions are regarded stable.
It is stabe according to the local configuration on your system.
What you look for is perhaps {wasstable} which returns the value
according to the default configuration.
[gentoo-user] Re: Problem understanding "eix"
Martin,
On Friday, 2020-04-24 17:32:09 -, you wrote:
> ...
> Maybe you run an unstable system, that is ACCEPT_KEYWORDS='~amd64'?
No.
> Or do you have a corresponding entry in package.{accept_,}keywords?
Yes. To satisfy the requirements of package "sys-apps/fwupd" I long ago
added the line
>=app-crypt/tpm2-tss-2.2.3-r1 ~amd64
But this only means that I accept an unstable package here, not that
these versions are regarded stable. After all, the property is named
"{isstable}" and not "{isaccepted}".
Sincerely,
Rainer
[gentoo-user] problem with open-rc - daemon is running but rc-service says stopped
"rc-service elogind status" says it is stopped, but "ps auxf | grep elogind" shows elogind-daemon is running. /run/elogind.pid has the correct pid for the daemon. Based on we searches for similar issues, I discovered that that /run/openrc/started/elogind did not exist. "ln -s /etc/init.d/elogind /run/openrc/started/" made rc-service recognize that the process was actually started. I can't find anything in /var/log or dmesg about elogind starting. It is not specified in any runlevel, so I assume it is being started automatically as needed by something else, although the only other file in /etc/init.d that needs it is fwupd, which is not currently running (and not automatically started). I suppose if I put elogind in the default runlevel, then open-rc will hopefully start it before it would otherwise get launched, but I'm curious how I could track down what is currently causing it to be started. Jack
