Forum Debian Users Gang

A jaki masz skrypt? Z tego co wyczytałem problem jest w tym, że gnome i xfce korzystają z upower a ten w jessie jest związany z systemd i to powoduje ze ustawienia z hdparm.conf nie działają.

[bug]725284[/bug]

[quote=nmarx]Nie ogarniam tego systemd :( Nie wiem co tu zrobić :/ Na Wheezym to było prosto, wklejałem odpowiednie linijki do hdparm.conf a tutaj nadal nie wiem co zrobić :( W tym wątku co podałeś nie widzę rozwiązania albo nic nie rozumiem ehh :/[/quote]
W tym linku ze zgłoszeniem błędu są podane rozwiązania.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725284#59

Dokładnie, powinien od razu zrobić to za Ciebie, a potem jeszcze podziękować. :) Daj spokój, kolega znajduje Ci rozwiązanie, a Ty z pretensjami wyskakujesz…

W tej wiadomości do której podlinkował yossarian. Sam nie mam tego problemu i nie che mi się w to szczegółowo wnikać, także nie napiszę Ci co masz zrobić krok po kroku. Jeśli czegoś z tego nie rozumiesz, to możesz po prostu dopytać zamiast się oburzać, to drugie na pewno w niczym Ci nie pomoże, a tylko zrazisz ludzi do siebie.

Gwoli ścisłości – napisałeś wtedy, że nie widzisz rozwiązania albo nic nie rozumiesz. No to dostałeś linka do konkretnej wiadomości z sugerowanymi rozwiązaniami – żebyś zobaczył. No a potem to już podniosłeś larum. :) Wiesz, często wystarcza samo naprowadzenie kogoś na rozwiązanie, nie każdemu trzeba pisać dokładnie co ma po kolei zrobić. A jeśli nie wystarcza, to serio, można kulturalnie zapytać.

Pierwszy link prowadzi do zgłoszenia błędu 725284 (od początku), drugi jest konkretnie do wiadomości 59 w tym zgłoszeniu. Twojego pojmowania kultury wolę nie komentować. ;)

Ok[b] yossarian[/b] wybacz mi moje humory, po prostu się zdenerwowałem wtedy, ale to było głupie.

No nic jakoś sobie poradziłem z tym choć nie wiem czy dobrze, ale jak na razie działa.

Zrobiłem sobie pliczek:

nano /etc/systemd/system/hdparm.service

O treści:

[Unit]
Descritpion=Moje usługi
After=suspend.target hibernate.target

[Service]
Type=simple
ExecStart=/sbin/hdparm -B254 -S 0 /dev/sda


[Install]
WantedBy=multi-user.target suspend.target hibernate.target

Później odpowiedni chmod:

chmod 755 hdparm.service

Start usługi:

systemctl enable hdparm.service

Restart kompa i poszło. Jak na razie działa. Zrobiłem to tak jakby łącząc dwa poradniki i dodałem jeszcze argument -S 0, żeby wyłączyć standby. Polecenie

systemctl status hdparm

nie zgłasza żadnych błędów.

W sumie tak jak napisałem, wszystko działa, ale zastanawiam się, czy zamiast angażować w to systemd nie lepiej byłoby użyć to tego cron-a, tyle, że wtedy po uśpieniu czy hibernacji nie trzymałoby ustawień. Na razie zostawię jak jest ;)

Ostatnio edytowany przez nmarx (2015-04-10 13:17:51)

[quote=nmarx]Przechodzę na Kubuntu LTS, przynajmniej do 2019 roku będę miał spokój z systemd ;) Gdyby ktoś z was znalazł rozwiązanie tego konfliku z hdparm, działające dłużej niż kilka dni to proszę napisać.[/quote]
SOA#1, mam tak samo zrobione. O ile nie zaktualizujesz do 16.04, to rzeczywiście, będziesz miał spokój XD

Wersje LTS w Ubuntu już nie stoją w miejscu, co kilka msc są nowe paczki np. jądro, mesa itp. Upstart jest nieporównywalnie lepszym rozwiązaniem niż systemd. Pewnie ktoś, komu systemd działa i nie ma problemów z głowicą hdd powie, że jest w porządku, ale niech coś zacznie się psuć to zobaczy co to za wynalazek xD. Być może w przyszłości jakaś aktualizacja to naprawi ale na razie jest straszna lipa z tym i to nie tylko u mnie.

Upstart jest nieporównywalnie lepszym rozwiązaniem niż systemd.[/quote]
Mógłbyś rozwinąć te kwestię i uzasadnić jakoś? Z tego co jak tam nasłuchałem się na konferencjach dotyczących systemd, to ubuntu ma/miał (nie wiem czy to się dokonało) zrezygnować z tego swojego upstarta na rzecz systemd. Także nawet devy ubuntu uważają, że systemd jest lepszy. xD

ale niech coś zacznie się psuć to zobaczy co to za wynalazek[/quote]
No mi się popsuło sporo rzeczy ale od czasu jak zacząłem czytać dokumentację, większość z tego co się popsuło, udało mi się naprawić samemu. Ostatnio nawet znalazłem buga w systemd-resolved. Najśmieszniejsze było to, że to przez przypadek wyszło, bo ja szukałem info na trochę inny temat (powiązany z resolverem) i miałem problemy ze zrozumieniem tam pewnych rzeczy. Później wszystko się wyjaśniło, a sam błąd już został poprawiony, no i teraz przynajmniej wiem dokładnie jak to działa i to jest cała istota oprogramowania (nie tylko systemd) — zrozumieć jak coś działa i od razu 99% problemów przestaje z miejsca istnieć. xD

Offline