Forum Debian Users Gang

Ogarnąłem chyba już to montowanie zaszyfrowanych zasobów w tym systemd -- innych niż partycje systemowe. Generalnie rzecz biorąc, to ma się do dyspozycji ciekawe narzędzia, które są dostępne pod:

# ls -al /lib/systemd/system-generators/
total 416K
drwxr-xr-x 2 root root 4.0K 2015-01-21 21:04:08 ./
drwxr-xr-x 8 root root 4.0K 2015-01-21 21:04:08 ../
-rwxr-xr-x 1 root root  899 2014-09-30 13:01:10 openvpn-generator*
-rwxr-xr-x 1 root root  47K 2015-01-21 13:31:21 systemd-cryptsetup-generator*
-rwxr-xr-x 1 root root  31K 2015-01-21 13:31:21 systemd-debug-generator*
-rwxr-xr-x 1 root root  27K 2015-01-21 13:31:21 systemd-default-display-manager-generator*
-rwxr-xr-x 1 root root  55K 2015-01-21 13:31:22 systemd-fstab-generator*
-rwxr-xr-x 1 root root  31K 2015-01-21 13:31:22 systemd-getty-generator*
-rwxr-xr-x 1 root root  67K 2015-01-21 13:31:22 systemd-gpt-auto-generator*
-rwxr-xr-x 1 root root  35K 2015-01-21 13:31:21 systemd-insserv-generator*
-rwxr-xr-x 1 root root  27K 2015-01-21 13:31:21 systemd-rc-local-generator*
-rwxr-xr-x 1 root root  23K 2015-01-21 13:31:21 systemd-system-update-generator*
-rwxr-xr-x 1 root root  51K 2015-01-21 13:31:22 systemd-sysv-generator*

I to one w dużej mierze mi uprościły życie. Głównie dwa z nich, ten fstab i cryptsetup. Jeden z nich generuje pliki dla systemd w oparciu o /etc/fstab, drugi na podstawie /etc/crypttab . Z tym, że bez dostosowania tych plików, zwłaszcza jak się szyfruje, się nie obejdzie.

Wszystkie pliki wygenerowane przy pomocy tych powyższych skryptów są lokowane w katalogu /tmp pod określonymi nazwami i trzeba te pliki przekopiować do:/etc/systemd/system/ . Poniżej przykładowy zestaw plików:

# cat systemd-cryptsetup@kabi.service
# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:cryptdisks_start man:cryptdisks_stop man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=systemd-fsck-root.service
Before=media-Kabi.mount

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=30
ExecStart=/usr/sbin/cryptdisks_start %i
ExecStop=/usr/sbin/cryptdisks_stop %i

[Install]
WantedBy=cryptsetup.target

# cat media-Kabi.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
RequiresOverridable=systemd-fsck@dev-disk-by\x2duuid-b47e6dcd\x2d924e\x2d40fa\x2da8b1\x2d7593419f86d7.service
After=systemd-fsck@dev-disk-by\x2duuid-b47e6dcd\x2d924e\x2d40fa\x2da8b1\x2d7593419f86d7.service systemd-cryptsetup@kabi.service

[Mount]
What=/dev/mapper/kabi
Where=/media/Kabi
Type=ext4
Options=defaults,errors=remount-ro,commit=10

[Install]
WantedBy=cryptsetup.target

Pierwszy z nich otwiera kontener przy pomocy narzędzia cryptdisk, drugi montuje to co otworzył pierwszy. Myślałem, by też dorobić osoby skrypt dla fsck ale ten skrypt od mounta automatycznie pociąga fsck i w sumie nie trzeba kolejnego pliku tworzyć. W każðym razie trzeba się pobawić tymi linijkami z after i before by skrypty się w odpowiedniej kolejności odpaliły.

Wredny jest tylko jeszcze fakt, że jeśli nie chce się otwierać jakiegoś kontenera na starcie systemu, to samo "systemctl disable" nie wystarczy i niby usługa jest wyłączona, to i tak startuje. xD Ale i to udało się ogarnąć -- trzeba dodać do /etc/fstab parametr "noauto". Rzecz w tym, że po dopisaniu jego, nie idzie zamontować zasobów via "mount -a". Ale to nie przeszkadza systemd by wywołać usługę via "systemctl start" i ładnie wszystko zamontuje.

