systemd & siduction

[hefee]

Moin,

für alle die mal systemd mit siduction testen wollen:

* systemd installieren
* im grub init=/bin/systemd hinzufügen

fertisch.

Ja es ist so einfach wie es klingt, das Beste sysvinit muss dabei nicht deinstalliert werden. Wenn also systemd hackt dann einfach das init=/bin/systemd weglassen und wieder gepflegt mit sysvinit starten.

Ich selber habe ein vollverschlüsseltes System LUKS+LVM was nun mit 44-8 auch tut. Von den Maintainern ist angestrebt, dass systemd für wheezy eigentlich schon komplett einsatzbereit ist nur halt nicht als standard initsystem.

[qwerthi]

hefee hat geschrieben

* im grub init=/bin/systemd hinzufügen

Wo genau muss das eingetragen werden?

qwerthi

[hefee]

Also wenn du es nur einmal zum testen nehmen willst:
* rechner neustarten in grub (e) drücken um den zu startenden Eintrag zu bearbeiten
* dann in die Zeile die mit linux anfängt gehen und ganz an ende das hinzufügen. Hier ein Beispiel:
linux   /vmlinuz-3.7-5.towo-siduction-amd64 root=/dev/mapper/vtabin-root ro quiet init=/bin/systemd

(diese variante gilt nur für das aktuelle booten)

Wenn mensch dauerhaft auf systemd umsatteln will in der Datei /etc/default/grub bei GRUB_CMDLINE_LINUX oder GRUB_CMDLINE_LINUX_DEFAULT das init=/bin/systemd hinzufügen:
z.B.:
vorher:

Code Select Expand


...
GRUB_CMDLINE_LINUX="<blafasel>"
...


nachher:

Code Select Expand


...
GRUB_CMDLINE_LINUX="<blafasel> init=/bin/systemd"
...


Diese Variante natürlich am besten nur, falls das einmalige booten mit systemd geglückt ist.

[pjnsmb]

very interesting , but be careful if you start using it.......

Starting a dist-upgrade I noticed on my system that using init 3 will NOT stop x , I had to manually stop x .

This is on a standard install using lightdm.

[hefee]

Starting a dist-upgrade I noticed on my system that using init 3 will NOT stop x , I had to manually stop x .

Because there are no runlevels anymore you have to shut down the graphical part differently:

for "init 3":
service  graphical.target stop

for switch back to "init 5":
service  graphical.target start

[ralul]

"service" is a general wrapper - also for insserv. It is not surely delivering all of systemd.

runlevel3=multi-user.target
runlevel5=graphical.target

to change a target:
systemctl isolate multi-user.target

Code Select Expand

vdir /usr/lib/systemd/system/run*.target
lrwxrwxrwx 1 root root 15 26. Jan 13:34 /usr/lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 26. Jan 13:34 /usr/lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root 17 26. Jan 13:34 /usr/lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root 17 26. Jan 13:34 /usr/lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root 17 26. Jan 13:34 /usr/lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 16 26. Jan 13:34 /usr/lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root 13 26. Jan 13:34 /usr/lib/systemd/system/runlevel6.target -> reboot.target
That above is systemd-197 from Gentoo. Could be /lib/systemd for Debian systemd-44.

Also Debian systemd-44 worked without problems I didn't like it: It is in an extensive sysvinit compatible mood, it therefore is overcomplicated. This compatibility was stoped by systemd developers. By that systemd-180ff has gone much more simple ways.

[pjnsmb]

root@petersbox:/home/peter# vdir /lib/systemd/system/run*.target
lrwxrwxrwx 1 root root 15 Jan 19 19:54 /lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Jan 19 19:54 /lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root 17 Jan 19 19:54 /lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Jan 19 19:54 /lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Jan 19 19:54 /lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 17 Jan 19 19:54 /lib/systemd/system/runlevel5.target -> multi-user.target
lrwxrwxrwx 1 root root 13 Jan 19 19:54 /lib/systemd/system/runlevel6.target -> reboot.target


so what has happened to my graphical.target  :?

[ralul]

These links of runlevel are not that important, but the link of default.target in /etc/systemd/system is:

Code Select Expand

$ vdir /etc/systemd/system
insgesamt 56
-rw-r--r-- 1 root root  518 23. Aug 17:50 apache2.service
-rw-r--r-- 1 root root  239 23. Aug 17:50 atd.service
lrwxrwxrwx 1 root root   40 21. Aug 20:00 default.target -> /usr/lib/systemd/system/graphical.target
lrwxrwxrwx 1 root root   37 26. Aug 10:40 display-manager.service -> /usr/lib64/systemd/system/kdm.service
drwxr-xr-x 2 root root 4096 26. Jan 13:34 getty.target.wants
drwxr-xr-x 2 root root 4096  2. Sep 17:51 graphical.target.wants
-rw-r--r-- 1 root root  478 23. Aug 17:50 iptables.service
drwxr-xr-x 2 root root 4096 21. Aug 12:55 local-fs.target.wants
-rw-r--r-- 1 root root  127  2. Sep 17:51 localstart.service
drwxr-xr-x 2 root root 4096 26. Jan 13:34 multi-user.target.wants
-rw-r--r-- 1 root root  107 23. Aug 17:50 mysqld.conf
-rw-r--r-- 1 root root  371 23. Aug 17:50 mysqld.service
lrwxrwxrwx 1 root root    9 31. Dez 12:49 plymouth-quit.service -> /dev/null
lrwxrwxrwx 1 root root    9 31. Dez 12:49 plymouth-quit-wait.service -> /dev/null
lrwxrwxrwx 1 root root    9 31. Dez 12:50 plymouth.service -> /dev/null
lrwxrwxrwx 1 root root    9 31. Dez 12:47 plymouth-start.service -> /dev/null
drwxr-xr-x 2 root root 4096  6. Nov 09:58 printer.target.wants
drwxr-xr-x 2 root root 4096  6. Nov 09:58 sockets.target.wants
drwxr-xr-x 2 root root 4096 20. Aug 16:13 sysinit.target.wants
And look above at the links to /dev/null: This is the disablement mechanism of systemd: I don't like plymouth ....

[hsp]

Mich würde mal interessieren ob von euch jemand systemd tatsächlich schon ensthaft einsetzt?

...

[hefee]

Ich - mit dem wechsel sind dann nochmal einige Fehler im etc aufgefallen (lvm+crypt) aber nachdem ich da sauber überall die richtige UUID reingemalt habe lööpt das ohne dass ich irgendwas tun müsste das war vor dem Wechsel zu grub2.00, so dass ich meine boot ungenauigkeiten einfach schon vorher lösen konnte und der Wechsel zu grub2.00 für mich kein problem darstellte

[devil]

Auf einem Notebook seit ~ 1.5 Jahren. Mit 2-maliger Neuinstallation wegen kaputtspielens.

greetz
devil