/etc/init.d/xdm part of xorg-server-1.9 fails to start when it can't find xdm-setup which was recently removed from it. /etc/init.d/xdm-setup had code to check kernel line for 'nox' so that init.d/xdm could not start in case of users that are on a livecd and want to just have a terminal and or accessibility users using speakup. Reproducible: Always Steps to Reproduce: 1. emerge =x11-base/xorg-server-1.9.0 2. /etc/init.d/xdm start 3. Actual Results: * ERROR: cannot start xdm as xdm-setup would not start Portage 2.2_rc84 (default/linux/x86/10.0, gcc-4.4.3, glibc-2.11.2-r0, 2.6.34-hardened-r1 i686) ================================================================= System uname: Linux-2.6.34-hardened-r1-i686-Intel-R-_Xeon-R-_CPU_E5420_@_2.50GHz-with-gentoo-2.0.1 Timestamp of tree: Sun, 19 Sep 2010 22:00:20 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] ccache version 2.4 [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.67 sys-devel/automake: 1.6.3-r1, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA @BINARY-REDISTRIBUTABLE" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="bn brx cy dgo eo eu fa gl gu_IN id kk kn_IN kok ks ku mai mn mni my sa_IN sat sd ta_IN tn uz en ca" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/x11 /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl atm berkdb bindist branding bzip2 cairo cli cracklib crypt cups cxx dbus dri fbcondecor fortran gdbm gif gnome gpm hal iconv ipv6 jpeg livecd loop-aes mmx mng modules mudflap ncurses nls nouveau nptl nptlonly opengl openmp pam pcre perl png portaudio pppd python qt3support qt4 readline reflection session socks5 sse sse2 ssl sysfs tcpd tiff truetype unicode usb x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="bn brx cy dgo eo eu fa gl gu_IN id kk kn_IN kok ks ku mai mn mni my sa_IN sat sd ta_IN tn uz en ca" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nouveau fbdev glint intel mach64 mga neomagic nv r128 radeon savage tdfx trident vesa via vmware cirrus ast chips i128 i740 imstt s3virge tseng v4l vermilion" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Most likely you forgot to run etc-update after emerging xorg-server-1.9. The new xdm init script doesn't need xdm-setup anymore.
(In reply to comment #1) > Most likely you forgot to run etc-update after emerging xorg-server-1.9. The > new xdm init script doesn't need xdm-setup anymore. > etc-update was ran and the odd thing is there is no reference to xdm-setup anywhere in init.d/xdm also why is init.d/xdm depending on itself?
(In reply to comment #1) > Most likely you forgot to run etc-update after emerging xorg-server-1.9. The > new xdm init script doesn't need xdm-setup anymore. > I can confirm that it is not an etc-update issue. I have no idea how xdm-setup gets called as a dependency for xdm when there is no reference whatsoever to xdm-setup in /etc/init.d/xdm
Could you print out which versions of xorg-server and xinit you have on your system? I think you might be mixing ~arch and stable versions. Thanks
(In reply to comment #4) > Could you print out which versions of xorg-server and xinit you have on your > system? I think you might be mixing ~arch and stable versions. > > Thanks > x11-apps/xinit-1.2.1-r2 USE="pam -debug -minimal" x11-base/xorg-server-1.9.0 USE="nptl udev xorg -dmx -doc -ipv6 -kdrive -minimal -static-libs -tslib" Still, what I am most curious about is how (from where) does it get to attempt calling xdm-setup.
Hum... could you try fiddling around with rc-update to see if xdm-setup is listed somewhere? To me it's starting to look like a baselayout/openrc issue... Thanks
(In reply to comment #6) > Hum... could you try fiddling around with rc-update to see if xdm-setup is > listed somewhere? To me it's starting to look like a baselayout/openrc issue... > > Thanks > Not in rc-update. Also, I get no output from: find /etc -exec grep -H xdm-setup {} \; Yet if I run: /etc/init.d/xdm -Z start I get: * start: xdm-setup xdm So still I wonder, where the heck does it get xdm-setup from? It's not in the /etc/init.d/xdm script depend() section or anywhere else for that matter. Note that doing '/etc/init.d/xdm -D start' works just fine. So I don't think there's an error in the init script itself unless I haven't spotted some cryptic reference to xdm-setup in it.
Reopening
@CCed herds, have any of you seen this before? Thanks
i imagine if xdm is emerged, dependencies are updated, and then etc-update is run, baselayout wont detect the dependency change. this is because etc-update preserves the timestamps of updated files. simply do `touch /etc/init.d/xdm` and try starting it. not sure this is something worth fixing as it's an edge case and the overhead required to address it bullet proof greatly outweighs the speed ups we get.
rc-update -u might help as well in this case...
hmm, i wonder if we could get etc-update to run `rc-update -u` after updating files in /etc/{conf,init}.d/ ... or if we should have some hook system so packages can opt-in ...
(In reply to comment #10) > i imagine if xdm is emerged, dependencies are updated, and then etc-update is > run, baselayout wont detect the dependency change. this is because etc-update > preserves the timestamps of updated files. I remember having a discussion about something like this a long time ago and the issue of mtime preservation was supposed to be solved by the directory mtime changing when one file is replaced by another via rename. So, it seems like the rc system is failing to invalidate it's dependency cache when the directory mtime changes.
(In reply to comment #11) > rc-update -u > > might help as well in this case... > That fixed things for me indeed, thanks (and I believe I originated the bug, Fernando just submitted it for me). I'll know what to do when I get strange init script dependency problems again. This might help me fix another one with bluetooth as well or at least will give me something new to look into. Thanks a lot.
Not an X bug then, please let us know if we should modify our ebuilds to make this upgrade safer. Thanks :)
I never had this problem with the previous xorg-server-1.9.0 build. This morning the emerge of 1.9.0-r1 failed to build because of this bug # 339035. I waited a few hours then re-synced portage and was able to successfully build the new version. Now however, I have this issue. XDM failed to start because of missing xdm-start. I can launch KDE by logging into my user from the VT with the 'startx' command which is how I'm writing this now. I've searched as mentioned below for xdm-setup which doesn't exist on my system. I'm running baselayout2 on an ~x86 laptop. If I run: '/etc/init.d/xdm -Z start' I get: '* ERROR: xdm needs service(s) xdm-setup' I've tried to 'touch /etc/init.d/xdm' and running 'rc-update -u' with absolutely no luck. 'rc-update -u' yields this error msg: * Caching service dependencies ... Service `xdm' needs non existant service `xdm-setup' As I said I can still get to my desktop via the VT and 'startx' but I prefer no having to do so. TIA
did you `etc-update` ? what does 'depend' say in /etc/init.d/xdm ?
x11-base/xorg-server-1.9.0-r1 clearly installs an /etc/init.d/xdm file that depends on xdm-setup: ========================================================== $ grep -A1 depend /usr/portage/x11-base/xorg-server/files/xdm.initd-3 depend() { need localmount xdm-setup ========================================================== I patched mine to read: ========================================================== $ grep -A2 depend /etc/init.d/xdm depend() { need localmount use xdm-setup ========================================================== Which appears to solve the problem.
# pwd /usr/portage/x11-base/xorg-server # grep xdm xorg-server-1.9.0-r1.ebuild newinitd "${FILESDIR}"/xdm.initd-3 xdm || die "initd file install failed" newconfd "${FILESDIR}"/xdm.confd-3 xdm || die # grep xdm-setup files/xdm.{init,conf}d-3 files/xdm.initd-3: need localmount xdm-setup xdm-setup needs to be removed from that line still.
*** Bug 339058 has been marked as a duplicate of this bug. ***
all you've shown is that you didnt etc-update. not a bug in Gentoo. $ grep initd xorg-server-1.9.0.ebuild newinitd "${FILESDIR}"/xdm.initd-2 xdm || die "initd file install failed" $ egrep '^[[:space:]]*\<(need|use)\>' files/xdm.initd-2 need localmount xdm use consolekit xfs
Hello, I *DID* dispatch-conf, as every time, and applied the new changes. I even removed /etc/init.d/xdm and it appeared again! (In reply to comment #21) > all you've shown is that you didnt etc-update. not a bug in Gentoo. > > $ grep initd xorg-server-1.9.0.ebuild > newinitd "${FILESDIR}"/xdm.initd-2 xdm || die "initd file install failed" > > $ egrep '^[[:space:]]*\<(need|use)\>' files/xdm.initd-2 > need localmount xdm > use consolekit xfs >
(In reply to comment #21) > all you've shown is that you didnt etc-update. not a bug in Gentoo. Seems you didn't emerge --sync as there no longer is an xorg-server-1.9.0.ebuild nor a xdm.initd-2 file: xorg-server-1.9.0.ebuild has been replaced by xorg-server-1.9.0-r1.ebuild and xdm.initd-2 by xdm.initd-3
As you see xdm-init.3 needs xdm-setup. *THIS IS A BUG* grep -R xdm-setup . ./x11-apps/xinit/xinit-1.2.0-r3.ebuild: newinitd "${FILESDIR}"/xdm-setup.initd-1 xdm-setup || die ./x11-apps/xinit/xinit-1.2.1.ebuild: newinitd "${FILESDIR}"/xdm-setup.initd-1 xdm-setup || die ./x11-apps/xinit/Manifest:AUX xdm-setup.initd-1 340 RMD160 65c5ee210735aaaa49033ae29f91ae658b8cd512 SHA1 1f5453bc2810b0cb89d3ec8f78871bbfd3a0a450 SHA256 1b8b39f95f17e0e6e61d20339804800834f4bd0fcbd6023f5d9039c1ed9599db ./x11-apps/xinit/ChangeLog: files/xdm-setup.initd-1, -xinit-1.0.8-r4.ebuild, -xinit-1.0.8-r7.ebuild, ./x11-apps/xinit/ChangeLog: 06 Oct 2009; William Hubbs <williamh@gentoo.org> files/xdm-setup.initd-1, ./x11-apps/xinit/ChangeLog: 24 Sep 2009; William Hubbs <williamh@gentoo.org> files/xdm-setup.initd-1, ./x11-apps/xinit/ChangeLog: Now the xdm-setup script creates the .noxdm file in /tmp and the xdm ./x11-apps/xinit/ChangeLog: 23 Sep 2009; William Hubbs <williamh@gentoo.org> files/xdm-setup.initd-1, ./x11-apps/xinit/ChangeLog: 23 Sep 2009; Rémi Cardona <remi@gentoo.org> files/xdm-setup.initd-1, ./x11-apps/xinit/ChangeLog: 17 Sep 2009; William Hubbs <williamh@gentoo.org> files/xdm-setup.initd-1, ./x11-apps/xinit/ChangeLog: Another rev bump to make sure that xdm-setup runs after /etc/init.d is ./x11-apps/xinit/ChangeLog: Fixed dependency on x-setup; it should be xdm-setup. ./x11-apps/xinit/ChangeLog: +files/xdm-setup.initd-1, -xinit-1.0.8-r5.ebuild, +xinit-1.0.8-r6.ebuild: ./x11-apps/xinit/ChangeLog: Fixed a typo in x-setup and renamed it to xdm-setup. ./x11-apps/xinit/files/xdm-setup.initd-1:# $Header: /var/cvsroot/gentoo-x86/x11-apps/xinit/files/xdm-setup.initd-1,v 1.7 2009/11/14 14:18:43 scarabeus Exp $ ./x11-apps/xinit/files/xdm.initd-4: need localmount xdm-setup ./x11-base/xorg-server/Manifest:AUX xdm-setup.initd-1 346 RMD160 e68512e71adbf15743f789bb6b5587b07a9812a3 SHA1 f25303b8bcef0c5d2eb61517d5347b4b88736cd4 SHA256 942ce5e8d1a0770543b683dcc388bae7619a24eb9741c1cd678ed3df97c01406 ./x11-base/xorg-server/xorg-server-1.8.2.ebuild: newinitd "${FILESDIR}"/xdm-setup.initd-1 xdm-setup || die ./x11-base/xorg-server/ChangeLog: +files/1.8.0-no-hardcoded-etc.patch, +files/xdm-setup.initd-1, ./x11-base/xorg-server/files/xdm-setup.initd-1:# $Header: /var/cvsroot/gentoo-x86/x11-base/xorg-server/files/xdm-setup.initd-1,v 1.1 2010/04/13 10:07:39 scarabeus Exp $ ./x11-base/xorg-server/files/xdm.initd: need localmount xdm-setup ./x11-base/xorg-server/files/xdm.initd-3: need localmount xdm-setup
I fixed the current issue. but it shouldn't have been duped again this bug.
Adjusting topic to what is the issue reported above.
Created attachment 248928 [details, diff] patch to fix xdm.initd-3 The problem I experience is not the result of a failure to run etc-update.
(In reply to comment #26) > Adjusting topic to what is the issue reported above. > Please listen to users. I use Gentoo since 2004 and I know etc-update. I feel really humiliated by an arrogant developer. This is not as the title describes. I synced the tree, removed /etc/init.d/xdm and the file shows "xdm-setup". Please listen.
(In reply to comment #26) > Adjusting topic to what is the issue reported above. A clear mistake - the problem for some is an issue with at least one version of an xorg-server ebuild supplied xdm init file, not an openrc problem and not a failure to run etc-update.
xdm.initd-3 has nothing to do with this bug. this bug is about xorg-server-1.9.0 and xdm.initd-2. if you have a different version, you're posting to the wrong bug.
>28 Sep 2010; Tomáš Chvátal (scarabeus) >xorg-server-1.9.0-r1.ebuild: >Add one more missing line on newinitd. I just saw this on cvs. Doesn't it need a revbump as well? or those that installed -r1 before that will still have a broken xorg-server :)
(In reply to comment #30) > xdm.initd-3 has nothing to do with this bug. this bug is about > xorg-server-1.9.0 and xdm.initd-2. if you have a different version, you're > posting to the wrong bug. Then this bug should be summarily closed as again both that ebuild and that init script are no longer in portage. And Bug 339058 should never have been marked as a dup of this one.
(In reply to comment #31) > *** Bug 339058 has been marked as a duplicate of this bug. *** Xavier - maybe you can reopen Bug 339058 ?
again, xorg-server-1.9.0-r1 has nothing to do with this bug. please stop posting about it.
please don't picture adept users as noobs or PEBKACs who forgot to run fundamental steps, e.g. etc-update after updates I tend to forget it from time to time, too (I'm sure everyone already has in the pat) BUT this time I'm 100% confident that this problem got introduced BECAUSE an update from the tree contained that change: Mon Sep 27 17:12:50 2010 >>> x11-base/xorg-server-1.9.0 merge time: 2 minutes and 50 seconds. to Tue Sep 28 18:28:34 2010 >>> x11-base/xorg-server-1.9.0-r1 merge time: 2 minutes and 38 seconds. and the behavior was described like posted above running rc-update -u and changing depend() { need localmount xdm-setup to depend() { need localmount use xdm-setup "fixed" it for me thanks !
i'll paint people who dont read bugzilla comments as noobs
(In reply to comment #37) > i'll paint people who dont read bugzilla comments as noobs The summary of this bug was originally (and when I started posting to it) "x11-base/xorg-server-1.9: init.d/xdm will not start because of missing init.d/xdm-setup", the _exact_ same symptoms for the "x11-base/xorg-server-1.9.0-r1". And in fact "x11-base/xorg-server-1.9" as used in the sammary is not fully qualified - it does not strictly specify only "x11-base/xorg-server-1.9.0" but appeared to encompass both "x11-base/xorg-server-1.9.0" and "x11-base/xorg-server-1.9.0-r1" so it was easy for such a noob as myself to make such horrible mistakes. My sincere apologies.
Chris: you were the only one i wasnt counting :P original reporter (Fernando): what fs are you using in / ?
If I understand this bug correctly, the issue is that the openrc dependency cache is not updated automatically if the dependencies in an rc script are changed. Mike, am I on the right track? If so, the next question I have is, is there a way we can know if something changed in /etc/init.d or wherever the services startup scripts happen to be located and force rebuilding the dependency cache in that situation?
we're relying on the timestamp of /etc/init.d to be updated when a file in that dir is updated. the original issue reported here would imply that this is not always the case, but it isnt trivial to reproduce.
I am considering making a forced deptree update happen every time a user runs "rc-update add" or "rc-update del". Are there any objections to this?
(In reply to comment #42) sounds reasonable. `rc-status` already does.
Currently, openrc checks e.g. /etc/init.d and our mtime check will return the newest file and it's mtime. When etc-update is used and it preserves the mtime, the mtime of the init.d directory is or should be updated anyway and thus it will be detected by our mtime check. I did some tests here with touch/touch -a, etc-update etc. The only one that will not be detected is touch -a. So if you update a package, like xdm and it will install a new init script as e.g. /etc/init.d/._cfg0000_xdm it will cause a dep cache rebuild. If you update the init script with etc-update it will update the dep cache. So either etc-update has been "fixed" recently or I just can't reproduce it.
(In reply to comment #44) > So if you update a package, like xdm and it will install a new init script > as e.g. /etc/init.d/._cfg0000_xdm it will cause a dep cache rebuild. If you > update the init script with etc-update it will update the dep cache. > > So either etc-update has been "fixed" recently or I just can't reproduce it. There was never anything to "fix" in etc-update, because it never fooled around with directory mtimes. Whenever it has renamed files, the parent directory's mtime has always changed automatically because that's just how directory mtimes work.