W taki sposób z około 2min 30s, udało mi się już zjechać ze startem systemu na:

Startup finished in 23.159s (kernel) + 29.679s (userspace) = 52.839s.

Ostatnio edytowany przez morfik (2015-01-27 05:23:34)

Chyba ogarnąłem już cały ten system montowania zaszyfrowanych voluminów przez systemd, przynajmniej jeśli chodzi o dodatkowe kontenery, bo zaszyfrowany lvm jest jeszcze poza moim zasięgiem, xD

W każdym razie trochę doczytałem i nieco przerobiłem plik od montowania szyfrowanego zasobu. Obecnie on wygląda mniej więcej tak:

[Unit]
Description=Cryptography Setup for %I
Documentation=man:cryptdisks_start man:cryptdisks_stop man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
IgnoreOnIsolate=true
Before=systemd-fsck@dev-mapper-kabi.service media-Kabi.mount umount.target
After=dev-disk-by\x2duuid-f3c10054\x2d0583\x2d4e10\x2d937b\x2ddcdc9a05a25c.device cryptsetup-pre.target systemd-fsck-root.service
BindsTo=dev-mapper-%i.device
BindsTo=dev-disk-by\x2duuid-f3c10054\x2d0583\x2d4e10\x2d937b\x2ddcdc9a05a25c.device
Conflicts=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=30
ExecStart=/usr/sbin/cryptdisks_start %i
ExecStop=/usr/sbin/cryptdisks_stop %i

W linijce z Before znalazł się fsck, z tym, że nie po uuid -- łatwiej się idzie połapać co ma być sprawdzane. Chodzi o to, że w przypadku braku tej usługi w tej linijce, systemd spróbuje sprawdzić volumin chyba chwilę po tym jak dojdzie do jego otwierania, a że ten jest zaszyfrowany, to nie widać jaki on ma system plików, no bo w sumie jeszcze nie ma  żadnego. I niby kontener po otwarciu zostanie zamontowany ale w taki sposób nigdy się nie dokona jego skanowanie, a sam fsck zwróci błąd w stylu:

Jan 24 04:02:21 morfikownia systemd[1]: Started Cryptography Setup for kabi.
Jan 24 04:02:21 morfikownia systemd[1]: Found device /dev/mapper/kabi.
Jan 24 04:02:21 morfikownia systemd-fsck[8882]: fsck failed with error code 8.
Jan 24 04:02:21 morfikownia systemd-fsck[8882]: Ignoring error.
Jan 24 04:02:21 morfikownia systemd[1]: Started File System Check on /dev/disk/by-uuid/990d110a-1310-4ab2-8a03-c952a408be11.
Jan 24 04:02:21 morfikownia systemd[1]: Mounting /media/Kabi...
Jan 24 04:02:21 morfikownia systemd-fsck[8882]: fsck.ext4: No such file or directory while trying to open /dev/mapper/kabi_unformatted

Czyli niby jest ale jednak nie ma. xD Jeśli się doda fsck do linijki z Before, to wtedy system sobie poradzi:

Jan 24 05:15:43 morfikownia systemd[1]: Starting Cryptography Setup for kabi...
Jan 24 05:15:43 morfikownia systemd[1]: Expecting device dev-mapper-kabi.device...
Jan 24 05:15:43 morfikownia cryptdisks_start[31338]: Starting crypto disk...kabi (starting)...
Jan 24 05:15:52 morfikownia cryptdisks_start[31338]: kabi (started)...done.
Jan 24 05:15:52 morfikownia systemd[1]: Started Cryptography Setup for kabi.
Jan 24 05:15:52 morfikownia systemd[1]: Found device /dev/mapper/kabi.
Jan 24 05:15:52 morfikownia systemd[1]: Starting File System Check on /dev/mapper/kabi...
Jan 24 05:15:52 morfikownia systemd-fsck[31426]: kabi: clean, 12249/1966080 files, 7522780/7863808 blocks
Jan 24 05:15:52 morfikownia systemd[1]: Started File System Check on /dev/mapper/kabi.
Jan 24 05:15:52 morfikownia systemd[1]: Mounting /media/Kabi...
Jan 24 05:15:52 morfikownia kernel: [ 5230.287971] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro,commit=10
Jan 24 05:15:52 morfikownia systemd[1]: Mounted /media/Kabi.

