Hi! Since I upgraded xinit to the 1.3.4-r2 version, it can't run the xdm daemon because some functions cannot be found (such as get_options). However, I found a workaround to get rid of that. Just below the line ". /lib/gentoo/functions.sh", add this line: PATH=$PATH:/lib/rc/bin because all binaries found on that directory are not symlinks to the openrc binary, but binaries themselves. Now it works. I hope it may help anyone. Reproducible: Always
My workaround was to add ROOTPATH=$ROOTPATH:/lib64/rc/bin to /etc/env.d/99local and execute env-update.
Or simply source /lib/rc/sh/functions.sh instead of /lib/gentoo/functions.sh inside the startDM.sh script.
Confirming, it's horrible being unable to login after update.
Same here. I tried to downgrade to x11-apps/xinit-1.3.4-r1 but it was removed. I was lucky to have binary package of x11-apps/xinit-1.3.4-r1 and I used it to get KDE working again. For such critical packages, is it better to leave the previous packages for sometime?
same here. another workaround is to use the full path /lib64/rc/bin/get_options please test your changes before you commit them, at least for stable ebuilds
Want to confirm it as well. Downgrading to x11-apps/xinit-1.3.4-r1 solves issue for me. Some generic info just to fit the rules: Portage 2.3.11 (python 3.4.6-final-0, default/linux/amd64/13.0/desktop/plasma, gcc-7.2.0, glibc-2.25-r7, 4.13.8-gentoo x86_64) ================================================================= System uname: Linux-4.13.8-gentoo-x86_64-Intel-R-_Core-TM-_i5-2500K_CPU_@_3.30GHz-with-gentoo-2.4.1 KiB Mem: 16352632 total, 256972 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Thu, 19 Oct 2017 10:30:01 +0000 Head commit of repository gentoo: a6ef526c60b1f809f9d008e5ecdba9cb28b795c1 sh bash 4.4_p12 ld GNU ld (Gentoo 2.29.1 p2) 2.29.1 app-shells/bash: 4.4_p12::gentoo dev-lang/perl: 5.26.1::gentoo dev-lang/python: 2.7.14::gentoo, 3.4.6::gentoo dev-util/cmake: 3.9.4::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1-r2::gentoo sys-apps/openrc: 0.33.1::gentoo sys-apps/sandbox: 2.12::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.15.1-r1::gentoo sys-devel/binutils: 2.29.1-r1::gentoo sys-devel/gcc: 5.4.0-r3::gentoo, 6.4.0::gentoo, 7.2.0::gentoo sys-devel/gcc-config: 1.9.0::gentoo sys-devel/libtool: 2.4.6-r4::gentoo sys-devel/make: 4.2.1-r1::gentoo sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers) sys-libs/glibc: 2.25-r7::gentoo Repositories:
Thanks for the workaround (first one worked for me). Lost 3 hours getting out of this mess today. I suggest you get a fix in the tree ASAP, before more people get a black screen at their next reboot.
The new startDM.sh uses /lib/gentoo/functions.sh instead of /etc/init.d/functions.sh which is a link to /lib64/rc/sh/functions.sh # diff startDM.sh-orig /etc/X11/startDM.sh 2c2 < # Copyright 1999-2011 Gentoo Foundation --- > # Copyright 1999-2017 Gentoo Foundation 4d3 < # $Id$ 10c9,14 < . /etc/init.d/functions.sh --- > . /lib/gentoo/functions.sh /lib/gentoo/functions.sh belongs to sys-apps/gentoo-functions package # equery b /lib/gentoo/functions.sh * Searching for /lib/gentoo/functions.sh ... sys-apps/gentoo-functions-0.12 (/lib/gentoo/functions.sh) and /lib/rc/sh/functions.sh belongs to different package sys-apps/openrc # equery b /lib/rc/sh/functions.sh * Searching for /lib/rc/sh/functions.sh ... sys-apps/openrc-0.33 (/lib64/rc/sh/functions.sh) The work around fix uses the directory /lib64/rc/bin which belongs to sys-apps/openrc # equery b /lib64/rc/bin * Searching for /lib64/rc/bin ... sys-apps/openrc-0.33.1 (/lib64/rc/bin) It seems to me that the change in startDM and the work around are going in different directions. Am I missing something?
(In reply to Lars Wendler (Polynomial-C) from comment #2) > Or simply source /lib/rc/sh/functions.sh instead of /lib/gentoo/functions.sh > inside the startDM.sh script. Your workaround is better. I did that and it works too. Thanks.
*** Bug 634776 has been marked as a duplicate of this bug. ***
Manually editing /etc/X11/startDM.sh and changing path from /lib/gentoo/functions.sh to /etc/init.d/functions.sh fixed the problem. Have anyone ever tested this before committing change?! Why have you removed 1.3.4-r1 from portage tree w/o making sure the only ebuild you left is working?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9bd33b8105427c8f92ca509c1cf60d0bf67f7aad commit 9bd33b8105427c8f92ca509c1cf60d0bf67f7aad Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2017-10-19 16:07:07 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2017-10-19 16:07:07 +0000 x11-apps/xinit: Rev bump to -r3 after previous commit's revert Closes: https://bugs.gentoo.org/634706 Package-Manager: Portage-2.3.8, Repoman-2.3.3 RepoMan-Options: --force x11-apps/xinit/{xinit-1.3.4-r2.ebuild => xinit-1.3.4-r3.ebuild} | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
Okay, here's what happened: For bug 504140, wizardedit committed a patch to startDM.sh, which is in $FILESDIR and is installed by all versions of xinit (all of which are stable). I wasn't around in the four minutes between him asking for an ack on #gentoo-dev and committing it, so I didn't see it before it was committed, but when I did I noted that it modified files installed so it should have a revbump. I incorrectly assumed that it actually worked, so I added the -r2 bump straight to stable (so users would get the new change) and dropped the old versions (so that users could not have a version that potentially different on-disk contents). I have now reverted wizardedit's commit, and made yet another revbump (-r3) which will install the same contents as -r1 did originally. Very sorry for the trouble.
After many attempts I was able to bring up my system by a dirty hack in /etc/X11/startDM.sh @Matt, I updated xinit: * x11-apps/xinit Latest version available: 1.3.4-r3 Latest version installed: 1.3.4-r3 It still doesn't work for me. This was my workaround: On line 25: PATH=$PATH:/lib/rc/bin:/lib/rc/sh Thanks in advance.
(In reply to Matt Turner from comment #13) > Okay, here's what happened: > > For bug 504140, wizardedit committed a patch to startDM.sh, which is in > $FILESDIR and is installed by all versions of xinit (all of which are > stable). I wasn't around in the four minutes between him asking for an ack > on #gentoo-dev and committing it, so I didn't see it before it was > committed, but when I did I noted that it modified files installed so it > should have a revbump. > > I incorrectly assumed that it actually worked, so I added the -r2 bump > straight to stable (so users would get the new change) and dropped the old > versions (so that users could not have a version that potentially different > on-disk contents). > > I have now reverted wizardedit's commit, and made yet another revbump (-r3) > which will install the same contents as -r1 did originally. > > Very sorry for the trouble. Thanks for the info! And no problem, mistakes happen :) I am wondering what can be done to prevent this in the future? It seems this change was untested otherwise one would've noticed it doesn't work immediately. Ideally the test would be automated, but a manual test would be a start. Any ideas how to incorporate this? Related to this, it seems like a review process for these changes is missing and developers can commit changes straight to the gentoo tree, is that correct?
(In reply to Simon from comment #15) > (In reply to Matt Turner from comment #13) > > Okay, here's what happened: > > > > For bug 504140, wizardedit committed a patch to startDM.sh, which is in > > $FILESDIR and is installed by all versions of xinit (all of which are > > stable). I wasn't around in the four minutes between him asking for an ack > > on #gentoo-dev and committing it, so I didn't see it before it was > > committed, but when I did I noted that it modified files installed so it > > should have a revbump. > > > > I incorrectly assumed that it actually worked, so I added the -r2 bump > > straight to stable (so users would get the new change) and dropped the old > > versions (so that users could not have a version that potentially different > > on-disk contents). > > > > I have now reverted wizardedit's commit, and made yet another revbump (-r3) > > which will install the same contents as -r1 did originally. > > > > Very sorry for the trouble. > > Thanks for the info! And no problem, mistakes happen :) > > I am wondering what can be done to prevent this in the future? > It seems this change was untested otherwise one would've noticed it doesn't > work immediately. Ideally the test would be automated, but a manual test > would be a start. Any ideas how to incorporate this? > > Related to this, it seems like a review process for these changes is missing > and developers can commit changes straight to the gentoo tree, is that > correct? Yes. It's not a good system. Exherbo has a gerrit instance for review, which seems to be a nice improvement over our workflow. This problem could have been avoided by waiting a day to push the patch from the time review is requested in order to give people an opportunity to respond (which is what I told wizardedit I'd like to see). There is no substitute for actual testing though.
