[opensuse] How to set the default runlevel in openSUSE 12.3 ?
How can I set the default runlevel in openSUSE 12.3 ? OK, it's called target now but YAST shows an empty dropdown list in the expert-view of the service manager where one used to chose the default runlevel. According to the documentation this is still the right place to look. I have KDE installed but most of the time I don't need all this graphical goodness so it's a waste of ressources. Manually switching back with "init 3" after every boot is not a perfect solution. regards Andreas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sat, 15 Jun 2013 13:20:10 +0200 Andreas <maps.on@gmx.net> пишет:
How can I set the default runlevel in openSUSE 12.3 ? OK, it's called target now but YAST shows an empty dropdown list in the expert-view of the service manager where one used to chose the default runlevel.
According to the documentation this is still the right place to look.
I have KDE installed but most of the time I don't need all this graphical goodness so it's a waste of ressources. Manually switching back with "init 3" after every boot is not a perfect solution.
ln -sf /usr/lib/systemd/system/multi-user.target \ /etc/systemd/system/default.target -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-06-15 13:20, Andreas wrote:
How can I set the default runlevel in openSUSE 12.3 ? OK, it's called target now but YAST shows an empty dropdown list in the expert-view of the service manager where one used to chose the default runlevel.
According to the documentation this is still the right place to look.
I have KDE installed but most of the time I don't need all this graphical goodness so it's a waste of ressources. Manually switching back with "init 3" after every boot is not a perfect solution.
Create "/etc/inittab" with this line only: id:3:initdefault: Apparently, it works. I did not create it: YaST did on install, if target text is chosen. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On 06/15/2013 09:30 AM, Carlos E. R. wrote:
Create "/etc/inittab" with this line only:
id:3:initdefault:
Apparently, it works. I did not create it: YaST did on install, if target text is chosen.
systemd does not read or use inittab in anyway, Yast created it because it still mostly lives in the pre-systemd era. (and there is already a bug filled for this) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-06-15 20:37, Cristian Rodríguez wrote:
On 06/15/2013 09:30 AM, Carlos E. R. wrote:
Create "/etc/inittab" with this line only:
id:3:initdefault:
Apparently, it works. I did not create it: YaST did on install, if target text is chosen.
systemd does not read or use inittab in anyway, Yast created it because it still mostly lives in the pre-systemd era. (and there is already a bug filled for this)
Yast only created that line, and system indeed started in text mode. On the other hand, the link exists:
lrwxrwxrwx 1 root root 40 Jun 2 01:53 /other/aux_01/etc/systemd/system/default.target -> /usr/lib/systemd/system/runlevel3.target -rw-r--r-- 1 root root 517 Apr 22 12:15 /other/aux_01/usr/lib/systemd/system/multi-user.target Telcontar:~ #
-- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On 2013-06-15 13:20 (GMT+0200) Andreas composed:
How can I set the default runlevel in openSUSE 12.3 ? OK, it's called target now but YAST shows an empty dropdown list in the expert-view of the service manager where one used to chose the default runlevel.
According to the documentation this is still the right place to look.
I have KDE installed but most of the time I don't need all this graphical goodness so it's a waste of ressources. Manually switching back with "init 3" after every boot is not a perfect solution.
Andrey gave the official answer, like any non-admin would ever remember it. Carlos gave a probably slightly easier way to remember, but it likely won't work after next OS upgrade. Want one to probably more easily remember? Put the runlevel you want on Grub's kernel cmdlines. With GFXboot menu, it's oh so simple to change on the fly for those times you want different than normal. For normal times, add a 3 to the appropriate menu.lst lines if using Grub Legacy. If using Grub 2, the change goes on the GRUB_CMDLINE_LINUX= line in /etc/default Grub for a "permanent" change, /boot/grub2/grub.cfg for a change that lasts only until its next automagic reconstruction. -- "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
В Sat, 15 Jun 2013 10:15:27 -0400 Felix Miata <mrmazda@earthlink.net> пишет:
Andrey gave the official answer, like any non-admin would ever remember it.
Current upstream systemd provides "systemctl get-default" and "systemctl set-default". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, June 15, 2013 06:53:26 PM Andrey Borzenkov wrote:
В Sat, 15 Jun 2013 10:15:27 -0400
Felix Miata <mrmazda@earthlink.net> пишет:
Andrey gave the official answer, like any non-admin would ever remember it. Current upstream systemd provides "systemctl get-default" and "systemctl set-default". Looking at; [CODE]
rpl7:~> man systemctl [/CODE] the "get-default" and "set-default" are not described. Executing the commands shown result in: [CODE] rpl7:~> sudo systemctl get-default root's password: Unknown operation 'get-default'. [/CODE] Could you point me to help with these commands? Thanks Russ -- openSUSE 12.3(Linux 3.7.10-1.11-desktop x86_64)|KDE 4.10.4 "release 569"|Intel core2duo 2.5 MHZ,|8GB DDR3|GeForce 8400GS(NVIDIA-Linux-x86_64-319.17) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 16/06/13 16:20, Upscope escribió:
Could you point me to help with these commands?
Of course they are not, since get-default and set-default only exist in systemd git HEAD, not in any released version. Currently you have to change runlevels using ln -sf /usr/lib/systemd/system/multi-user.target \ /etc/systemd/system/default.target or ln -sf /usr/lib/systemd/system/graphical.target \ /etc/systemd/system/default.target Next systemd will have both set-default , get-default and the respective dbus methods for applications that want to change the default runlevel. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Upscope said the following on 06/16/2013 04:20 PM:
On Saturday, June 15, 2013 06:53:26 PM Andrey Borzenkov wrote:
В Sat, 15 Jun 2013 10:15:27 -0400
Felix Miata <mrmazda@earthlink.net> пишет:
Andrey gave the official answer, like any non-admin would ever remember it. Current upstream systemd provides "systemctl get-default" and "systemctl set-default". Looking at; [CODE]
rpl7:~> man systemctl [/CODE]
the "get-default" and "set-default" are not described.
Executing the commands shown result in: [CODE] rpl7:~> sudo systemctl get-default root's password: Unknown operation 'get-default'. [/CODE]
Could you point me to help with these commands? Thanks
Did you google? http://opensuse.14.x6.nabble.com/How-to-set-the-default-runlevel-in-openSUSE... is earlier in this thread. Eventually the changes going on that I see in [systemd-devl] do percolate down. The official line is that the packagers have to makes sure that the changes don't break anything ... HA HA HA http://cgit.freedesktop.org/systemd/systemd/commit/?id=99504dd4c or http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/10980 -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-06-16 at 16:44 -0400, Anton Aylward wrote:
Eventually the changes going on that I see in [systemd-devl] do percolate down. The official line is that the packagers have to makes sure that the changes don't break anything ... HA HA HA
Aha! But that is what happens to me, that the upgrade procedure does not catch and migrate things that worked before and don't now >:-P - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+PiEACgkQtTMYHG2NR9UaUQCgkEkI9Z1u2I1sGIsgEVXgnizd OkQAnjGj9OlLH8Uznppy3e6LbrK9d76F =P391 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. said the following on 06/16/2013 06:37 PM:
On Sunday, 2013-06-16 at 16:44 -0400, Anton Aylward wrote:
Eventually the changes going on that I see in [systemd-devl] do percolate down. The official line is that the packagers have to makes sure that the changes don't break anything ... HA HA HA
Aha! But that is what happens to me, that the upgrade procedure does not catch and migrate things that worked before and don't now >:-P
I suspect what has happened is that the new release had over-written your carefully edited files rather than creating .rpmnew versions that 'suggest' a change and let you do a diff. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-06-16 at 19:23 -0400, Anton Aylward wrote:
Carlos E. R. said the following on 06/16/2013 06:37 PM:
On Sunday, 2013-06-16 at 16:44 -0400, Anton Aylward wrote:
Eventually the changes going on that I see in [systemd-devl] do percolate down. The official line is that the packagers have to makes sure that the changes don't break anything ... HA HA HA
Aha! But that is what happens to me, that the upgrade procedure does not catch and migrate things that worked before and don't now >:-P
I suspect what has happened is that the new release had over-written your carefully edited files rather than creating .rpmnew versions that 'suggest' a change and let you do a diff.
I had a lot of them, but none that I remember in sysconfig. Some services were simply disabled, no rpmorig/new there. I had to reenable them manually, when I found out - like fam requiring rpc now, and rpc was not started. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+VGAACgkQtTMYHG2NR9XSQACfSwIMW/d+qp/O4pMYsDayMGd7 TrUAn2hQZ6bqYwuwhmxLzZ+qCt5WTv/J =4jmr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Mon, 17 Jun 2013 02:12:16 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> пишет:
Some services were simply disabled, no rpmorig/new there. I had to reenable them manually, when I found out - like fam requiring rpc now, and rpc was not started.
If that happened on update, it is definitely worth bug report. Update should not change current enabled/disabled status. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+fpMACgkQR6LMutpd94wHvwCbBM2zmWzHbXTrfKXfrWED3G1+ /rkAnR8kZQdMcJvABdQrDVc25nB1IhpR =CUoW -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 07:12 +0400, Andrey Borzenkov wrote:
В Mon, 17 Jun 2013 02:12:16 +0200 (CEST) "Carlos E. R." <> пишет:
Some services were simply disabled, no rpmorig/new there. I had to reenable them manually, when I found out - like fam requiring rpc now, and rpc was not started.
If that happened on update, it is definitely worth bug report. Update should not change current enabled/disabled status.
I have my notes about what failed on the upgrade, and I do plan to report all of them in a single bugzilla, to keep the context and save typing, before I forget the details. They can ask for the individual things to handle go on separate reports later, if they are interested. Let's see when I can. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+0igACgkQtTMYHG2NR9U1bQCdFo3Ww+Iuwfmf6fGwbfXai5Lc nA0An1b8YhHf+ihOi+YwOFrZTCBNa5AG =Gsbx -----END PGP SIGNATURE-----
On Mon, Jun 17, 2013 at 1:08 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
I have my notes about what failed on the upgrade, and I do plan to report all of them in a single bugzilla, to keep the context and save typing, before I forget the details.
Well, that's usually wrong think to do. One bug report should contain one problem. Because each problem may concern unrelated components, each having different maintainer. You simplify task for you, but make it more complicated for "them" to handle it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 14:06 +0400, Andrey Borzenkov wrote:
On Mon, Jun 17, 2013 at 1:08 PM, Carlos E. R. <> wrote:
I have my notes about what failed on the upgrade, and I do plan to report all of them in a single bugzilla, to keep the context and save typing, before I forget the details.
Well, that's usually wrong think to do. One bug report should contain one problem. Because each problem may concern unrelated components, each having different maintainer. You simplify task for you, but make it more complicated for "them" to handle it.
Not this time, sorry :-) I have dozens of reports nobody seems to read or act uppon. Eventually they are closed when the release is EOL, nothing doing. I strongly object to writing a dozen issues on a dozen reports, in all of them explaining the context, repeatedly, to have them ignored. I think it is preferable to report all the issues in one report in context, then whoever is interested in one issue asks me to put that into one isolated report, and I would do so gladly. This way they can see how all those issues relate one to the other. Sometimes I see bugzillas that depends on dozens of other bugzillas, to collect them. It is similar. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG+5oQACgkQtTMYHG2NR9X5twCfUURWqTVnfBEablbAzlA+xv01 suMAn0a5Rm2Ovf26UzvQ++CoxFj7DWQy =/0PV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-06-15 16:15, Felix Miata wrote:
On 2013-06-15 13:20 (GMT+0200) Andreas composed:
Andrey gave the official answer, like any non-admin would ever remember it. Carlos gave a probably slightly easier way to remember, but it likely won't work after next OS upgrade.
Who knows!? That was on a fresh install, not an upgraded one. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
participants (7)
-
Andreas -
Andrey Borzenkov -
Anton Aylward -
Carlos E. R. -
Cristian Rodríguez -
Felix Miata -
Upscope