Dalej w pliku jest dodane After=dev-disk-by\x2duuid-f3c10054\x2d0583\x2d4e10\x2d937b\x2ddcdc9a05a25c.device , a to jest UUID partycji z zaszyfrowanym voluminem i jeśli system nie znajdzie takiego urządzenia, będzie czekał przez jakiś czas w nadziei, że może się pojawi, aż do timeouta -- chyba 1,5min.

Linijki z BindsTo określają (w tym przypadku) urządzenia, które muszą być widoczne przez system -- jeśli z jakichś powodów znikną, ta usługa się zakończy. I ostania linijka z Conflicts precyzuje,target, po dojściu do którego ta usługa wykona to co ma w ExecStop . Oczywiście wszystko w oparciu o odwróconą kolejność w polach After i Before, bo inaczej kontener by był zamontowany i nie dałoby się go zamknąć xD

___


Przeniosłem także suspend/hibernację z pm-utils na systemd. Domyślne ustawienia są dość ubogie, bo dają możliwość jedynie przypisania odpowiednich przycisków pod konkretne akcje w pliku  /etc/systemd/logind.conf , przykładowo:

HandlePowerKey=hibernate
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
HandleLidSwitchDocked=ignore

W porównaniu do pm-utils, to trochę mało ale można dość poważnie rozszerzyć tę funkcjonalność -- wystarczy stworzyć kilka plików service, tak ze 4 minimum. xD Dwa z nich będą dla zwykłego użytkownika, a dwa pozostałe dla roota. Chodzi generalnie o wykonywanie pewnych działań z odpowiednimi uprawnieniami

Ja u siebie stworzyłem poniższe pliki:

root:/etc/systemd/system# ls -al sleep.target.wants/
total 8.0K
drwxr-xr-x  2 root root 4.0K 2015-01-24 03:13:40 ./
drwxr-xr-x 12 root root 4.0K 2015-01-24 05:13:32 ../
lrwxrwxrwx  1 root root   35 2015-01-24 03:13:40 resume@morfik.service -> /etc/systemd/system/resume@.service
lrwxrwxrwx  1 root root   39 2015-01-24 03:13:40 root-resume.service -> /etc/systemd/system/root-resume.service
lrwxrwxrwx  1 root root   40 2015-01-24 03:13:40 root-suspend.service -> /etc/systemd/system/root-suspend.service
lrwxrwxrwx  1 root root   36 2015-01-24 03:13:40 suspend@morfik.service -> /etc/systemd/system/suspend@.service

Generalnie to tylko dwa z nich mają zastosowanie.-- suspend@morfik.service blokuje ekran przed uśpieniem, a root-resume.service synchronizuje czas itp po wybudzeniu.

Poniżej oba pliki:

[Unit]
Description=Local system resume actions
After=sleep.target

[Service]
Type=oneshot
ExecStartPre=/bin/sleep 2
ExecStart=/opt/skrypty/synchronizacja_czasu
ExecStart=/sbin/sysctl -p
ExecStart=/sbin/swapoff -a
ExecStart=/sbin/swapon -a

[Install]
WantedBy=sleep.target

Tutaj taka mała uwaga, ten sleep na początku ma na celu upewnienie, że sieć zdąży się załadować. Bo z tego co sprawdzałem to zwykle gubiony jest pierwszy ping po wybudzeniu, temu dobrze jest ustawić minimum 2s aby połączenie się zestawiło. Inna sprawa to fakt resetowania ustawień sysctl -- nie wiem czemu po hibernacji/uśpieniu te ustawienia się resetują ale to samo miałem na sysvinit. No i ostatnie dwie linijki czyszczą swapa.

A tu plik użytkownika z blokadą ekranu:

