[opensuse] 12.3 installation, runlevels and trouble shooting
OK gang, I get it new and shiny is kool. This, however, is ridiculous. Booting from install media puts my Dell XPS 1730 (aka Dell MXG071) w/Nvidia GeForce 8700M GT into display test mode (pretty colors on the LCD but not very compute useful), unless I use failsafe mode... And after install all I have is x11failsafe and a VERY slow system. Systemd doesn't seem to allow me to switch to what used to be runlevel 3 (does such a thing still exist in a port systemd world?) to even begin to troubleshoot. Open a bug? Sure, where to start? What exactly is broken? You tell me, where do I start. BTW, I am NOT a windows/OS X refugee. I've been doing this a very long time. 12.3 is a mess at best! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Thu, 11 Apr 2013 09:45:29 -0700 Bruce Ferrell <bferrell@baywinds.org> пишет:
OK gang,
I get it new and shiny is kool. This, however, is ridiculous.
Booting from install media puts my Dell XPS 1730 (aka Dell MXG071) w/Nvidia GeForce 8700M GT into display test mode (pretty colors on the LCD but not very compute useful), unless I use failsafe mode... And after install all I have is x11failsafe and a VERY slow system.
Systemd doesn't seem to allow me to switch to what used to be runlevel 3 (does such a thing still exist in a port systemd world?) to even begin to troubleshoot.
Add 3 to kernel command line.
Open a bug? Sure, where to start? What exactly is broken?
You tell me, where do I start.
BTW, I am NOT a windows/OS X refugee. I've been doing this a very long time. 12.3 is a mess at best!
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 11/04/13 13:51, Andrey Borzenkov escribió:
В Thu, 11 Apr 2013 09:45:29 -0700 Bruce Ferrell <bferrell@baywinds.org> пишет:
OK gang,
I get it new and shiny is kool. This, however, is ridiculous.
Booting from install media puts my Dell XPS 1730 (aka Dell MXG071) w/Nvidia GeForce 8700M GT into display test mode (pretty colors on the LCD but not very compute useful), unless I use failsafe mode... And after install all I have is x11failsafe and a VERY slow system.
Systemd doesn't seem to allow me to switch to what used to be runlevel 3 (does such a thing still exist in a port systemd world?) to even begin to troubleshoot.
Add 3 to kernel command line.
or boot with systemd.unit=multi-user.target .. OR issue init 3 in the command line..
"(does such a thing still exist in a port systemd world?)"
There is backward compatibility for runlevels 3 and 5, but runlevels no longer exist. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Cristian Rodríguez <crrodriguez@opensuse.org> [04-11-13 13:14]:
El 11/04/13 13:51, Andrey Borzenkov escribió:
В Thu, 11 Apr 2013 09:45:29 -0700 Bruce Ferrell <bferrell@baywinds.org> пишет:
OK gang,
I get it new and shiny is kool. This, however, is ridiculous.
Booting from install media puts my Dell XPS 1730 (aka Dell MXG071) w/Nvidia GeForce 8700M GT into display test mode (pretty colors on the LCD but not very compute useful), unless I use failsafe mode... And after install all I have is x11failsafe and a VERY slow system.
Systemd doesn't seem to allow me to switch to what used to be runlevel 3 (does such a thing still exist in a port systemd world?) to even begin to troubleshoot.
Add 3 to kernel command line.
or boot with systemd.unit=multi-user.target .. OR issue init 3 in the command line..
and *probably*: nomodeset -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Systemd doesn't seem to allow me to switch to what used to be runlevel 3 (does such a thing still exist in a port systemd world?) to even begin to troubleshoot. makes me wonder if I ran into that when I was dealing with that graphics card
On 4/11/2013 1:18 PM, Patrick Shanahan wrote: problem. One of the things I tried was to select runlevel 3 because I figured that if it booted in a non graphic mode, my original ATI might work. I still got the black screen and that is when I finally decided to go with a new graphics card and forget the hassle. Damon Register -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/04/13 04:18, Damon Register wrote:
Systemd doesn't seem to allow me to switch to what used to be runlevel 3 (does such a thing still exist in a port systemd world?) to even begin to troubleshoot. makes me wonder if I ran into that when I was dealing with that graphics card
On 4/11/2013 1:18 PM, Patrick Shanahan wrote: problem. One of the things I tried was to select runlevel 3 because I figured that if it booted in a non graphic mode, my original ATI might work. I still got the black screen and that is when I finally decided to go with a new graphics card and forget the hassle.
Damon Register
You are still going to get the same "black screen" even with the new graphics card because if the driver - and here I am assuming the nVidia driver - does not fit the version of the kernel then you need to compile the driver for the installed kernel. And the only way I know how to do this is to boot into level 3 and then compile the driver. Why were the runlevels done away with anyway? For what illogical reason? BC -- Using openSUSE 12.3 x86_64 KDE 4.10.2 & kernel 3.8.6-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Basil Chupin said the following on 04/12/2013 12:58 AM:
Why were the runlevels done away with anyway? For what illogical reason?
Ask that of the various *NIX implementations that never used the SVR4 'runlevel' concept in the first place. They considered runlevels to be illogical .... in the first place. -- TCP/IP Illustrated... Is that the swimsuit edition? -- rgh22 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Basil Chupin <blchupin@iinet.net.au> [04-12-13 01:02]: [...]
Why were the runlevels done away with anyway? For what illogical reason?
They have not *really* been "done away with", but have really changed considerably in ?definition?. Runlevel is/was a system state where certain capabilities are present such as (loosely) 5, the graphical state, and 3, multi-user/networking state. Now you have targets which have similar names and capabilities but are not numbered and represent a "dynamic" state where the deamons may not be active but will be called if necessary. Think of it like having a pantry stocked for daily needs and the same pantry stocked for a family get-together, runlevel 3/5, vs a minimally stocked pantry but ready access to needed items for either level from a grocery next door. This may not be accurate but that is what I understand from list conversation. Previous, you could not apply a different system graphics driver while the present driver what used, runlevel 5, but dropping to a text mode, runlevel 3, you could. Now by leaving the "graphics target" you accomplish the same and are able to install a different graphics driver. I believe it is called "progress" :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
They have not *really* been "done away with", but have really changed considerably in ?definition?. Runlevel is/was a system state where certain capabilities are present such as (loosely) 5, the graphical state, and 3, multi-user/networking state. Now you have targets which have similar names and capabilities but are not numbered and represent a "dynamic" state where the deamons may not be active but will be called if necessary.
The nearest documentation I could find on suse is given below. http://en.opensuse.org/SDB:Configuring_graphics_cards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan said the following on 04/12/2013 07:54 AM:
They have not *really* been "done away with", but have really changed considerably in ?definition?. Runlevel is/was a system state where certain capabilities are present such as (loosely) 5, the graphical state, and 3, multi-user/networking state. Now you have targets which have similar names and capabilities but are not numbered and represent a "dynamic" state where the deamons may not be active but will be called if necessary.
Indeed. Realistically we only used runlevels 1, 3 and 5 That is: single use with networking turned off; multi-user with networking tuned on; graphical mode. We still have those, its just that we now have clearer names rather than numbers. These weren't 'levels' these were 'states. As Patrick says, each state had certain capabilities present. The sysvinit approach did some stupid things. You can see in the old /etc/init.d/rc{1,3,5}/ there are S for start and K for Kill scripts. Moving from one state to another could involve killing and then restarting a deamon. That seems 'illogical' to me. -- The Internet is not the greatest threat to information security; stupidity is the greatest threat to information security. - Will Spencer <will.spencer@gte.net> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Fri, 12 Apr 2013, Anton Aylward wrote:
The sysvinit approach did some stupid things. You can see in the old /etc/init.d/rc{1,3,5}/ there are S for start and K for Kill scripts. Moving from one state to another could involve killing and then restarting a deamon. That seems 'illogical' to me.
Oh yes? ==== man 8 init ==== CHANGING RUNLEVELS [..] When init is requested to change the runlevel, it sends the warning signal SIGTERM to all processes that are undefined in the new runlevel. ==== -dnh -- If you don't see why, please stay the fuck away from my code. -- Paul "Rusty" Russel, in /usr/src/linux/Documentation/DocBook/kernel-locking.tmpl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David Haller said the following on 04/12/2013 02:18 PM:
Hello,
On Fri, 12 Apr 2013, Anton Aylward wrote:
The sysvinit approach did some stupid things. You can see in the old /etc/init.d/rc{1,3,5}/ there are S for start and K for Kill scripts. Moving from one state to another could involve killing and then restarting a deamon. That seems 'illogical' to me.
Oh yes?
==== man 8 init ==== CHANGING RUNLEVELS [..] When init is requested to change the runlevel, it sends the warning signal SIGTERM to all processes that are undefined in the new runlevel. ====
YES - because I'm not talking about undefined processes. I'm talking about the ones for which there is a K file in the current run level and a S file in the new level. For example, moving from 3 to 5, there is /etc/init.d/rc3.d/K02cups then /etc/init.d/rc5.d/S10cups Oh, wait, no! There is explicit code if test -s /etc/rc.status then . /etc/rc.status else exit 1 fi Well OK, but its up to the person coding the unit to take care of that. Its not intrinsic to the mechanism as it is with systemd. -- "Current economics is merely refining the obsolete. Economic theory is still based on the scarcity axiom, which doesn't apply to information. When I sell you a phone, I no longer have it. When I sell information to you, I have more information by the very fact that you have it and I know you have it. That's not even true of money." -- Peter Drucker, WiReD6.03 Mar-1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Fri, 12 Apr 2013, Anton Aylward wrote:
David Haller said the following on 04/12/2013 02:18 PM:
On Fri, 12 Apr 2013, Anton Aylward wrote:
The sysvinit approach did some stupid things. You can see in the old /etc/init.d/rc{1,3,5}/ there are S for start and K for Kill scripts. Moving from one state to another could involve killing and then restarting a deamon. That seems 'illogical' to me.
Oh yes?
==== man 8 init ==== CHANGING RUNLEVELS [..] When init is requested to change the runlevel, it sends the warning signal SIGTERM to all processes that are undefined in the new runlevel. ====
YES - because I'm not talking about undefined processes. I'm talking about the ones for which there is a K file in the current run level and a S file in the new level.
A service having a "S*" file in the new runlevel is _defined_ in that runlevel and won't get signalled (TERM ... KILL) by init.
For example, moving from 3 to 5, there is /etc/init.d/rc3.d/K02cups then /etc/init.d/rc5.d/S10cups
Oh, wait, no! There is explicit code
if test -s /etc/rc.status then . /etc/rc.status else exit 1 fi
Well OK, but its up to the person coding the unit to take care of that.
I don't have cups installed (I don't print), but that snippet is not the culprit why cupsd might get/have been killed and restarted on a RL-change on your box with init. Have a look into /etc/rc.status, that should still exist on 12.3.
Its not intrinsic to the mechanism as it is with systemd.
Unless the init-script-writer breaks the init-mechanism, all is fine. And I _BET_ that systemd units will be breaking the systemd mechanism too, sooner or later, most likely by borked dependecies or some such. BTW: systemd is trying to do more each week. Or so it seems to me. cf. http://freedesktop.org/wiki/Software/systemd/. I don't need a fucking /etc/machine-id. # ls -l /etc/machine-id lrwxrwxrwx [..] /etc/machine-id -> /dev/null I DO NOT WANT systemd replacing either syslog, inetd or mingetty. I DO NOT WANT localed, logind, whatnotd (nor ConsoleKit or any other of that *Kit stuff). I do not use any "Display Manager" nor any "Desktop Environment". I mount and want to keep mounting stuff manually. And IMNSHO merging /usr and / is plain stupid. My guess it's all just to hide the bloat. systemd is an abomination with respect to the unix-mantra: Do *one* thing, and do that good. systemd is trying to become the egg-laying-woolen-milk-giving-sow. And I can see it coming that it'll be "unmaintainable" in a year or two. And we'll get a big yay promise for systemd2, all new and shiny and different! *hoooray* Hell, AFAIK, even MacOS X has a better seperation between the GUI and the system. Any intermingling of system and desktop stuff (see Networkmanager, *Kit, dbus, pulse/phonon/gstreamer, and now systemd) is EVIL! And using XML config-files??? [aside: I'm running only those I could not avoid (yet), i.e. console-kit, polkitd and hald for KDE stuff] I'm ok with the idea of converging /etc/*-release into os-release though. -dnh, frotzing Linux (SuSE) since '97, and anyone who finds sarcasm and has any objections can cube it and stuff it where the sun don't shine. Sideways. I'm *that* close to switch to gentoo or LFS and/or create a "Hallerlix2" once and for all. Or to a BSD. PS: I can't think of a package on freedesktop.org that I like ... -- Get your acts together, guys. Stop blathering and frothing at the mouth. -- Linus Torvalds -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sat, 13 Apr 2013 01:29:54 +0200 David Haller <dnh@opensuse.org> пишет:
A service having a "S*" file in the new runlevel is _defined_ in that runlevel and won't get signalled (TERM ... KILL) by init.
How init decides which processes are part of "service" (i.e. had been started by script residing in specific directory with S* in it name) and should be killed? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sat, 13 Apr 2013, Andrey Borzenkov wrote:
David Haller <dnh@opensuse.org> ?????:
A service having a "S*" file in the new runlevel is _defined_ in that runlevel and won't get signalled (TERM ... KILL) by init.
How init decides which processes are part of "service" (i.e. had been started by script residing in specific directory with S* in it name) and should be killed?
That's the job of the init-script. A script called 'foo' in /etc/init.d/ and symlinks S10foo/K90foo in /etc/init.d/rc3.d/ and rc5.d/ is started by init when changing to runlevels 3 and 5 with the parameter "start". When leaving the runlevels, the script /etc/init.d/foo is called with the parameter 'stop'. The script has to do the right thing in both cases (e.g. stop the processes it started, startproc/checkproc/killproc help doing that). When changing from runlevel 3 to 5 or 5 to 3, the script foo is _not_ called (neither with "stop" nor "start" as parameter), as the service "foo" is defined in both runlevels. -dnh --
This needs quotes: use lib "/path/to/perl/modules"; Single or double quotes? Yes. -- Tad McClellan in comp.lang.perl.misc -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sun, 14 Apr 2013 13:41:30 +0200 David Haller <dnh@opensuse.org> пишет:
Hello,
On Sat, 13 Apr 2013, Andrey Borzenkov wrote:
David Haller <dnh@opensuse.org> ?????:
A service having a "S*" file in the new runlevel is _defined_ in that runlevel and won't get signalled (TERM ... KILL) by init.
How init decides which processes are part of "service" (i.e. had been started by script residing in specific directory with S* in it name) and should be killed?
That's the job of the init-script.
So how can init send KILL signal to services that are not supposed to exist in current runlevel? Or better, how is it related to having or not having S* in file name?
A script called 'foo' in /etc/init.d/ and symlinks S10foo/K90foo in /etc/init.d/rc3.d/ and rc5.d/ is started by init when changing to runlevels 3 and 5 with the parameter "start". When leaving the runlevels, the script /etc/init.d/foo is called with the parameter 'stop'. The script has to do the right thing in both cases (e.g. stop the processes it started, startproc/checkproc/killproc help doing that).
When changing from runlevel 3 to 5 or 5 to 3, the script foo is _not_ called (neither with "stop" nor "start" as parameter), as the service "foo" is defined in both runlevels.
-dnh
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sun, 14 Apr 2013, Andrey Borzenkov wrote:
? Sun, 14 Apr 2013 13:41:30 +0200 David Haller <dnh@opensuse.org> ?????:
On Sat, 13 Apr 2013, Andrey Borzenkov wrote:
David Haller <dnh@opensuse.org> ?????:
A service having a "S*" file in the new runlevel is _defined_ in that runlevel and won't get signalled (TERM ... KILL) by init.
How init decides which processes are part of "service" (i.e. had been started by script residing in specific directory with S* in it name) and should be killed?
That's the job of the init-script.
So how can init send KILL signal to services that are not supposed to exist in current runlevel? Or better, how is it related to having or not having S* in file name?
It doesn't. That's not its job. It's job is to call the K-links with the argument "stop" that don't have a S-link script in the target runlevel. The scripts have to react accordingly to being called with the argument "stop". Just have a look at /etc/init.d/skeleton. -dnh -- "Don't put off 'till tomorrow, responsibilities. They'll just come back to haunt you. (Ignore them totally)" -- TISM -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Patrick Shanahan said the following on 04/12/2013 07:54 AM:
They have not *really* been "done away with", but have really changed considerably in ?definition?. Runlevel is/was a system state where certain capabilities are present such as (loosely) 5, the graphical state, and 3, multi-user/networking state. Now you have targets which have similar names and capabilities but are not numbered and represent a "dynamic" state where the deamons may not be active but will be called if necessary.
Indeed.
Realistically we only used runlevels 1, 3 and 5
That is: single use with networking turned off; multi-user with networking tuned on; graphical mode.
On linux, 'S' became useful -- it came up before the boot scripts were run. There are around 19 uniq (39 total) scripts in /etc/rc.d/boot.d.
We still have those, its just that we now have clearer names rather than numbers.
We now have long complicated to type and no auto-completion long names... If they were a menu, that would be 1 thing. They are not. They are something we have to type. Short is better. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-04-12 19:34 (GMT-0700) Linda Walsh composed:
Realistically we only used runlevels 1, 3 and 5
That is: single use with networking turned off; multi-user with networking tuned on; graphical mode.
On linux, 'S' became useful -- it came up before the boot scripts were run. There are around 19 uniq (39 total) scripts in /etc/rc.d/boot.d.
We still have those, its just that we now have clearer names rather than numbers.
We now have long complicated to type and no auto-completion long names...
As has been reiterated on this list today and less recently, single digits on kernel cmdline via aliasing of some sort still perform in 12.3 and Factory the same function as they did in 8.1 and 10.0, just as "init 3" in a shell is aliased to "systemctl isolate multi-user.target". Everything good about the old way has not yet been disposed of.
If they were a menu, that would be 1 thing. They are not. They are something we have to type. Short is better.
To a point. There can be times when short is too short. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata said the following on 04/12/2013 10:47 PM:
If they were a menu, that would be 1 thing. They are not. They are something we have to type. Short is better. To a point. There can be times when short is too short.
I'm reminded of my mother berating my teenage sister about her skirts. -- "Being professional is doing all the things you love to do on days when don't feel like doing them". -- Julius Erving. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-04-13 00:29 (GMT-0400) Anton Aylward composed:
Felix Miata composed:
If they were a menu, that would be 1 thing. They are not. They are something we have to type. Short is better.
To a point. There can be times when short is too short.
I'm reminded of my mother berating my teenage sister about her skirts.
LOL. My 62" short mother, trying reach anything on a kitchen cabinet's top shelf. What I had in mind typing previously was search boxes demanding more than two or three characters when I'm trying to find information about mc or something else impossible to make more than three characters long. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh said the following on 04/12/2013 10:34 PM:
Anton Aylward wrote:
Patrick Shanahan said the following on 04/12/2013 07:54 AM:
They have not *really* been "done away with", but have really changed considerably in ?definition?. Runlevel is/was a system state where certain capabilities are present such as (loosely) 5, the graphical state, and 3, multi-user/networking state. Now you have targets which have similar names and capabilities but are not numbered and represent a "dynamic" state where the deamons may not be active but will be called if necessary.
Indeed.
Realistically we only used runlevels 1, 3 and 5
That is: single use with networking turned off; multi-user with networking tuned on; graphical mode.
On linux, 'S' became useful -- it came up before the boot scripts were run. There are around 19 uniq (39 total) scripts in /etc/rc.d/boot.d.
And how was it useful? What are you doing with it? How did you get there? Are you saying that with systemd there is nothing that can be put on the boot command line to achieve the same end? I hope that's not what you're saying, I hope you're only saying that you are unaware of such and I hope that you are going to be asking what that would be and if there is a short form.
We still have those, its just that we now have clearer names rather than numbers.
We now have long complicated to type and no auto-completion long names...
No not HAVE TO but CAN CHOSE TO. You can still put 1, 3, 5 on the command line. Please stop asserting misinformation.
If they were a menu, that would be 1 thing. They are not. They are something we have to type. Short is better.
No, short is not always better. That's a stupid myth. Linda, you're the one that always goes on about the merits of LILO. Surely its in your ability to add the lines to LILO to give that menu offering the other boot options? -- "Intolerance of ambiguity is the mark of an authoritarian personality." - Theodor W. Adorno -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/04/13 21:54, Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [04-12-13 01:02]: [...]
Why were the runlevels done away with anyway? For what illogical reason? They have not *really* been "done away with", but have really changed considerably in ?definition?. Runlevel is/was a system state where certain capabilities are present such as (loosely) 5, the graphical state, and 3, multi-user/networking state. Now you have targets which have similar names and capabilities but are not numbered and represent a "dynamic" state where the deamons may not be active but will be called if necessary.
Think of it like having a pantry stocked for daily needs and the same pantry stocked for a family get-together, runlevel 3/5, vs a minimally stocked pantry but ready access to needed items for either level from a grocery next door.
This may not be accurate but that is what I understand from list conversation.
Previous, you could not apply a different system graphics driver while the present driver what used, runlevel 5, but dropping to a text mode, runlevel 3, you could. Now by leaving the "graphics target" you accomplish the same and are able to install a different graphics driver.
I believe it is called "progress" :^)
OK, this is fine with me - provided I am made aware of what that new state of awareness is and how I can enter it where I can compile the nVidia driver without any hassles (and without reaching that state using wacky-tobacky). Right now I know that I can this by entering runlevel 3 - but what will i need to do in the near future to do the same? BC -- Using openSUSE 12.3 x86_64 KDE 4.10.2 & kernel 3.8.6-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-04-12 22:46 (GMT+1000) Basil Chupin composed:
OK, this is fine with me - provided I am made aware of what that new state of awareness is and how I can enter it where I can compile the nVidia driver without any hassles (and without reaching that state using wacky-tobacky).
Right now I know that I can this by entering runlevel 3 - but what will i need to do in the near future to do the same?
init 3 remains an alias to achieve the equivalent systemd state/level that requires about 6X as much typing using the native systemd command system to turn off the graphical target. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
init 3 remains an alias to achieve the equivalent systemd state/level that requires about 6X as much typing using the native systemd command system to turn off the graphical target.
Pardon? "init 3" is ... 6 characters. What is the native systemd command that does this in 2? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Basil Chupin <blchupin@iinet.net.au> [04-12-13 08:49]: [...]
OK, this is fine with me - provided I am made aware of what that new state of awareness is and how I can enter it where I can compile the nVidia driver without any hassles (and without reaching that state using wacky-tobacky).
Right now I know that I can this by entering runlevel 3 - but what will i need to do in the near future to do the same?
from perusing the man files for systemd and relatives, I believe the command analogous to "init 3" is: systemctl isolate multi-user.target -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan said the following on 04/12/2013 10:29 AM:
* Basil Chupin <blchupin@iinet.net.au> [04-12-13 08:49]: [...]
OK, this is fine with me - provided I am made aware of what that new state of awareness is and how I can enter it where I can compile the nVidia driver without any hassles (and without reaching that state using wacky-tobacky).
Right now I know that I can this by entering runlevel 3 - but what will i need to do in the near future to do the same?
from perusing the man files for systemd and relatives, I believe the command analogous to "init 3" is: systemctl isolate multi-user.target
True, but then you can also type init 3 and that would work too. -- It is therefore not unreasonable to suppose that some portion of the neglect of science in England, may be attributed to the system of education we pursue. -- Charles Babbage -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2013 10:29 AM, Patrick Shanahan pecked at the keyboard and wrote:
* Basil Chupin <blchupin@iinet.net.au> [04-12-13 08:49]: [...]
OK, this is fine with me - provided I am made aware of what that new state of awareness is and how I can enter it where I can compile the nVidia driver without any hassles (and without reaching that state using wacky-tobacky).
Right now I know that I can this by entering runlevel 3 - but what will i need to do in the near future to do the same?
from perusing the man files for systemd and relatives, I believe the command analogous to "init 3" is: systemctl isolate multi-user.target
Just create an alias in your .alias file: alias init3='systemctl isolate multi-user.target' and be done with it. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/04/13 00:29, Patrick Shanahan wrote:
* Basil Chupin <blchupin@iinet.net.au> [04-12-13 08:49]: [...]
OK, this is fine with me - provided I am made aware of what that new state of awareness is and how I can enter it where I can compile the nVidia driver without any hassles (and without reaching that state using wacky-tobacky).
Right now I know that I can this by entering runlevel 3 - but what will i need to do in the near future to do the same? from perusing the man files for systemd and relatives, I believe the command analogous to "init 3" is: systemctl isolate multi-user.target
And this is supposed to be an improvement over "init 3" or even "3"?! Heaven help us........ BC -- Using openSUSE 12.3 x86_64 KDE 4.10.2 & kernel 3.8.6-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 13 Apr 2013 15:30:08 +1000 Basil Chupin <blchupin@iinet.net.au> wrote:
command analogous to "init 3" is: systemctl isolate multi-user.target
And this is supposed to be an improvement over "init 3" or even "3"?!
You have both that is now linked to multi-user.target, but one day when you wake up with knowledge of systemd and start creating targets then you'll appreciate wisdom of systemd creators to offer natural language instead of numerical encoding with limited number of targets.
Heaven help us........
It already helped :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/13/2013 7:38 PM, Rajko wrote:
Heaven help us........
It already helped :) Are you sure it wasn't the other place that helped with this one? :-)
Damon Register -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/04/13 08:54, Patrick Shanahan escribió:
* Basil Chupin <blchupin@iinet.net.au> [04-12-13 01:02]: [...]
Why were the runlevels done away with anyway? For what illogical reason?
They have not *really* been "done away with", but have really changed considerably in ?definition?.
Runlevels are implemented in a minimal fashion, minimal enough to simulate 1, 3 and 5, nothing else.
This may not be accurate but that is what I understand from list conversation.
Yes, your analogy holds pretty well.
I believe it is called "progress" :^)
More around the lines of the result of hardware and usage patterns change since the inception of hotplugging cpu/disks/sound/RAM/etc devices. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan wrote:
Previous, you could not apply a different system graphics driver while the present driver what used, runlevel 5, but dropping to a text mode, runlevel 3, you could. Now by leaving the "graphics target" you accomplish the same and are able to install a different graphics driver. I believe it is called "progress" :^)
--- Having to type "systemd.unit=multi-user.target" on a kernel boot line instead of "3" is not progress -- especially when the new invocation is unstable and is not a standard. Runlevels were "1 key", and reasonably well understood -- now, I'd have to have a systemd reference to look up how to do it... Unfortunately, when the system is down, how do I do that again? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 12 Apr 2013 19:26:40 -0700 Linda Walsh <suse@tlinx.org> wrote:
Having to type "systemd.unit=multi-user.target" on a kernel boot line instead of "3" is not progress
You don't have to type 29 characters, just 1 as "3" works fine as it did before. The same is valid for "init 1" (3 and 5) when needed. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh said the following on 04/12/2013 10:26 PM:
Having to type "systemd.unit=multi-user.target" on a kernel boot line instead of "3" is not progress
You're right, its not. That's why you don't have to. You chose to use the misleading word "HAVING" there, Linda. You should have written Choosing to type "systemd.unit=multi-user.target" on a kernel boot line instead of "3" is long winded even though it does make clear what is happening, so its a good thing one can still simply type "3". Please stop asserting misinformation -- There is nothing wrong with America that the faith, love of freedom, intelligence and energy of her citizens cannot cure. -- Dwight D. Eisenhower -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Linda Walsh said the following on 04/12/2013 10:26 PM:
Having to type "systemd.unit=multi-user.target" on a kernel boot line instead of "3" is not progress
You're right, its not. That's why you don't have to.
You chose to use the misleading word "HAVING" there, Linda. You should have written
Choosing to type "systemd.unit=multi-user.target" on a kernel boot line instead of "3" is long winded even though it does make clear what is happening, so its a good thing one can still simply type "3".
Please stop asserting misinformation
I didn't assert it. I claimed it and I still do. Having to type systemd.unit=mult-user.target isn't progress over typing "3". The run levels are now called "compatibility features". That implies they aren't permanent. I.e. the plan is to do away with them. But this is precious: "even though it does make clear what is happening" -- CLEAR to WHO??? you are in Single User. Your system isn't booted. Who is it clear to? It isn't more clear to me, since I don't know what systemd.unit = multi-user-target defines as its state. I have an idea what runlevel 3 is by looking in my rc3.d rundir. So where do I list the same scripts from systemd? /usr/lib/systemd/system/multi-user.target? Nope: That's: Requires=basic.target Conflicts=rescue.service rescue.target After=basic.target rescue.service rescue.target (and other stuff). Maybe in the dir: Ishtar:/usr/../system/multi-user.target.wants# ls dbus.service@ systemd-ask-password-wall.path@ systemd-user-sessions.service@ getty.target@ systemd-logind.service@ ---- Um... so compare to /etc/rc.d/rc3.d/S*|wc = 57... So... hmm... 57 services vs. 5. What's wrong with this picture. Where's the clarity? The simplicity? Where's all the services? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Fri, 12 Apr 2013 21:50:36 -0700 Linda Walsh <suse@tlinx.org> пишет:
It isn't more clear to me, since I don't know what systemd.unit = multi-user-target defines as its state. I have an idea what runlevel 3 is by looking in my rc3.d rundir. So where do I list the same scripts from systemd?
Upstream added "systemctl list-dependencies" recently. The patch while not one-liner is self-contained and does not touch core, only systemctl itself. There are good chances maintainer will agree to accept backport. You know how to use OBS and bugzilla, do not you? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sat, 13 Apr 2013 09:10:30 +0400 Andrey Borzenkov <arvidjaar@gmail.com> пишет:
В Fri, 12 Apr 2013 21:50:36 -0700 Linda Walsh <suse@tlinx.org> пишет:
It isn't more clear to me, since I don't know what systemd.unit = multi-user-target defines as its state. I have an idea what runlevel 3 is by looking in my rc3.d rundir. So where do I list the same scripts from systemd?
Upstream added "systemctl list-dependencies" recently. The patch while not one-liner is self-contained and does not touch core, only systemctl itself. There are good chances maintainer will agree to accept backport. You know how to use OBS and bugzilla, do not you?
Something like this. bor@opensuse:~/src/systemd> ./systemctl --full --no-pager list-dependencies default.target ├─cpufreq.service ├─cups.service ├─fbset.service ├─haveged.service ├─ntp.service ├─purge-kernels.service ├─sshd.service ├─systemd-readahead-collect.service ├─systemd-readahead-replay.service ├─systemd-update-utmp-runlevel.service ├─xdm.service ├─xinetd.service ├─YaST2-Firstboot.service ├─YaST2-Second-Stage.service └─multi-user.target ├─acpid.service ├─avahi-daemon.service ├─cpufreq.service ├─cron.service ├─cups.service ├─dbus.service ├─fbset.service ├─haveged.service ├─libvirtd.service ├─NetworkManager.service ├─ntp.service ├─plymouth-quit-wait.service ├─plymouth-quit.service ├─purge-kernels.service ├─rc-local.service ├─rsyslog.service ├─sshd.service ├─systemd-ask-password-wall.path ├─systemd-logind.service ├─systemd-update-utmp-runlevel.service ├─systemd-user-sessions.service ├─xinetd.service ├─basic.target │ ├─alsa-restore.service │ ├─console-kit-log-system-start.service │ ├─systemd-tmpfiles-clean.timer │ ├─systemd-udev-root-symlink.service │ ├─sockets.target │ │ ├─avahi-daemon.socket │ │ ├─dbus.socket │ │ ├─pcscd.socket │ │ ├─systemd-initctl.socket │ │ ├─systemd-journald.socket │ │ ├─systemd-shutdownd.socket │ │ ├─systemd-udevd-control.socket │ │ └─systemd-udevd-kernel.socket │ └─sysinit.target │ ├─cycle.service │ ├─dev-hugepages.mount │ ├─dev-mqueue.mount │ ├─lvm.service │ ├─plymouth-read-write.service │ ├─plymouth-start.service │ ├─proc-sys-fs-binfmt_misc.automount │ ├─sys-fs-fuse-connections.mount │ ├─sys-kernel-config.mount │ ├─sys-kernel-debug.mount │ ├─systemd-ask-password-console.path │ ├─systemd-binfmt.service │ ├─systemd-journal-flush.service │ ├─systemd-journald.service │ ├─systemd-modules-load.service │ ├─systemd-random-seed-load.service │ ├─systemd-sysctl.service │ ├─systemd-tmpfiles-setup.service │ ├─systemd-udev-trigger.service │ ├─systemd-udevd.service │ ├─systemd-vconsole-setup.service │ ├─cryptsetup.target │ ├─local-fs.target │ │ ├─-.mount │ │ ├─boot.mount │ │ ├─datastore.mount │ │ ├─home.mount │ │ ├─systemd-fsck-root.service │ │ ├─systemd-remount-fs.service │ │ ├─var-lock.mount │ │ ├─var-run.mount │ │ └─remote-fs-pre.target │ │ └─... │ └─swap.target │ └─dev-system-swap.swap ├─getty.target │ └─getty@tty1.service └─remote-fs.target └─remote-fs-pre.target └─local-fs.target ├─-.mount ├─boot.mount ├─datastore.mount ├─home.mount ├─systemd-fsck-root.service ├─systemd-remount-fs.service ├─var-lock.mount ├─var-run.mount └─... bor@opensuse:~/src/systemd> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
В Sat, 13 Apr 2013 09:10:30 +0400 Andrey Borzenkov <arvidjaar@gmail.com> пишет:
В Fri, 12 Apr 2013 21:50:36 -0700 Linda Walsh <suse@tlinx.org> пишет:
It isn't more clear to me, since I don't know what systemd.unit = multi-user-target defines as its state. I have an idea what runlevel 3 is by looking in my rc3.d rundir. So where do I list the same scripts from systemd?
Upstream added "systemctl list-dependencies" recently. The patch while not one-liner is self-contained and does not touch core, only systemctl itself. There are good chances maintainer will agree to accept backport. You know how to use OBS and bugzilla, do not you?
Something like this.
bor@opensuse:~/src/systemd> ./systemctl --full --no-pager list-dependencies
So you've replace "ls " with a specialized and unique command; Now I want to find out what's in each of those and find out why something is not working (or working the way it is). Um. ok, .. (1st minor nit: /usr/lib/systemd/system: icky vs. /etc/rc.d, short - for those with typing difficulties), then cat /etc/sshd.config .... [optional_subsection] "reserved_dictionary_word"=unknown ... The optional sections, and reserved dictionary are a unique and new language -- they aren't Shell, but a whole bunch of new options to learn and configure. They are not as standard as unix shell core utils, They are not POSIX (which is often annoying, so I'm not crying, but it was _a_ lowest common denominator!), it's not any known language, it's not portable, ... and it's not any where near as flexible as a shell script. After a bit of wrangling** we find: /bin: bash dbus-daemon echo plymouth rm sh systemctl true /etc/init.d: boot.local halt.local /sbin: agetty klogd purge-kernels rpcbind sulogin /usr/bin: plymouth systemctl udevadm /usr/lib/YaST2/bin: autoyast-initscripts.sh /usr/lib/YaST2/startup: YaST2.Firstboot YaST2.Second-Stage /usr/lib: colord /usr/lib/polkit-1: polkitd /usr/lib/udev: write_dev_root_rule /usr/lib/udisks2: udisksd /usr/lib/upower: upowerd /usr/lib64/libvirt: libvirt-guests.sh /usr/sbin: acpid atd atheme-services automount avahi-daemon avahi-dnsconfd cron dovecot nginx nscd quotaon rsyncd sshd sshd-gen-keys-start syslogd syslogd-service-prepare tomcat-jsvc-sysd tomcat-sysd Of which 1/3 are shell scripts. (Exercise for the reader to run 'file' on the above files). And this is far from a fully installed systemd system. and doesn't list the 30 some-odd calls to systemd-included binaries. You call this easier or simpler? Faster to execute -- yes, easier to understand, maintain, develop-for -- certainly not to anyone who knows shell. Maybe after it's been around and become a standard for 'N years', but doesn't look alot like shell scripts that have run the OS (including 1970's shell scripts for unix) for the past 40+ years. But you know, this is all really a red-herring to me. I want basic boot-from-disk functionality back. The fact that it CAN'T do that is the most serious and crippling limitation in my mind. The fact that 'S' isn't "before anything runs -- but is dependent on some 'systemd' "target" only **EMPHASIZES** the problem. The idea of 'S' was to get in before the *control* service started (as an example). You've lost the ability to break things down. Because of that you have to require a ram-disk to bundle all the "/etc/init.d/boot.d" operations onto the ramdisk. The requirements of this solution are onerous and debilitating. The only thoughts about maintaining backwards compatibility have been about denying it is supported or sabotaging it (by moving everything to /usr). ** - for the curious: the wrangling... not entirely trivial... Ishtar:/usr/lib/systemd/system> more /tmp/wrang #!/bin/bash grep ExecStart * 2>/dev/null |cut -d= -f2 |cut -d\ -f1|sed 's/^-//' | grep -v systemd| while read fn;do file -L --mime-type "$fn" done|cut -f1 -d: |sort|uniq|( dir="" fl="" while read serv;do d=$(dirname "$serv") b=$(basename "$serv") if [[ $d != $dir ]]; then printf "\n%25s: " "$d" ;fi dir=$d echo -n " $b" done ) echo -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sat, 13 Apr 2013 00:04:26 -0700 Linda Walsh <suse@tlinx.org> пишет:
You call this easier or simpler?
I answered your question how to find what is "included" in multi-user.target. I'm not going to argue with you about anything or call names. If I misunderstood you and it was not a question - I apologize for miscommunication. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
В Sat, 13 Apr 2013 00:04:26 -0700 Linda Walsh <suse@tlinx.org> пишет:
You call this easier or simpler?
I answered your question how to find what is "included" in multi-user.target. I'm not going to argue with you about anything or call names.
It was a question but also chance to contrast how easy systemd is to use compared to sysVinit. As for calling names? Jane? Joe? Sam? What names were you not going to call? I'm not sure how enter into the picture? I looked over my writing to see if there was anything that might have provoked such a response. Sincerely, I am clueless. I don't see any name calling hinted at, so how did that come up? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh said the following on 04/13/2013 03:04 AM:
So you've replace "ls " with a specialized and unique command; Now I want to find out what's in each of those and find out why something is not working (or working the way it is). Um.
Yes you can. Systemic does all that. RTFM OBTW: 'ls' doesn't tell you what's in files, doesn't tell you if they have been run, doesn't tell you whether running them succeeded or not, doesn't tell you what a file depends on. -- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. --Bertrand Russell -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh said the following on 04/13/2013 03:04 AM:
Faster to execute -- yes, easier to understand, maintain, develop-for -- certainly not to anyone who knows shell. Maybe after it's been around and become a standard for 'N years', but doesn't look alot like shell scripts that have run the OS (including 1970's shell scripts for unix) for the past 40+ years.
So long as you have this hang-up about scripts you will never grok systemd. And as someone who has been using UNIX for nearly 40 years ... You obviously don't understand why the shell was used for so many functions in the first place, just as you don't seem to understand why /usr/bin and /usr/lib were introduced in the first place. And yes, Linda, I understand shell, and more to the point I fond systemd easier to understand than the ad-hoc mess that is the collection of start-up scripts ... I recall whey System V came out and the detested UNIX Systems Group introduced the 'runlevels' and shoe-horned all those scripts into place and forced on us the - as we called it at the time - straight-jacket of the protocols and confinement that went with them. Other systems - BSD, Solaris, said "No Way!" and stuck with their own approach. Then there was SCO ... Coherent ... Oh, and then was also IBM's AIX and the VRM and HP's HP/UX that didn't look like anything else and refused to tie its revisions in with anyone else and refused to use a RS-232 standard (e.g.for serial consoles) that was like anyone else. So don't try and make out that everything was hunky-dory and coherent and sensible for the last "40+" years before systemd. -- Try to learn something about everything and everything about something. Thomas H. Huxley -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh said the following on 04/13/2013 03:04 AM:
After a bit of wrangling** we find:
/bin: bash dbus-daemon echo plymouth rm sh systemctl true /etc/init.d: boot.local halt.local /sbin: agetty klogd purge-kernels rpcbind sulogin /usr/bin: plymouth systemctl udevadm /usr/lib/YaST2/bin: autoyast-initscripts.sh /usr/lib/YaST2/startup: YaST2.Firstboot YaST2.Second-Stage /usr/lib: colord /usr/lib/polkit-1: polkitd /usr/lib/udev: write_dev_root_rule /usr/lib/udisks2: udisksd /usr/lib/upower: upowerd /usr/lib64/libvirt: libvirt-guests.sh /usr/sbin: acpid atd atheme-services automount avahi-daemon avahi-dnsconfd cron dovecot nginx nscd quotaon rsyncd sshd sshd-gen-keys-start syslogd syslogd-service-prepare tomcat-jsvc-sysd tomcat-sysd
Of which 1/3 are shell scripts. (Exercise for the reader to run 'file' on the above files).
What are you trying to say here, Linda, that systemd does use shell scripts? That systemd start up daemons? I think you're missing the point. On a number of accounts. /etc/init.d/{boot,halt}.local are scripts, yes but so? There's nothing in them except comment lines ... UNLESS THE USER CUSTOMIZES And if you want to say that systemd is deficient because the user/sysadmin has arbitrarily customized things, and that systemd will respect this, then I don't think you have a valid argument. You also haven't explained why you ran this on /usr/lib/systemd rather than /etc/systemd. There's a lot in that library that isn't subsequently used or used at all. YaST2-Firstboot.service, for example. Then there's stuff specific to laptops ... I keep saying 'Context is Everything'. All you've done here is throw out that systemd executes things. That's no basis for claiming that "its no better ..." -- The most important fundamental laws and facts of physical science have all been discovered, and these are now so firmly established that the possibility of their ever being supplemented in consequence of new discoveries is exceedingly remote. (1903) -- Albert Abraham Michelson (1852-1931) Quoted by Peter Coveney and Roger Highfield in 'The Arrow of Time', Flamingo, London 1991, p 67. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh said the following on 04/13/2013 03:04 AM:
cat /etc/sshd.config .... [optional_subsection] "reserved_dictionary_word"=unknown ... The optional sections, and reserved dictionary are a unique and new language -- they aren't Shell, but a whole bunch of new options to learn and configure. They are not as standard as unix shell core utils, They are not POSIX (which is often annoying, so I'm not crying, but it was _a_ lowest common denominator!), it's not any known language, it's not portable, ... and it's not any where near as flexible as a shell script.
What's the point of this? Are you going to damn the XML coded config files as well? What about the config files firefox uses? What about JSON files? Sorry, I don't buy into this, Linda. You're throwing out red herrings. You might as well complain about X and the config files it uses or the KDM/XDM config files. All those aren't shell scripts and "aren't portable" in that they are specific to the application. Big Deal. And nothing to do with systemd. -- Ninety percent of the politicians give the other ten percent a bad reputation. -- Henry Kissinger -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
And nothing to do with systemd.
How initrd starts the system has nothing to with systemd, I agree: Besides the existing files in /lib, /bin the initrd includes all of these files from /usr: /usr /usr/lib64 /usr/lib64/libsplashycnf.so.1.0.0 /usr/lib64/libsplashycnf.so.1 /usr/lib64/libglib-2.0.so.0.3400.3 /usr/lib64/libglib-2.0.so.0 /usr/lib64/libdirectfb-1.4.so.5.0.0 /usr/lib64/libdirectfb-1.4.so.5 /usr/lib64/libkmod.so.2.2.2 /usr/lib64/libkmod.so.2 /usr/lib64/libext2fs.so.2.4 /usr/lib64/libext2fs.so.2 /usr/lib64/libcom_err.so.2.1 /usr/lib64/libcom_err.so.2 /usr/lib /usr/lib/systemd /usr/lib/udev /usr/lib/udev/write_net_rules /usr/lib/udev/write_cd_rules /usr/lib/udev/v4l_id /usr/lib/udev/usb_modeswitch /usr/lib/udev/usb_id /usr/lib/udev/usb-db /usr/lib/udev/udisks-probe-sas-expander /usr/lib/udev/udisks-probe-ata-smart /usr/lib/udev/udisks-part-id /usr/lib/udev/udisks-dm-export /usr/lib/udev/udevmountd /usr/lib/udev/udev-configure-printer /usr/lib/udev/udev-add-printer /usr/lib/udev/udev-acl /usr/lib/udev/scsi_id /usr/lib/udev/rule_generator.functions /usr/lib/udev/pci-db /usr/lib/udev/path_id /usr/lib/udev/mtd_probe /usr/lib/udev/libz.so.1.2.5 /usr/lib/udev/libz.so.1 /usr/lib/udev/libutil.so.1 /usr/lib/udev/libutil-2.9.so /usr/lib/udev/libutil-2.15.so /usr/lib/udev/libudev.so.0.12.0 /usr/lib/udev/libudev.so.0 /usr/lib/udev/libthread_db.so.1 /usr/lib/udev/libthread_db-1.0.so /usr/lib/udev/libsepol.so.1 /usr/lib/udev/libselinux.so.1 /usr/lib/udev/librt.so.1 /usr/lib/udev/librt-2.9.so /usr/lib/udev/librt-2.15.so /usr/lib/udev/libresolv.so.2 /usr/lib/udev/libresolv-2.9.so /usr/lib/udev/libresolv-2.15.so /usr/lib/udev/libpthread.so.0 /usr/lib/udev/libpthread-2.9.so /usr/lib/udev/libpthread-2.15.so /usr/lib/udev/libpcprofile.so /usr/lib/udev/libnss_nisplus.so.2 /usr/lib/udev/libnss_nisplus-2.9.so /usr/lib/udev/libnss_nisplus-2.15.so /usr/lib/udev/libnss_nis.so.2 /usr/lib/udev/libnss_nis-2.9.so /usr/lib/udev/libnss_nis-2.15.so /usr/lib/udev/libnss_hesiod.so.2 /usr/lib/udev/libnss_hesiod-2.9.so /usr/lib/udev/libnss_hesiod-2.15.so /usr/lib/udev/libnss_files.so.2 /usr/lib/udev/libnss_files-2.9.so /usr/lib/udev/libnss_files-2.15.so /usr/lib/udev/libnss_dns.so.2 /usr/lib/udev/libnss_dns-2.9.so /usr/lib/udev/libnss_dns-2.15.so /usr/lib/udev/libnss_db.so.2 /usr/lib/udev/libnss_db-2.15.so /usr/lib/udev/libnss_compat.so.2 /usr/lib/udev/libnss_compat-2.9.so /usr/lib/udev/libnss_compat-2.15.so /usr/lib/udev/libnsl.so.1 /usr/lib/udev/libnsl-2.9.so /usr/lib/udev/libnsl-2.15.so /usr/lib/udev/libncursesw.so.5.8 /usr/lib/udev/libncursesw.so.5 /usr/lib/udev/libncurses.so.5.8 /usr/lib/udev/libncurses.so.5.6 /usr/lib/udev/libncurses.so.5 /usr/lib/udev/libmemusage.so /usr/lib/udev/libm.so.6 /usr/lib/udev/libm-2.9.so /usr/lib/udev/libm-2.15.so /usr/lib/udev/liblzma.so.5.0.3 /usr/lib/udev/liblzma.so.5 /usr/lib/udev/libgcc_s.so.1 /usr/lib/udev/libdl.so.2 /usr/lib/udev/libdl-2.9.so /usr/lib/udev/libdl-2.15.so /usr/lib/udev/libdevmapper.so.1.02 /usr/lib/udev/libdevmapper-event.so.1.02 /usr/lib/udev/libcrypt.so.1 /usr/lib/udev/libcrypt-2.9.so /usr/lib/udev/libcrypt-2.15.so /usr/lib/udev/libcidn.so.1 /usr/lib/udev/libcidn-2.9.so /usr/lib/udev/libcidn-2.15.so /usr/lib/udev/libc.so.6 /usr/lib/udev/libc-2.9.so /usr/lib/udev/libc-2.15.so /usr/lib/udev/libanl.so.1 /usr/lib/udev/libanl-2.9.so /usr/lib/udev/libanl-2.15.so /usr/lib/udev/libaio.so.1.0.1 /usr/lib/udev/libaio.so.1 /usr/lib/udev/libSegFault.so /usr/lib/udev/libBrokenLocale.so.1 /usr/lib/udev/libBrokenLocale-2.9.so /usr/lib/udev/libBrokenLocale-2.15.so /usr/lib/udev/ld-linux.so.2 /usr/lib/udev/ld-2.9.so /usr/lib/udev/ld-2.15.so /usr/lib/udev/kpartx_id /usr/lib/udev/keymap /usr/lib/udev/keyboard-force-release.sh /usr/lib/udev/iwlwifi-led.sh /usr/lib/udev/isdn.sh /usr/lib/udev/input_id /usr/lib/udev/idedma.sh /usr/lib/udev/hid2hci /usr/lib/udev/gpsd.sh /usr/lib/udev/firmware /usr/lib/udev/findkeyboards /usr/lib/udev/create_floppy_devices /usr/lib/udev/cpp /usr/lib/udev/collect_lvm /usr/lib/udev/collect /usr/lib/udev/cdrom_id /usr/lib/udev/bluetooth_serial /usr/lib/udev/bluetooth.sh /usr/lib/udev/ata_id /usr/lib/udev/accelerometer /usr/lib/udev/write_dev_root_rule /usr/lib/udev/numlock-on /usr/lib/udev/rules.d /usr/lib/udev/rules.d/77-network.rules /usr/lib/udev/rules.d/95-dm-notify.rules /usr/lib/udev/rules.d/13-dm-disk.rules /usr/lib/udev/rules.d/10-dm.rules /usr/lib/udev/rules.d/80-drivers.rules /usr/lib/udev/rules.d/64-md-raid.rules /usr/lib/udev/rules.d/60-persistent-input.rules /usr/lib/udev/rules.d/60-persistent-storage.rules /usr/lib/udev/rules.d/50-firmware.rules /usr/lib/udev/rules.d/50-udev-default.rules /usr/share /usr/share/zoneinfo /usr/share/zoneinfo/UTC /usr/share/splashy /usr/share/splashy/themes /usr/share/splashy/themes/default /usr/share/splashy/themes/default/theme.xml /usr/share/splashy/themes/default/suspend.png /usr/share/splashy/themes/default/error.png /usr/share/splashy/themes/default/background.png /usr/share/splashy/themes/default/FreeSans.ttf ^^^^^^^^^^^^^^^^^^^^^^^^^^ /usr/share /usr/sbin /usr/sbin/fsck /usr/sbin/blkid /usr/sbin/ip /usr/bin /usr/bin/umount /usr/bin/sleep /usr/bin/mount /usr/bin/chroot /usr/bin/rm /usr/bin/mv /usr/bin/ls /usr/bin/dmesg /usr/bin/cp /usr/bin/chmod /usr/bin/ln /usr/bin/mknod /usr/bin/udevadm /usr/bin/sed /usr/bin/on_ac_power /usr/bin/mkdir /usr/bin/cat /usr/bin/uname /usr/bin/date And all the sysVinit boot scripts: /boot /boot/93-boot.sh /boot/92-killblogd2.sh /boot/91-shell.sh /boot/91-mtab.sh /boot/91-killudev.sh /boot/91-killblogd.sh /boot/91-createfb.sh /boot/84-remount.sh /boot/83-mount.sh /boot/82-resume.kernel.sh /boot/81-resume.userspace.sh /boot/81-btrfs.sh /boot/21-devinit_done.sh /boot/11-usb.sh /boot/11-block.sh /boot/06-blogd.sh /boot/05-kms.sh /boot/05-clock.sh /boot/04-udev.sh /boot/03-storage.sh /boot/03-rtc.sh /boot/02-start.sh /boot/01-devfunctions.sh /boot/01-acpi.sh /init ------------------- So Why can't that be on root? -------------- /etc/sysconfig/network (all the contents)... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/12/2013 10:10 PM, Andrey Borzenkov wrote:
В Fri, 12 Apr 2013 21:50:g36 -0700 Linda Walsh <suse@tlinx.org> пишет:
It isn't more clear to me, since I don't know what systemd.unit = multi-user-target defines as its state. I have an idea what runlevel 3 is by looking in my rc3.d rundir. So where do I list the same scripts from systemd?
Upstream added "systemctl list-dependencies" recently. The patch while not one-liner is self-contained and does not touch core, only systemctl itself. There are good chances maintainer will agree to accept backport. You know how to use OBS and bugziglla, do not you?
Actually, I think you've all made it pretty clear you care for no opinion but your own. There have been numerous presentations of the shortcomings of the decisions you've forced on those who choose to use OpenSUSE. The choices are even if well intentioned, poorly thought out and executed, if verbosely described. The documentation is even worse, which was tolerable when there was a common basis of understanding of principals. I think it may well be time to fork OpenSUSE, take what we think is good and discard the garbage you've forced in; Making it a cross between the worst of Windows, OS X and VMS. And OBS is the key to that fork. It's gonna be a ton of work to do, but to get shut of your arrogance... It's well worth it. Let's face it, Patrick Volkerding nearly singlehandly keeps Slackware alive. I suspect there are enough of us who would prefer and up to date distribution without the garbage and attitude. Linda, you've very eloquently, and carefully explained what's wrong with the approach. Much better than I could. Thank you. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 13/04/13 02:29, Bruce Ferrell escribió: There have been numerous presentations of the
shortcomings of the decisions you've forced on those who choose to use OpenSUSE.
All of them are absolute bullshit, arguments from ignorance. The choices are even if well intentioned, poorly thought out
and executed, if verbosely described.
Software has bugs, deal with it. The documentation is even worse,
which was tolerable when there was a common basis of understanding of principals.
The systemd documentation is long enough to fill TWO TOMES (it has been printed and that was the result)
I think it may well be time to fork OpenSUSE.
Or much more simple, you could stop whinning and use something else. like a BSD or a debian variant. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh said the following on 04/13/2013 12:50 AM:
But this is precious: "even though it does make clear what is happening" -- CLEAR to WHO??? you are in Single User. Your system isn't booted. Who is it clear to?
It isn't more clear to me, since I don't know what systemd.unit = multi-user-target defines as its state. I have an idea what runlevel 3 is by looking in my rc3.d rundir. So where do I list the same scripts from systemd?
Its quite clear that you "Don't Get It". Because you talk of scripts. You won't let go of the concepts associated with sysvinit and so berate systemd for not being like sysvinit. THERE ARE NOT SCRIPTS WITH SYSTEMD Systemd does not need the shell therefore it doesn't use scripts. So its pointless to ask about lists. And it is pointless to criticise systemd in terms of sysvinit. I'd venture that "3" wasn't a state, which is why it was called a run-level, but that's being picky... The systemd tools such as systemctl will tell you more about the state - what has run and what has failed. And why. It will also tell you what has run to completion - something you can't see with sysvinit since there are no tools other than, hopefully, the system log, if the programmer was sensible enough to use logging. And as I've pointed out, with systemd you can view the dependency tree associated with a target. Dependency is an important concept with systemd and one completely absent sysvinit. -- Everything that is really great and inspiring is created by the individual who can labor in freedom. -- Albert Einstein, in H. Eves Return to Mathematical Circles, Boston: Prindle, Weber and Schmidt, 1988. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-04-11 13:18 (GMT-0400) Patrick Shanahan composed: ...
Bruce Ferrell composed:
Booting from install media puts my Dell XPS 1730 (aka Dell MXG071) w/Nvidia GeForce 8700M GT into display test mode (pretty colors on the LCD but not very compute useful), unless I use failsafe mode... And after install all I have is x11failsafe and a VERY slow system.
Systemd doesn't seem to allow me to switch to what used to be runlevel 3 (does such a thing still exist in a port systemd world?) to even begin to troubleshoot.
Add 3 to kernel command line.
and *probably*: nomodeset
To a 12.3/nouveau user, is there any practical difference between x11failsafe and nomodeset? Disabled KMS, aka Xorg running on VESA, is probably why Bruce's system is "VERY slow". -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 11 April 2013 07:18:17 am Patrick Shanahan wrote:
* Cristian Rodríguez <crrodriguez@opensuse.org> [04-11-13 13:14]:
El 11/04/13 13:51, Andrey Borzenkov escribió:
В Thu, 11 Apr 2013 09:45:29 -0700
Bruce Ferrell <bferrell@baywinds.org> пишет:
OK gang,
I get it new and shiny is kool. This, however, is ridiculous.
Booting from install media puts my Dell XPS 1730 (aka Dell MXG071) w/Nvidia GeForce 8700M GT into display test mode (pretty colors on the LCD but not very compute useful), unless I use failsafe mode... And after install all I have is x11failsafe and a VERY slow system.
Systemd doesn't seem to allow me to switch to what used to be runlevel 3 (does such a thing still exist in a port systemd world?) to even begin to troubleshoot.
Add 3 to kernel command line.
or boot with systemd.unit=multi-user.target .. OR issue init 3 in the command line..
and *probably*: nomodeset
-- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net
Which results in 1600 x 1200 in a 2560x1440 screen..... Man, this graphics snafu is really a major major setback: wtf is wrong with being left with *no* configurability of a graphics system if you want totry something different? thank God someone did a 12.1/kde3 in obs and thank God that I had the foresight to *update that* to 12.3, so I still got my 2560X1440, gosh, the latest kde4 is just about equal to my trusty old kde3, sheesh, now i spend my time 40-60 on kde4/kde3, still i don't think i am ready to switch for good:)))) but it is getting closer:))) Sooo,this kms is *not* really ready for prime time, nouveau is *not* as good as nvidia, thuuus, PLEASE, make it a little easier to let us choose what driver we want and allow an easier dumping of nouveau & kms, what we have to do now is like trying to remove internert explorer from windoze!!!!!! regards, d. d. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 11 Apr 2013 21:22:50 -1000 kanenas@hawaii.rr.com wrote: ...
and *probably*: nomodeset ... Which results in 1600 x 1200 in a 2560x1440 screen..... Man, this graphics snafu is really a major major setback: wtf is wrong with being left with *no* configurability of a graphics system if you want totry something different?
Do you know how to create xorg.conf in /etc/X11/, or edit files in /etc/X11/xorg.conf.d/ ? It is the same way as in old times, with added benefit of smaller files in xorg.conf.d that can be used if you have to add only line or two. If you are not sure how, then use rpm files, or nvidia installer. Both work fine. http://en.opensuse.org/SDB:NVIDIA
... now i spend my time 40-60 on kde4/kde3, still i don't think i am ready to switch for good:)))) but it is getting closer:)))
I lead you few years with full time KDE4 usage. For light KDE see what you can help with: http://lizards.opensuse.org/2013/04/11/hackweek9-lightweight-kde-desktop-pro... and http://blogs.kde.org/2013/04/11/hackweek9-lightweight-kde-desktop-project-up... note that repo is at: https://build.opensuse.org/project/show?project=home%3Awstephenson%3Aworkben...
Sooo,this kms is *not* really ready for prime time, ...
KMS is fine. Even your trusted nvidia is using it :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (15)
-
Andrey Borzenkov -
Anton Aylward -
Basil Chupin -
Bruce Ferrell -
Cristian Rodríguez -
Damon Register -
Damon Register -
David Haller -
Felix Miata -
kanenas＠hawaii.rr.com -
Ken Schneider - openSUSE -
Linda Walsh -
Patrick Shanahan -
Rajko -
Sujit Karatparambil