[opensuse-factory] Booting into runlevel 3 no longer possible by appending 3 to the kernel line
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? I use it frequently to change the power profile of my graphics card before starting the X server because doing it later on (or using dynamic power management) leads to GPU lockups: https://bugs.freedesktop.org/show_bug.cgi?id=77394 Regards, Stefan -- 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 3:24 PM, Stefan Seifert <nine@detonation.org> 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 -- 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 16:15 -0300, Cristian Rodríguez wrote:
On Sun, Mar 29, 2015 at 3:24 PM, Stefan Seifert <nine@detonation.org> 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 <mgalbraith@suse.de> 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
Cristian Rodríguez composed on 2015-03-29 23:34 (UTC-0300):
Mike Galbraith wrote:
I hope it keeps on working.
Yes, it is a bug.
Is there a report filed on it somewhere those with interest can follow? If so, details please. I suspect those doing a lot of booting who wish maximum simplicity until it can be fixed can put 5 on cmdline, set default to multi-user.target, and backspace the 5 away when 3 is actual desire. I normally keep 3 in my Grub stanzas, which grabs my attention when the bootloader menu is up no matter what the default target is. -- "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
В Sun, 29 Mar 2015 20:24:52 +0200 Stefan Seifert <nine@detonation.org> пишет:
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?
systemd.unit=multi-user.target And I think it is a bug, "3" on kernel command line should still work.
I use it frequently to change the power profile of my graphics card before starting the X server because doing it later on (or using dynamic power management) leads to GPU lockups: https://bugs.freedesktop.org/show_bug.cgi?id=77394
Regards, Stefan
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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?
I use it frequently to change the power profile of my graphics card before starting the X server because doing it later on (or using dynamic power management) leads to GPU lockups: https://bugs.freedesktop.org/show_bug.cgi?id=77394
Regards, Stefan Hello Stefan, did You try to change the runlevel resp. system target by similar commands
Am Sonntag, 29. März 2015, 20:24:52 schrieb Stefan Seifert: like the following: init 3 systemctl isolate multi-user.target When i try these. i get messages about: PolicyKit daemon disconnected from the bus We are no longer a registered authentication agent Do You get similar messages? 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 Sun, Mar 29, 2015 at 4:55 PM, Emil Stephan <Emil.Stephan@t-online.de> 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
Am Sonntag, 29. März 2015, 17:01:40 schrieb Cristian Rodríguez:
On Sun, Mar 29, 2015 at 4:55 PM, Emil Stephan <Emil.Stephan@t-online.de> 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. Regards, Emil P.S.: You do not like runlevels, do You? -- 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 Sun, Mar 29, 2015 at 5:27 PM, Emil Stephan <Emil.Stephan@t-online.de> 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 <Emil.Stephan@t-online.de> 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, 17:33:32 schrieb Cristian Rodríguez:
On Sun, Mar 29, 2015 at 5:27 PM, Emil Stephan <Emil.Stephan@t-online.de> 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 <Emil.Stephan@t-online.de>
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 ?
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
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.
-- 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
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 <Emil.Stephan@t-online.de>
...
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 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. !@#$%^& But, the bootline argument is not ignored: if default.target == multi-user.target and you ask for "5", then you will get 5. So the observation I have so far is that what you get is something like — from a DAG POV — union(default.target, commandline) rather than the desired "commandline ? commandline : default.target". -- 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
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 please. -- 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. -- 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
participants (7)
-
Andrei Borzenkov -
Cristian Rodríguez -
Emil Stephan -
Felix Miata -
Jan Engelhardt -
Mike Galbraith -
Stefan Seifert