Systemd w 14.10 i nie tylko

Od kilku dni intensywnie testuję Kubuntu 14.10. Powiem szczerze, że od początku mam trochę mieszane uczucia. Intel znów się nie wyrobił i to co zrobił ze sterownikami grafiki to istna porażka, ale sam system startuje, przynajmniej u mnie, zauważalnie szybciej. 

Na i5 4tej generacji nie mogę sobie włączać ustawień z GRUBA z NeteXt'a gdyż w dmesg mam po tym same błędy z DRM, ale....

ale jak już go postawiłem to postanowiłem zobaczyć jak sobie radzi systemd, który jeszcze w tym wydaniu nie jest natywnie włączony. Zatem wykonałem następujące czynności. Doinstalowałem brakujące pakiety:

sudo apt-get install systemd libpam-systemd systemd-ui

wyedytowałem GRUBA:

sudo nano /etc/default/grub

i dokonałem zmiany wpisu z:

GRUB_CMDLINE_LINUX_DEFAULT="quite splash"

na:

GRUB_CMDLINE_LINUX_DEFAULT="init=/lib/systemd/systemd quite splash"

oczywiście na koniec wymagany jest:

sudo update-grub

i restart.

Po restarcie możemy jeszcze zweryfikować czy systemd wystartował poprawnie:

sudo journalctl -u cron

wynik wygląda mniej więcej tak:

-- Logs begin at pią 2014-10-31 05:19:46 CET, end at pią 2014-10-31 06:26:10 CET. --
paź 31 05:19:47 yoga systemd[1]: Starting Regular background program processing daemon...
paź 31 05:19:47 yoga systemd[1]: Started Regular background program processing daemon.
paź 31 05:19:47 yoga /usr/sbin/cron[700]: (CRON) INFO (pidfile fd = 3)
paź 31 05:19:47 yoga /usr/sbin/cron[700]: (CRON) INFO (Running @reboot jobs)
paź 31 06:25:01 yoga CRON[2203]: pam_unix(cron:session): session opened for user root by (uid=0)
paź 31 06:25:01 yoga /USR/SBIN/CRON[2204]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
paź 31 06:25:01 yoga CRON[2203]: pam_unix(cron:session): session closed for user root

Warto też wiedzieć czy wszystkie usługi wstały poprawnie:

systemctl --failed

Jak widać u mnie jest ok !

0 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

To co mi się podoba to wg mojej oceny dużo szybszy start i brak śmieci w dmesg. Generalnie wszystkie usługi się pięknie podniosły i nie było z prawie niczym problemu. Muszę pomyśleć o "ficzerze" do NeteXt'a, który ułatwi zarządzanie usługami, bo z tego co widzę jest to o wiele przyjemniejsze i łatwiejsze:)

Jedyny problem, który miałem to montowanie partycji SWAP. Okazało się, że w:

/etc/fstab

nie radzi sobie z wpisem UUID, jak go przerobiłem na /dev/sdaX wszystko poszło.

Mając usługi startowe upstart i sysv w dmesg pojawiały mi się wpisy:

[ 17.810870] systemd-logind[1021]: Failed to start unit user@1000.service: Unknown unit: user@1000.service
[ 17.810875] systemd-logind[1021]: Failed to start user service: Unknown unit: user@1000.service
[ 17.813932] systemd-logind[1021]: New session c2 of user marcin.
[ 17.813951] systemd-logind[1021]: Linked /tmp/.X11-unix/X0 to /run/user/1000/X11-display.
[ 48.544309] show_signal_msg: 3 callbacks suppressed

Po przejściu na systemd już nie ma informacji o tych błędach. Jak widać deweloperzy zostawili mały "śmietnieczek", którego nie posprzątali. Mała rzecz, ale oko przy przeglądaniu logów denerwuje.
Jedyny komunikat ostrzeżenia, który mi został to:

[ 3.108566] systemd[1]: [/lib/systemd/system/friendly-recovery.service:14] Executable path is not absolute, ignoring: dmesg --console-off
[ 3.134414] systemd[1]: Cannot add dependency job for unit systemd-vconsole-setup.service, ignoring: Unit systemd-vconsole-setup.service failed to load: No such file or directory. 

Jak się okazuje problem znany i nic z tym nie zrobimy bo:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755194

PLASMA 5 - w skrócie nie idźmy tą drogą, to środowisko nie ma prawa się jeszcze nazwywać nawet wstępną alfą. Całe szczęście, że nie wymusili go natywnie, bo by trzeba było 14.10 omijać szerokim łukiem. Stabilne w nim są tylko zwisy, autozamykanie aplikacji etc.

Reasumując, czekam na poprawki od intel, bo na chwilę obecną np chrome muszę odpalać bez wsparcia grafiki (wszystko na procesorze) poleceniem:

LIBGL_DRI3_DISABLE=1 google-chrome

inaczej mam w dmesg:

Chrome causes segfault in i965_dri.so

 Kwiatków pewnie jest więcej i na innych maszynach może być inaczej. Czekam na Wasze spostrzeżenia.

AKTUALIZACJA

Kolejny błąd, który udało się naprawić to:

/lib/systemd/system/friendly-recovery.service Executable path is not abolute, ignoring: dmesg --console-off

w tym celu wystarczy w pliku:

/lib/systemd/system/friendly-recovery.service

zmienić:

ExecStartPre=-dmesg --console-off

na:

ExecStartPre=-/bin/dmesg --console-off