we have get_bootparam() already in /sbin/functions.sh which means it's available to the init.d scripts do you really need 'nox' or is 'gentoo=nox' acceptable ? after all, 'gentoo=<foo>' is how every other option is passed to init.d scripts ...
The LiveCD people requested the 'nox' feature, bringing them in for input.
Well, "nox" was explicitly requested because it is what is used in livecd-tools to skip the X detection. If X isn't detected, then the display manager (and X) will likely fail. This causes lots of nastiness for LiveCD users, which was why the request was made. I'd prefer it if it stayed like it currently is for the functionality used by the LiveCD.
so fix the livecd tools to use gentoo=nox
That's really stupid considering all of the other options don't require prefixing with gentoo= to function. There's also the issue of limited space on the kernel command line, and the LiveCD builds already put quite a bit of data there. I wouldn't want these options to be ignored because it went over the buffer. To put it simply, gentoo=nox is *not* acceptable to us.
if the only purpose of this is for livecds, why arent the livecd scripts handling the option completely ? why does the xdm init.d script need to know about the option when the livecd should simply not be starting the xdm init.d script in the first place ?
It's useful in other cases too, some of which I've hit. * X freezes on startup, but you've got the xdm init script in your default runlevel * You're rebooting a machine and you don't want X to start up yet, because you want to change the config but forgot And yes, these can also be solved in many cases by doing an interactive boot.
(In reply to comment #6) > And yes, these can also be solved in many cases by doing an interactive boot. Or by appending "single" to the kernel command line and removing the services causing the problem manually and then allow boot to continue.
so then the init.d script uses the proper gentoo=nox while livecd scripts can continue to use their own short nox ... or you can do as Roy suggests
The LiveCD scripts don't start xdm. They never have. While it could be *changed* to do so, I don't see the point. Let me put it another way. What do we gain by changing this behavior, and is it worth the effort required to change the multiple places in livecd-tools and catalyst just to facilitate what I see as a cosmetic change?
Donnie, do we want to change this? If we do, it means removing the "nox" check from the init script, and I'll be putting all of the *dm starting in livecd-tools, instead. It means we'll only have this functionality on the LiveCD, of course.
(In reply to comment #10) > Donnie, do we want to change this? It really doesn't matter at all to me one way or the other. Do whatever you guys have decided is the best course.
@livecd folks. care to tell us what the status on this is? Thanks
Were we supposed to be doing something? It looks like it was just left in limbo
Let's start the discussion over then :) Do you guys still need gentoo=nox inside xinit's xdm init script? Can this be put somewhere else maybe? Cheers
No, the question was if "nox" itself was necessary, or if it can be moved to "gentoo=nox" instead. Truthfully, it doesn't matter. However, it will mean making changes to the livecd-tools scripts which use it, as well as the xdm init script. This support was originally requested for the LiveCD, which doesn't use gentoo=* for anything, but simple do*/no* commands. This may not be nearly as much of an issue as it once was, since the maximum length of the kernel command line has grown with newer kernels. Making this change *will* break backwards compatibility and will need documentation updates, as well. Personally, I see no reason to change it, but have no problem with making the necessary changes to the livecd-tools code. I tend to think that there's not enough value in the change versus the work required to enact it, but again, I will do whatever Gentoo decides. Now, if someone wants to provide the necessary patches against livecd-tools, catalyst, and (possibly) genkernel, I will commit them and this can be resolved. Otherwise, it will be changed whenever I get around to it.
only complaint i really have is that a reboot is required to undo the nox behavior. i.e. i know starting X is going to lock my system, so i add nox to rebuild the module (*cough* nvidia *cough*), but rather than simply reload the module and start the xdm init.d script, i now have to either edit the script to remove the check or reboot the system.
*** Bug 284722 has been marked as a duplicate of this bug. ***
All, livecd-tools creates a file, /etc/init.d/.noxdm when X is not supposed to start, which can occur in a couple of situations. - the user specifies nox on the command line. - the user specifies speakup.synth=foo or brltty=foo and does not specify dox. I think this issue could be resolved if /etc/init.d/xdm checked for the existance of /etc/init.d/.noxdm instead of checking the command line. William
Created attachment 203984 [details] xdm.patch This is a suggested patch to fix this issue. Let me know what you think. William
The problem with this approach is that it only works in conjunction with livecd-tools.
Created attachment 204027 [details] xdm-with-nox.patch All, this patch, which we will need someone who is running X to test, should work with both methods. nox on the livecd will create the file /etc/init.d/.noxdm which will signal this script to stop. Or, if it finds gentoo=nox on the command line it will stop. Check it out and let me know what you think. William
Created attachment 204050 [details] xdm-with-nox.patch All, this is an updated version of my second patch, per scarabeus. It now gives more specific messages regarding why xdm isn't starting.
Ok latest patch looks nice and sane. @remi`: what do you think, i would go with commiting it. Mostly it brings no dead rats into the tree :]
Created attachment 204073 [details] x-setup.initd-1 This is the x-setup init script. Currently, the only thing it does is check the kcl for gentoo=nox and touch the .noxdm file if the kcl parameter is there.
Created attachment 204075 [details] xdm.initd-3 Here is the updated xdm init script that takes advantage of the x-setup init script.
Guys, I have done a revbump to xinit for this bug, after working with Remi and dberkolz. So, please test and make sure that everything works, then, please fast track to stable so we can get it on the dvd. Thanks much. William
William, There is a mistake in x-setup: if check_bootparam "nox" ; then , should be: if get_bootparam "nox" ; then
All, I just discovered a problem. We can't name the new script x-setup because it will collide with livecd-tools x-setup. So, what other names do you suggest for the new script? Off the top of my head, I'm thinking x-init.
I'd say xdm-setup, if only because it relates to the xdm script. But that's just bikeshedding, pick one that works and sounds reasonably ok :) Cheers
All, I have renamed the script to xdm-setup and also addressed comment #27. Thanks for pointing that out.
Arch teams, we need xinit-1.0.8-r6 fast tracked to stable before the 10.0 live dvd release. The test to perform is as follows: 1) emerge and make sure you are using xdm-1.0.8-r6. Also, make sure that xdm is set to start on boot by adding to the default runlevel. 2) reboot and pass gentoo=nox on the kernel command line. - at this point xdm should not start. 3) Now start xdm manually and it should come up. If this works, please stabilize 1.0.8 on your arch asap. Thanks much. William
In the last comment, I meant stabilize 1.0.8-r6. Thanks. William
William please test the latest hybrid isos, I made a change to xdm initd so speakup.synth and brltty work.
I am adding patches above and they will be part of my next build.
I think the xdm-setup init-script needs some kind of dependency to make sure /etc/init.d is writable. One possibility that should work with baselayout 1 and 2 is "need localmount".
All, I just did another rev bump to address comment #35. Please stabilize -r7 instead. Thanks much.
Arch teams, what is the status of stabilization? This is needed for the live cd/dvd release. Thanks, William
# USE="consolekit" emerge -1av =x11-apps/xinit-1.0.8-r7 These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds built with USE flags to satisfy "sys-apps/hal[consolekit]". !!! One of the following packages is required to complete your request: - sys-apps/hal-0.5.11-r9 (Missing IUSE: consolekit) (dependency required by "x11-apps/xinit-1.0.8-r7" [ebuild]) (dependency required by "=x11-apps/xinit-1.0.8-r7" [argument]) needs newer hal.
(In reply to comment #38) > needs newer hal. Is there a simple solution?
*** Bug 285740 has been marked as a duplicate of this bug. ***
I guess we should go for x11-apps/xinit-1.0.8-r8? 21 Sep 2009; Tomáš Chvátal <scarabeus@gentoo.org> xinit-1.0.8-r8.ebuild: Remove not required dependencies (aka kill hal useflag). Per #g-dev discussion. *xinit-1.0.8-r8 (21 Sep 2009) 21 Sep 2009; Tomáš Chvátal <scarabeus@gentoo.org> +xinit-1.0.8-r8.ebuild: Revbump the xinint for the last commit so automagicness is fixed even for those whom already compiled the thing. 21 Sep 2009; Tomáš Chvátal <scarabeus@gentoo.org> xinit-1.0.8-r7.ebuild: Disable automagicness. Per bug #285741. 19 Sep 2009; Tomáš Chvátal <scarabeus@gentoo.org> xinit-1.0.8-r7.ebuild, metadata.xml: Adjust the hal/consolekit mess to be more sane.
Writing to /etc/init.d/ a file like .noxdm is very wrong and causes runlevel cache to be tainted (which has a VERY BAD performance impact). Please fix, x11-apps/xinit added the support for .noxdm in /tmp.
All, I just spoke with lxnay about this on IRC. Please disregard comment #42. Please stabilize -r8. Thanks much.
All, on my previous comment I said to disregard comment #42. What I meant was that this comment deals with an issue in livecd-tools, and since this bug is against xinit, that comment will be handled in another bug.
amd64/x86 stable
ppc stable
ppc64 stable
Stable for HPPA.
Stable on alpha.
arm/ia64/s390/sh/sparc stable, closing
