@Andrzej J - W Mint ma 4.13.0-45-generic od Ubuntu (Mint chyba nigdy nie robił własnych kerneli).
@1709 - Obawiam się, że przekazanie Lenovo B570, że ma DSDT z Windows 2015 jest nieco zbyt nowe dla tego systemu. Jeśli w ogóle to problem z ACPI (a wydaje się, że nie) to zastanawiałbym się raczej nad czymś wcześniejszym (Windows 2008) lub po prostu Linux.
Przeglądnięcie dziennika wykazuje znaczną ilość błędów i to zarówno sprzętowych (system ma problem z uruchomieniem bluetooth, karty WIFI i wielu innych), jak i programowych (spora ilość pochodzi z Cinnamona). Niemniej jednak, dla mnie zastanawiającym tropem są informacje, jakie pojawiają się 14.06 o 20:16. Pośród nich jest m.in.:
cze 14 20:16:19 LaptopMint swapoff[2789]: swapoff: /dev/sda2: swapoff nie powiodło się: Zły argument
cze 14 20:16:19 LaptopMint systemd[1]: dev-sda2.swap: Swap process exited, code=exited status=255
cze 14 20:16:19 LaptopMint systemd[1]: Deactivated swap Swap Partition.
cze 14 20:16:19 LaptopMint systemd[1]: dev-sda2.swap: Unit entered failed state.
Polecenie power off/shutdown jest wysyłane:
cze 14 20:16:20 LaptopMint systemd[1]: Starting Power-Off...
cze 14 20:16:20 LaptopMint systemd[1]: Shutting down.
cze 14 20:16:20 LaptopMint kernel: systemd-shutdow: 40 output lines suppressed due to ratelimiting
Dodatkowo trochę ten system wygląda tak, jakby z jednej strony miał coś, co jest sterownikiem opartym o dkms, z drugiej strony nie miał plików nagłówkowych kernela (bo nie może wejść do katalogu modułów).
Zadziwiające dla mnie jest również, że na tym Lenowo kernel chce się dobrać do WMI od Acera. Raczej to nie ma jednak wpływu na błąd.
Samo ACPI nie wydaje się działać jakoś wadliwie i nie jestem przekonany, czy we właściwym kierunku próbujemy pójść z problemem.
Muszę podkreślić - nie mam i nie będę miał Minta, a (K)Ubuntu znam sprzed ładnych 6-7 lat. Sugerowałbym jednak w pierwszej kolejności ustalenie gdzie może leżeć błąd - czy już na styku kernel/sprzęt, czy też gdzieś jest to sprawa czysto software'owa (wyłączenie następuje z Cinnamon). Może zatem zacząć tak:
1. Uruchomić komputer bez wchodzenia do DE. Proponuję wykonać dwa testy (należy przekazać GRUBemu przy bootowaniu następujące polecenia):
a. systemd.unit=multi-user.target
systemd.unit=rescue.target
# lub , bo nie wiem, które u Ciebie zadziała; niektóre systemy wymagają uprawnień admina do tych poleceń.
Tak samo spróbować zakończyć sesję w Cinnamonie, wydając w konsoli powyższe polecenie.
Sprawdźmy czy zamyka się teraz poprawnie.
Dodatkowo, sprawdzenie co się dzieje przy tym "śpiącym" wyłączaniu: https://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually (https://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually)
1. Swap nie powinien miec chyba wplywu na wylaczanie, zreszta bardziej bym sie skupil na samym ACPI czy dziala,
jak np. klawisze funkcyjne do podswietlania ekranu, czy ktoras z komend do wylaczania systemu.
Jesli ACPI bedzie dzialac, wtedy mozesz sie zajac innymi bledami samego kernela.
Oczywiscie zgadzam sie z toba pavbaranov ze jesli nie mamy konkretnego bledu przy zdarzeniu,
to ciezko stwierdzic przyczyne, dodatkowo informacje ACPI raczej nie sa zbyt oczywiste.
W zamierzeniu, przynajmniej tak powinno byc, ze system zamyka aplikacje , uslugi a potem wysyla komende poweroff jakbys wcisnal przycisk,
jak komputer sie wylaczy to nie otrzymasz juz informacji ze komputer sie wylaczyl, choc zgodze sie ze powinna byc uruchomiona usluga czasowa w RAM,
ze jesli system dalej dziala to ma wypisac blad do logu. Ale to tylko moje gdybanie i moze zyczenie.
2. Zadziwiające dla mnie jest również, że na tym Lenowo kernel chce się dobrać do WMI od Acera
cze 14 20:15:38 LaptopMint kernel: acer_wmi: Acer Laptop ACPI-WMI Extras
cze 14 20:15:38 LaptopMint kernel: acer_wmi: Unsupported machine has AMW0_GUID1, unable to load
Kiedys zglaszalem podobny problem tylko ze z wyswietlajacymi sie komunikatami ACPI, to otrzymalem odpowiedz ze to nie jest blad,
tylko informacja gdy sprzet jest testowany, ale nie dostalem informacji jak te "informacje" wylaczyc.
3. Ostatnio resetowalem haslo root. Mint ma tryb ratunkowy, a w nim okienko graficzne w trybie tekstowym ( napisane chyba w ncurses )
i w tym okienku opcje zalogowania sie jako root.
Czy z tego , czy innego poradnika korzystalem, nie pamietam.
https://mintguide.org/system/248-reset-the-password-for-root-or-any-user-in-linux-mint.html
Tak na szybko: apci=off wyłącza funkcjonalności ACPI takie jak np. oszczędzanie baterii, wygaszanie ekranu itp. Dopisanie tego do GRUBego nie spowoduje, że komputer nie wyłącza się :). Tu nie mamy do czynienia (albo inaczej - nie wiemy), czy to błąd ACPI, zatem sugerowałbym ominięcie jego. Ryzyko żadne.
Wytłuszczone przez Ciebie kwestie dotyczące ACPI nie są istotne/nie powinny być istotne w zakresie wyłączania, ale - znów - jeśli mają - sugeruję wyłączyć ACPI. Dowiemy się więcej.
Pierwszy komunikat mówi, że tablica DSDT, którą chce stosować tu kernel jest inna niż ta, którą w istocie może stosować (choć "linux" jest ostatecznością). Żądanie kernela w tym zakresie jest ignorowane. Owa wadliwa tablica DSDT również nie powinna mieć wpływu na możliwość wyłączania systemu.
Generalnie - IMO - problem leży gdzie indziej. Możemy jeszcze sprawdzić inaczej - livecd (najlepiej kilka różnych, w tym Mint i Sparky w wersjach używanych) - start, próba wyłączenia. Jeśli problem istnieje w wersji "na dysku", to i na livecd winien. Jeśli tylko istnieje "na dysku", to gdzieś są jakieś ustawienia, które się nie bardzo podobają lub mimo wszystko wersje oprogramowania są inne.
Co ciekawe - ten sam model komputera miał też spore problemy z wyłączaniem się na 64bitowym Win7. Lenovo zrobiło jakąś łatkę/driver, ale nie są dostępne (zresztą to pod Windows).
W przypadku niektórych modeli Lenovo i problemów z jego zamykaniem w istocie sterowanie ACPI pomogło np. dołączenie acpi=noirq, niekiedy acpi=force.
Oprócz tego propozycje to np. aktualizacja BIOSu, UEFI... :) oraz - co już też proponowane tu było - inny kernel. Dodam od siebie jeszcze aktualizacja firmware (choć nie wiem, czy to akurat dla Mint/Sparky łatwo dostępne).
Możemy jeszcze spróbować wyłączyć komputer z konsoli przez:
# swapoff -a && systemctl poweroff
Inny pomysł - zmiana ustawień w /etc/systemd/system.conf i zmiana linii:
#DefaultTimeoutStopSec=90s
PS: Wg mnie - w przypadkach obu systemów, kontrolę nad wyłączaniem przejmuje systemd.
PS2: Przydałby się dziennik dla zamykania ze Sparky. Z diffa mogłoby się sporo wyjaśnić.
Razem "acpi=off acpi_os=Windows noapic" ? Razem chyba nie zadziala, zwlaszcza
ze off wylacza ACPI kompletnie, a wiec nie bedziesz mogl uzyc ACPI do wylaczenia komputera.
To tak nie działa :) acpi=off spowoduje wyłącznie brak kontroli komputera nad podsystemem zarządzania energią. Z wyłączaniem nie ma nic wspólnego (a w każdym bądź razie z takim, jakie testujemy). Sensu obu komend razem nie widzę.
Natomiast jeśli chodzi o acpi_os bądź acpi_osi, to struktura jest lekko inna. W przypadku pierwszego winno to wyglądać:
acpi_os_name="Microsoft Windows jakiś"
Źródło wraz ze wskazanymi przykładami owych "WindowsJakiś": https://wiki.archlinux.org/index.php/DSDT (https://wiki.archlinux.org/index.php/DSDT)
@pixel70 - Mam jeszcze pytanie: czy jeśli wyłączasz komputer i pozostawisz go na dłuższą chwilę (powiedzmy ze 2 minuty), to jednak się wyłącza, czy dalej tkwi na "system halted"?
W instrukcji tego laptopa jest wspomniane odnosnie ACPI tylko przy hibernarcji
To cause the computer to enter hibernation mode, follow the steps below:
• If you are using the ACPI operating system and have defined one of the
following actions as the event that causes the system to go into hibernation
mode, perform that action:
– Closing the lid.
– Pressing the power button.
http://lenovo.pl-manual.com/d-b570/user-s-manual.html?page=30
Doczytalem takze co to jest apm, bo nie wiedzialem
https://pl.wikipedia.org/wiki/Advanced_Power_Management
pixel70 widze ze problemu jeszcze nie zglosiles, bo widze tylko inne jedno, inne zgloszenie.
https://bugzilla.kernel.org/buglist.cgi?quicksearch=ACPI%20Lenovo%20B57
Dodane
Oraz uffam ze testowales
Mozesz tez pogrzebac troche w systemie ( w sensie tylko zobaczyc )
Choc to bez roznicy jesli zadna z komend zamykania systemu Ci nie dziala, wiec mozesz to potraktowac tylko jako ciekawostke.
$ ls /etc/acpi/events/powerbtn-acpi-support/
ls: nie ma dostępu do '/etc/acpi/events/powerbtn-acpi-support/': Nie jest katalogiem
$ cat /etc/acpi/events/powerbtn-acpi-support
event=button[ /]power
action=/etc/acpi/powerbtn-acpi-support.sh
$ cat /etc/acpi/powerbtn-acpi-support.sh
...
else
# Normal handling.
/sbin/shutdown -h -P now "Power button pressed"
fi
Aczkolwiek moja intuicja mowi ze wylaczanie powinno dzialac, bo to jest te S5 wspomniane wyzej
nawet tu widze potwierdzenie ze S5 sluzy do wylaczania https://unix.stackexchange.com/questions/122557/how-does-the-system-shutdown-of-a-linux-kernel-work-internally
Pokaż nam jeszcze zawartość cat /usr/lib/systemd/system/systemd-halt.service
locate systemd-halt.service
Jesli dopiero co zainstalowales to dobrze jest wykonac updatedb z konta root by stworzylo baze danych z nazwami plikow.
lub ostatecznie ( ale nie polecam bo zbyt wolne )
find / -name "systemd-halt.service"