On Sun, 2015-03-29 at 16:15 -0300, Cristian Rodríguez wrote:

On Sun, Mar 29, 2015 at 3:24 PM, Stefan Seifert wrote:

...

Hi!

Some time in the last month Tumbleweed lost the ability to boot into runlevel 3 (command line with no X server running) by appending a 3 to the kernel line in the grub menu. I guess that's because with systemd there are no numbered runlevels anymore, but I wonder, what the replacement is?

While that should still work.. what you are looking for is to boot with systemd.unit=multi-user.target

I hope it keeps on working. We humans invent shortcuts because we're lazy (sometimes spelled 'efficient' for marketability purposes), and we want to _stay_ lazy :) -Mike -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 2015-03-29 at 23:34 -0300, Cristian Rodríguez wrote:

On Sun, Mar 29, 2015 at 11:22 PM, Mike Galbraith wrote:

...

I hope it keeps on working.

Yes, it is a bug.

I just tested my box (TW), still works. It's slow then going 3 -> 5, says waiting for plymouth boot screen for some reason, but works. -Mike -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Mar 29, 2015 at 4:55 PM, Emil Stephan wrote:

Do You get similar messages?

Yes, but this messages are informative/harmless and got nothing to do with the problem in question. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Mar 29, 2015 at 5:27 PM, Emil Stephan wrote:

Am Sonntag, 29. März 2015, 17:01:40 schrieb Cristian Rodríguez:

...

On Sun, Mar 29, 2015 at 4:55 PM, Emil Stephan wrote:

...

Do You get similar messages?

Yes, but this messages are informative/harmless and got nothing to do with the problem in question. Hello Cristian,

even, if "systemctl isolate <new-target>" does not change anything and the system stays in the current target.

Works for me.. does it happen with both systemd 210 and 219 ?

Regards, Emil

P.S.: You do not like runlevels, do You?

There are no runlevels in the sysvinit-sense when using systemd, there is a minimal compatibility that provides at least the illusion of runlevels. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Sonntag, 29. März 2015, 22:57:47 schrieb Emil Stephan:

Am Sonntag, 29. März 2015, 17:33:32 schrieb Cristian Rodríguez:

...

On Sun, Mar 29, 2015 at 5:27 PM, Emil Stephan

...

Hard to say. I got the update from 210 to 219 today at 13:27. I have used runlevel resp. target changes to install the nvidia drivers to create a mmio trace. And this i have done yesterday too, since i tried several versions of the nvidia drivers. And i think, i had these behaviour yesterday too, but this was not my first level concern in that case. I have just checked, whether i can go back to 210. I have it on the DVD from the eleventh of march. I'll give it a try, and report later. Regards Emil

... Hello, i've done the tests now. In preparation of the tests it turned aout, that there are two groups of packages have to be considered. Group1: systemd systemd-sysvinit Group2: libudev1 udev libgudev-1_0-0 These packages in both groups changed in version from 210 to 219, but can be up-(or down-)graded separately. So i considered three conditions 1: default target for systemd (multi-user and graphical) 2: systemd version (210 or 219) 3: udev version (210 or 219) and four actions 1: runlevel number as kernel parameter 2: changing target by 'init <runlevel number>' 3: changing target by 'systemctl isolate <target name>' 4: changing target by setting the default target and entering it by 'systemctl default' It turned out that the fourth action always worked. This was a mean to change into the target state, if it was necessary for the next test step. I will omit it from the table. Some words about the notation: (x) this is the actual runlevel, when giving the comand x->y x is the requested runlevel rsp. target y is the reached runlevel rsp. target Here the table using some shortcuts: condition action deftg sdvers udvers kparm init sysctl multi 210 210 3 -> 3 (5)3->3 (5)3->3 (3)5->5 (3)5->5 5 -> 5 (5)3->3 (5)3->3 (3)5->5 (3)5->5 210 219 3 -> 3 (5)3->3 (5)3->3 (3)5->5 (3)5->5 5 -> 5 (5)3->3 (5)3->3 (3)5->5 (3)5->5 219 210 3 -> 3 (5)3->3 (5)3->3 (3)5->5 (3)5->5 5 -> 5 (5)3->3 (5)3->3 (3)5->5 (3)5->5 219 219 3 -> 3 (5)3->3 (5)3->3 (3)5->5 (3)5->5 5 -> 5 (5)3->3 (5)3->3 (3)5->5 (3)5->5 graph 210 210 3 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 5 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 210 219 3 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 5 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 219 210 3 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 5 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 219 219 3 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 5 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 The conclusion, i found, is: I couldn't go below the default target. If my default target was multi-user, i could change between multi-user and graphical. If my default target was graphical, i could only change between graphical and graphical. The behaviour does not depend on the two considered versions. I think, Jan Engelhardt already noticed this in another post to this thread. In some cases i had to use action #4 to reach the runlevel, that was a preliminary for the next test, and then had to change the default target back to meet condition #1. In some of these cases, i noticed delays of the reaction to the command entered. It turned out, that probably there was no reaction. After changing the default target, it took about 20 to 25 seconds that the system automatically entered the new default target. I checked this with just waiting with the command at the next test. Is this a wishful behaviour? By the way, this was a mount count burner, forcing a file system check during the tests. Regards, Emil -- Registered Linux User since 19940320 ---------------------------------------------------------- Emil Stephan, Albersloher Weg 571A, 48167 Münster, Germany Accelerate Windows: 9.80665 m/sec^2 would be adequate -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2015-03-30 01:07, Jan Engelhardt wrote:

On Sunday 2015-03-29 20:24, Stefan Seifert wrote:

...

Some time in the last month Tumbleweed lost the ability to boot into runlevel 3 (command line with no X server running) by appending a 3 to the kernel line in the grub menu. I guess that's because with systemd there are no numbered runlevels anymore,

There is a bug… somewhere. !@#$%^&

Follow-up here: http://lists.freedesktop.org/archives/systemd-devel/2015-March/029940.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt composed on 2015-04-02 12:27 (UTC+0200):

On Sunday 2015-03-29 20:24, Stefan Seifert wrote:

...

Some time in the last month Tumbleweed lost the ability to boot into runlevel 3 (command line with no X server running) by appending a 3 to the kernel line in the grub menu. I guess that's because with systemd there are no numbered runlevels anymore, but I wonder, what the replacement is?

Does it still occur for you and have you not changed klog units since? If so, run and paste

systemctl status klog

Welcome to openSUSE 20150329 "Tumbleweed" - Kernel \r (\l). Linux gx150 3.19.3-1-desktop #1 SMP PREEMPT Thu Mar 26 17:34:34 UTC 2015 (f10e7fc) i686 i686 i386 GNU/Linux â klog.service - Early Kernel Boot Messages Loaded: loaded (/usr/lib/systemd/system/klog.service; enabled; vendor preset: disabled) Active: active (exited) since Thu 2015-04-02 06:38:26 EDT; 2min 30s ago Process: 753 ExecStart=/bin/sh -c test -c /dev/tty10 && /usr/sbin/klogconsole $KLOGCONSOLE_PARAMS -r10 || : (code=exited, status=0/SUCCESS) Process: 751 ExecStart=/bin/sh -c test -s /dev/shm/initrd.msg && /bin/cat /dev/shm/initrd.msg >> /var/log/boot.msg || : (code=exited, status=0/SUCCESS) Process: 748 ExecStart=/bin/sh -c /bin/dmesg -r > /var/log/boot.msg (code=exited, status=0/SUCCESS) Process: 723 ExecStart=/bin/sh -c test -s /var/log/boot.msg && /bin/mv -f /var/log/boot.msg /var/log/boot.omsg || : (code=exited, status=0/SUCCESS) Main PID: 753 (code=exited, status=0/SUCCESS) CGroup: /system.slice/klog.service Apr 02 06:38:25 gx150 systemd[1]: Starting Early Kernel Boot Messages... Apr 02 06:38:26 gx150 systemd[1]: Started Early Kernel Boot Messages. -- "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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 2015-04-02 12:46, Felix Miata wrote:

...

...

...

Some time in the last month Tumbleweed lost the ability to boot into runlevel 3 (command line with no X server running) by appending a 3 to the kernel line in the grub menu. I guess that's because with systemd there are no numbered runlevels anymore, but I wonder, what the replacement is?

Does it still occur for you and have you not changed klog units since? If so, run and paste

systemctl status klog

â klog.service - Early Kernel Boot Messages

Loaded: loaded (/usr/lib/systemd/system/klog.service; enabled; vendor preset: disabled) Active: active (exited) since Thu 2015-04-02 06:38:26 EDT; 2min 30s ago Thanks. I too observe the same output.

`systemctl status klog` on TW: loaded (/usr/.../klog.service; enabled; vendor preset: disabled) `systemctl status klog` on openSUSE 13.2 however reports: loaded (/usr/.../klog.service; disabled)

So, *someone or something* caused klog service to become enabled all of a sudden. That in turn means that klog's requirements are being started on boot. Since klog requires "default.target" (which is equivalent to graphical.target), graphical parts will be started even though you have "3" on the boot line.

systemd is working properly.

But you might want to ask Werner Fink / mtomaschewski about klog.service. Hallo Jan,

Am Donnerstag, 2. April 2015, 13:07:54 schrieb Jan Engelhardt: this can explain my observations. The behaviour holds not only for the kernel parameter, but also for using the commands 'init <runlevel>' and 'systemctl isolate <target>'. If the default.target is set to multi-user. i could change between multi-user and graphical with all three methods. If the default.target ist set to graphical. i could only change between graphical and graphical. For me the question is: Why requires klog.service default.target. It need local-fs to access /var/log. It needs virtual consoles for /dev/tty10. Another question is: Do we need klog any further? I assume, we can see the messages, that go into /var/log/boot.msg, with journalctl too (but only as long as the system runs, i think). Regards, Emil -- Registered Linux User since 19940320 ---------------------------------------------------------- Emil Stephan, Albersloher Weg 571A, 48167 Münster, Germany Accelerate Windows: 9.80665 m/sec^2 would be adequate -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org