jdd wrote:

Le 11/11/2011 14:30, James Knott a écrit :

...

What about systems, such as my firewall or a server that are normally started without a desktop? In previous versions, you'd just edit inittab to change the run level. How is that done now?

probably the same one (it's only from a terminal that the behavioir is different AFAIK)

jdd

The idea is to start the computer without a desktop. Previously, editing inittab did that. It no longer does. What's the new method to start a computer without a desktop? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/11/2011 10:52 AM, jdd wrote:

Le 11/11/2011 16:39, James Knott a écrit :

...

The idea is to start the computer without a desktop. Previously, editing inittab did that. It no longer does. What's the new method to start a computer without a desktop?

right now I see only adding 3 to the kernel grub line, but I fiond this odd

I thought this was covered already? Don't you change a symlink to a service file? One service file does the same as init 5, another service fie does the same as init 3. I think the names are different for opensuse but it's like this: http://fedoraproject.org/wiki/Systemd#How_do_I_change_the_default_runlevel.3... That's not a great process but it's early days. Ultimately I guess the ideal would be for one or more scripts to be written to optionally parse inittab and sysv init scripts if they exists to make systemd read sysv init files as an optional compatibility bridging part of it's processing. And eventually develop a new template for writing init scripts so that a single script can function as either a sysv init script or a systemd service sscript. Probably involving smallish changes to the script itself and the bulk of the compatibility magic in some function libraries that get sourced at the top. systemd appears perfectly configurable and customizable, at least or more than sysv init, so things like after.local and pretty much any desired action look pretty straight forward to replicate, merely the names and places of scripts and the methods to specify dependencies & order of operations are different, but no harder. The difficulties I see are all in breaking so much existing system integration and assumptions by existing software. The differences are not that baffling or hard to adapt to, taken individually, but the fact that it has been sysv init forever, since before even linux existed, let alone the entire run of linux, let alone the entire run of suse linux, so much software is out there that just assumes sysv init. In my case I have to deal with drivers and proprietary daemons for multiport serial cards (digi, equinox) and T1 fax modem cards (eicon) and network serial port server boxes and terminal servers (equinox, digi, cyclades) and hardware raid cards (adaptec, lsi, 3ware), proprietary terminal emulator daemons (FacetWin), commercial application software that includes daemons (Rand McNally MileMaker, PC-Miler, VSI-FAX, Prophesy) ... all these things include either one-time startup actions or one or more daemons each, or both, so their installers do need to know how to install startup and shutdown scripts, are closed source, poorly supported on linux despite being anywhere from fairly to very expensive, include poorly written frankly broken installers and start scripts that I usually have to hand edit but at least they are sysv init scripts, and absolutely necessary, and many no longer going to be updated, will never see systemd support. Unless systemd can seamlessly support sysv init files, it will simply break ALL of those. requiring me, and every other user using products like these, to hand craft their own replacements for the vendor supplied init scripts, and manually fix the supplied installers, where possible, or figure out various ways to fake out the installers so that they think they installed onto a system that's laid out the way they expect, then go rearrange the stuff that got installed after the fact to work on systemd. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/11/2011 07:39 AM, James Knott wrote:

The idea is to start the computer without a desktop. Previously, editing inittab did that. It no longer does. What's the new method to start a computer without a desktop?

I just had an idea based on my experience with 11.4 after a zypper dup a few weeks ago: just arrange for kdm to crash during boot! This shouldn't be too difficult, it's doing it all by itself! After the screen blinks and the graphic adapter's fans change RPM, the boot sequences returns and completes leaving you with a command-line login and no X. Of course, if you "want" to run KDE you can always make /usr/bin/Xorg setuid root and run "startx". Do it the old fashioned way, as in chmod 4755 /usr/bin/Xorg. But be sure you make sure your default shell is /bin/bash or you'll get an X crash without any hints of the failure in the logs. You and your users will have to eschew /bin/tcsh. Regards, Lew ..who is wondering if he's getting too old... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org