[[Unit]
Description=User suspend actions
Before=sleep.target root-suspend.service

[Service]
User=%I
Type=oneshot
Environment="DISPLAY=:0"
ExecStart=/usr/bin/xscreensaver-command -lock
ExecStartPost=/bin/sleep 2

[Install]
WantedBy=sleep.target

Linijka z User określa prawa wykonywanych działań i w tym przypadku wskazuje na to co jest po @ w suspend@morfik.service , czyli morfik. Jest także ustawiona zmienna $DISPLAY, bo większość aplikacji graficznych tego wymaga, a dalej to już wywołanie blokady ekranu z efektem wygaszenia (2s). xD

Pozostałe dwa pliki, mają ustawione

ExecStart=/bin/true

Tak by same usługi, mimo, że puste, zwracały status SUCCESS. xD

Ostatnio edytowany przez morfik (2015-01-24 21:46:54)

[quote=gnejusz pompejusz]Czyli skrypt do peerblocka też będziesz przerabiał na systemd?[/quote]
Po co? takie skrypty to raczej do crona się pakuje.

Na archlinux wiki pisali coś o tym, że by zbytnio nie używać kilku daemonów od acpi, bo to może prowadzić do dziwnych efektów i prawdopodobnie jeden z nich u mnie wystąpił. Choć nie wiem czy to nie była czasem wina złej konfiguracji, w każdym razie, jak już pisałem wyżej, systemd ma wbudowany własny mechanizm i zgodnie z tym co pisali na wiki, można pozbyć się kilku pakietów.  W sumie to było: acpi acpi-support acpi-support-base acpitool . Tam jednak była też wzmianka o tym, że:

systemd cannot handle AC and Battery ACPI events, so if you use Laptop Mode Tools or other similar tools acpid is still required.[/quote]
I to mnie zastanawia, bo przecie u mnie stan baterii jest pokazywany, nawet na panelu tint2 mam % stanu i bez problemu pokazuje czy się wyczerpuje czy ładuje. Bardziej szczegółowy log jest też w upower:

Kod:

morfik:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          BAT0
  vendor:               HP
  power supply:         yes
  updated:              Sun 25 Jan 2015 10:50:45 PM CET (51 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              42.2528 Wh
    energy-empty:        0 Wh
    energy-full:         48.0394 Wh
    energy-full-design:  48.0394 Wh
    energy-rate:         23.6045 W
    time to empty:       1.8 hours
    percentage:          87%
    capacity:            100%
    technology:          lithium-ion
    icon-name:          'battery-full-symbolic'
  History (charge):
    1422222645  87.000  discharging
  History (rate):
    1422222645  23.604  discharging

Nie wiem czy to tylko u mnie działa czy ten wpis jest nieaktualny ale póki co, po wywaleniu acpi, nic się nie zmieniło w działaniu mojego laptopa. Podświetlanie działa, bateria też i hibernation/sleep/ via sysetmd i hybrid za sprawą upower przy bardzo niskim stanie baterii, lid switch działa, tak samo jak przycisk power. Coś jeszcze? xD

-----

Przepisałem swoją pierwszą usługę z sysvinit na systemd, oczywiście to był dnscrypt-proxy. W sumie wyszło coś takiego:

Kod:

[Unit]
Description=Encrypted DNS resolver
Documentation=man:dnscrypt-proxy
Documentation=file:/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv
DefaultDependencies=true
Requires=resolvconf.service
After=resolvconf.service
Before=shutdown.target

[Service]
Environment="IP=127.0.2.1"
Environment="PORT=53"
Environment="USER=dnscrypt"
Environment="RESOLVER_NAME=opendns"
EnvironmentFile=-/etc/default/dnscrypt-proxy
Type=simple
ExecStartPre=/bin/sh -c '/bin/mkdir /run/dnscrypt-proxy >/dev/null 2>&1 || true'
ExecStartPre=/bin/sh -c '/bin/echo "nameserver ${IP}" | /sbin/resolvconf -a lo.dnscrypt'
ExecStart=/usr/sbin/dnscrypt-proxy \
    --local-address=${IP}:${PORT} \
    --user=${USER} \
    --resolver-name=${RESOLVER_NAME}
ExecStopPost=/sbin/resolvconf -d lo.dnscrypt
ExecStopPost=/bin/rm -Rf /run/dnscrypt-proxy
Restart=on-failure
RemainAfterExit=no

[Install]
WantedBy=multi-user.target

Z tym, że to jeszcze nie koniec roboty, bo na necie widziałem aktywację via socket ale póki co jeszcze nie udało mi się zrozumieć tego mechanizmu i zwyczajnie implementacja się nie powiodła. xD Zostawiam to narazie tak jak jest wyżej. Z tym, że tam jest też opcja [b]EnvironmentFile=-/etc/default/dnscrypt-proxy[/b] , w której można precyzować zmienne i to czyni ten dnscrypt-proxy kompatybilny ze skryptem sysvinit. A ten mały "-" przed ścieżka pliku sprawi, że systemd nie będzie narzekał jeśli tego pliku nie zastanie.

Ten mechanizm działa w oparciu o resolvconf — przed odpaleniem:

Kod:

# cat /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.1
search mhouse.lh

I po:

Kod:

Jan 25 22:49:07 morfikownia systemd[1]: Starting Nameserver information manager...
Jan 25 22:49:07 morfikownia systemd[1]: Started Nameserver information manager.
Jan 25 22:49:07 morfikownia systemd[1]: Starting Encrypted DNS resolver...
Jan 25 22:49:08 morfikownia systemd[1]: Started Encrypted DNS resolver.
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [NOTICE] Starting dnscrypt-proxy 1.4.3
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Initializing libsodium for optimal performance
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Generating a new key pair
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Done
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Server certificate #1408041567 received
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] This certificate looks valid
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Chosen certificate #1408041567 is valid from [2014-08-15] to [2015-08-15]
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [INFO] Server key fingerprint is 8201:4577:3D75:3934:FC25:B83C:8369:72DC:98A2:1368:AA0A:2C18:6C17:D7B4:30E8:CD63
Jan 25 22:49:08 morfikownia dnscrypt-proxy[34732]: [NOTICE] Proxying from 127.0.2.1:53 to 208.67.220.220:443

oraz plik resolv.conf:

Kod:

# cat /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.2.1
search mhouse.lh

Myślałem, że przenoszenie tych usług będzie jakoś bardziej skomplikowane, a to nawet ujdzie w miarę, tylko trzeba obadać te wszystkie parametry używane w plikach. xD

___


Kilka uwag co do plików unitów.

Przy okazji robienia paczki pod dnscrypt-proxy, znalazłem nieco lepszy sposób na tworzenie plików tymczasowych pod chroot dnscrypta. Wprawdzie wcześniej mi do do głowy nie przyszło ale teraz zamiast wpisywać w unit linijki typu:

Kod:

ExecStartPre=/bin/sh -c '/bin/mkdir /run/dnscrypt-proxy >/dev/null 2>&1 || true'
ExecStopPost=/bin/rm -Rf /run/dnscrypt-proxy

Można w katalogu debian/ z budowaną paczką dodać plik dnscrypt-proxy.tmpfile i tam wrzucić:

Kod:

D /run/dnscrypt-proxy 0755 dnscrypt dnscrypt - -

I przy starcie maszyny, ten katalog zostanie automatycznie stworzony i odpowiednio ustawiony.

Druga sprawa to pliki z montowaniem zasobów, czyli te z rozszerzeniem .mount . Zauważyłem, że przy takiej konfiguracji tych plików jak wyżej, system leci do przodu jak gdyby nigdy nic, a sprawdzanie systemu plików odbywa się równolegle i zwykle nawet nie kończy się przed pojawieniem się okienka logowania. Rozwiązałem to przez dodanie do pliku .mount tych linijek:

Kod:

[Install]
WantedBy=basic.target

Zgodnie z tym co jest napisane tutaj: http://www.freedesktop.org/software/systemd/man/bootup.html , basic.target jest przed multi-user.target i graphical.target ale po sysinit.target zatem akurat odpowiednie miejsce by zamontować te dodatkowe dyski. W efekcie system zatrzymuje swoje działanie na parę sekund, na czas sprawdzania fsck, po czym montuje i leci sobie dalej.

___


Wywaliłem właśnie swoje skrypty, za pomocą których to konfigurowała mi się jasność ekranu — chodzi o przywracanie stanu sprzed wyłączenia laptopa. Systemd ma swój własny mechanizm, który powinien działać bez problemu. U mnie jednak nie chciał. xD Sprawa wygląda tak: mój laptop ma pełno bugów w acpi i system rejestruje swój plik od backlightu, czego efektem są dwa — jeden acpi_video0 i drugi intel_backlight .

Kod:

root:~# ls -al /sys/class/backlight/
total 0
drwxr-xr-x  2 root root 0 2015-01-26 05:01:21 ./
drwxr-xr-x 46 root root 0 2015-01-26 05:01:21 ../
lrwxrwxrwx  1 root root 0 2015-01-26 05:01:21 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/
lrwxrwxrwx  1 root root 0 2015-01-26 05:01:21 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/

W takim przypadku system korzysta z acpi_video0 ale możliwe jest sterowanie jasnością ekranu przy pomocy obu powyższych plików, z tym, że przy przyciskaniu klawiszy na laptopie, wartości zmieniają się jedynie w intel_backlight , co powoduje dwie rzeczy. Pierwsza to skoki jasności — z bardzo ciemniej do bardzo jasnej, w zależności od tego co się używa do zmiany podświetlenia. Drugi objaw to brak zapisywania ustawień po restarcie laptopa. Choć w sumie to te ustawienia są zapisywane, z tym, że skoro systemd operuje na acpi_video0 a my kręcimy intel_backlight , to chyba oczywiste jest, że to działać za bardzo nie będzie. xD

Systemd dostarcza unit /lib/systemd/system/systemd-backlight@.service , który ma się zajmować jasnością ekranu — wywoływany jest tuż przed wyłączeniem maszyny, i zaraz na jej starcie. Przy wyłączaniu, zapisuje odpowiednią wartość ze wszystkich dostępnych backlightów do plików w /var/lib/systemd/backlight/ i przy budzeniu maszyny, te wartości są odczytywane i aplikowane.

Na necie znalazłem instrukcje dla Xservera, z którego backlightu ma on korzystać — w przypadku gdy jest ich kilka. Wystarczy stworzyć pliczek z konfiguracja dla Xorga w /etc/X11/xorg.conf.d/ i dać tam poniższą zawartość:

Kod:

Section "Device"
    Identifier    "Device0"
    Driver    "intel"
    Option    "Backlight"    "acpi_video0"
    BusID    "PCI:0:2:0"
EndSection

I od tej pory narzędzia takie jak xbacklight operujące na backlightach będą referować do ustawionego wyżej acpi_video0 , czyli systemd zacznie widzieć zmiany w jasności ekranu i poprawnie je zapisywać i wczytywać.

Oczywiście można też zabronić sterownikowi acpi rejestrować swojego backlighta, tak by w systemie był tylko jeden, a nie dwa. Bo jakby nie patrzeć np. u mnie przyciski na laptopie operują na intel_backlight a nie na acpi_video0 , zatem nawet jeśli zacznę zmieniać nimi wartość podświetlenia ekranu, to i tak systemd tego nie zobaczy i po resecie wczyta starą wartość. By usunąć tego backlighta od acpi, trzeba dopisać parametr acpi_backlight=vendor do linijki kernela. Po resecie powinien być już widoczny tylko jeden backlight:

Kod:

root:~# ls -al /sys/class/backlight/
total 0
drwxr-xr-x  2 root root 0 2015-01-26 05:23:27 ./
drwxr-xr-x 46 root root 0 2015-01-26 05:21:20 ../
lrwxrwxrwx  1 root root 0 2015-01-26 05:21:44 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/

I w takim wypadku systemd nie ma innego wyjścia i będzie musiał operować na nim, czego efektem będzie stworzenie pliku:

Kod:

root:~# ls -al /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:intel_backlight
-rw-r--r-- 1 root root 4 2015-01-26 05:32:21 /var/lib/systemd/backlight/pci-0000:00:02.0:backlight:intel_backlight
root:~# cat /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:intel_backlight
976

I taka rada jeszcze, unikać maksymalnych wartości, czyli nie ściemniać/rozjaśniać na maxa, bo wtedy po restarcie maszyny będą problemy z wartościami.

Ostatnio edytowany przez morfik (2015-01-26 00:50:24)