* Cristian Rodríguez [04-11-13 13:14]:

El 11/04/13 13:51, Andrey Borzenkov escribió:

...

В Thu, 11 Apr 2013 09:45:29 -0700 Bruce Ferrell пишет:

...

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

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 [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

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 -- 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

В Sat, 13 Apr 2013 01:29:54 +0200 David Haller пишет:

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

В Sun, 14 Apr 2013 13:41:30 +0200 David Haller пишет:

Hello,

On Sat, 13 Apr 2013, Andrey Borzenkov wrote:

...

David Haller ?????:

...

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

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

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

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 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

* Basil Chupin [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

On 04/12/2013 10:29 AM, Patrick Shanahan pecked at the keyboard and wrote:

* Basil Chupin [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 Sat, 13 Apr 2013 15:30:08 +1000 Basil Chupin 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

El 12/04/13 08:54, Patrick Shanahan escribió:

* Basil Chupin [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

On Fri, 12 Apr 2013 19:26:40 -0700 Linda Walsh 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

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

В Sat, 13 Apr 2013 09:10:30 +0400 Andrey Borzenkov пишет:

В Fri, 12 Apr 2013 21:50:36 -0700 Linda Walsh пишет:

...

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

В Sat, 13 Apr 2013 00:04:26 -0700 Linda Walsh пишет:

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

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:

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

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

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

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 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