Lenovo Thinkpad T450s: „Błąd: nieulotna pamięć systemowa UEFI o zmiennej pojemności jest prawie pełna”.


5

Mój klient korzysta z Lenovo Thinkpad T450 od około roku. Na maszynie działa teraz Debian jessie, z jądrem poza jessie-backports 4.5+73~bpo8+1. Najnowsza wersja UEFI jest flashowana / instalowana. System operacyjny jest zainstalowany w „trybie UEFI”, z dodatkową EFIpartycją itp. Do około czterech tygodni temu konfiguracja była solidna i stabilna: Lenovo Thinkpad i Debian, co może pójść nie tak?

Od czterech tygodni, przy każdym uruchomieniu, maszyna pokazuje błąd, który popełniłem w temacie. Oto obraz tego:

Błąd: pamięć nieulotna zmiennego systemu UEFI jest prawie pełna.

Naciśnięcie Escspowoduje kontynuację procesu rozruchu, który działał „dobrze” ... jeszcze przez dwa tygodnie. Wiadomość zmieniła się z

Naciśnij Esc, aby kontynuować, lub F1, aby przejść do konfiguracji.

do

Posprzątaj TAK lub NIE

(niestety nie mam tego obrazu).

Mój klient nacisnął „TAK”, co spowodowało, że wyczyściłem pamięć masową, o ile widzę to wszystko, co uniemożliwiło uruchomienie komputera. Potem przywróciłem pozycję rozruchową „debian”, a maszyna znów była szczęśliwa, ładowała się dobrze itp. Trwało to jeszcze kilka dni; od ~ jednego tygodnia komunikat pojawia się ponownie przy każdym uruchomieniu.

Próbowałem skontaktować się z obsługą Lenovo cztery razy w ciągu czterech różnych dni i zrezygnowałem po około 30 minutach w kolejce telefonicznej za każdym razem.

Wykorzystałem wszystkie moje umiejętności $ (twoja ulubiona wyszukiwarka-tutaj) w ostatnich dniach i znalazłem prawie nic: skąd to się bierze, jak debugować i, co najważniejsze, jak to naprawić. Wydaje mi się, że w obecnej sytuacji maszyna nie będzie mogła zostać ponownie uruchomiona.

Wszelkie wskazówki bardzo mile widziane!


Jak duża jest partycja EFI? Jaki procent używanego systemu plików EFI? Dowiedz się z:df -hT /boot/efi
Deltik

@Deltik To ~ 500mb, zużycie obecnie wynosi około 1%. (Sprawdziłem to również wcześniej, przepraszam, że nie postawiłem tego w pytaniu. O ile rozumiem komunikat o błędzie, nie chodzi o /boot/EFI, ale o „coś innego”, prawda?) [Jestem nie ma mowy o czymś w rodzaju „eksperta UEFI”, więc całkiem możliwe, że się w tym mylę.]
gf_

Ach, to byłoby zbyt łatwe, prawda? Kolejnym miejscem na wygląd jest tutaj: /sys/firmware/efi/efivars/. Prawdopodobnie są to zmienne, na które narzeka system UEFI.
Deltik

@Deltik Tak ... byłoby łatwo. :( O /sys/firmware/efi/vars/: W środku jest „dużo rzeczy”. Wiesz, co powinienem sprawdzić?
gf_

Zgaduję tutaj, ale to powinno posortować zmienne według wielkości w porządku rosnącym:ls -lh /sys/firmware/efi/efivars | sort -k5 -h
Deltik

Odpowiedzi:


5

Jądro Linux od wersji 3.8 streszczenia UEFI jako zmiennej przechowywaniaefivarfs .

Montowanie efivarfs

Jeśli mount | grep '^efivarfs'nic nie zwróci, możesz zamontować efivarfsza pomocą tego polecenia:

mount -t efivarfs efivarfs /sys/firmware/efi/efivars

Teraz możesz przeglądać, /sys/firmware/efi/efivarsczy jakieś zmienne się wyróżniają.

Sortowanie zmiennych UEFI według rozmiaru

efivarfsnie ma pojęcia użycia dysku, ale zgłasza każdą zmienną według rozmiaru. To polecenie sortuje zmienne według wielkości, rosnąco:

ls -lh /sys/firmware/efi/efivars | sort -k5 -h

Następne kroki

To jest tak dalece, jak mogę zabrać cię za pomocą informacji, które podałeś. Następnie musisz dowiedzieć się, co zajmuje tyle miejsca w zmiennej pamięci NVRAM UEFI.

Arch Linux Wiki sugeruje usuwanie /sys/firmware/efi/efivars/dump-*plików / zmiennych jeśli istnieją, choć nie wspomina, co tworzy te zmienne.

Jak omówiono na czacie , jednym z podejść byłoby zrobienie migawki zmiennych UEFI, przepłukanie ich zgodnie z propozycją oprogramowania układowego Lenovo, ponowne zainstalowanie rozruchu EFI Debiana, wykonanie migawki ponownie, poczekanie na ponowne wypełnienie zmiennych UEFI i zrobienie jednej więcej migawek. Następnie będziesz mógł porównać migawki, aby zobaczyć, co się zmieniło i, mam nadzieję, zidentyfikować, co powoduje, że problematyczna zmienna lub zmienne zajmują tak dużo miejsca.

Jeśli wszystko inne zawiedzie, możesz wrócić do starszego uruchamiania.


Jak sugeruje wiki Arch, w środku /sys/firmware/efi/efivarsbyło rzeczywiście wiele dump-*plików. Na razie usunąłem je, co ponownie uszczęśliwiło oprogramowanie układowe UEFI. Jutro opublikuję kolejne. (Dzięki za ten wskaźnik Deltik, bardzo doceniony, nie znalazłem tego sam.)
gf_

2
Jeśli się nie mylę, dump-*pliki zawierają informacje o awarii jądra. Nie wiem dużo o nich, ale spodziewam się, że powinny je tworzyć tylko jądra skonfigurowane do debugowania, dlatego polecam sprawdzenie opcji kompilacji jądra (jeśli jądra są kompilowane lokalnie) i opcji rozruchu, aby sprawdzić, czy coś może być źle skonfigurowane aby niepotrzebnie utworzyć te pliki.
Rod Smith

@RodSmith Thanks. Konfiguracja jest dość prosta, nic szczególnego: GRUB2, UEFI, Debianjądra waniliowe z jessie-backports, nie kompilowane samodzielnie. Masz pomysł na to, co powinienem konkretnie?
gf_

1
W takim przypadku możesz opublikować raport o błędzie w Debianie, ponieważ wygląda na to, że może to być domyślna konfiguracja Debiana, która zapełnia ograniczoną pamięć dostępną w NVRAM.
Rod Smith

2
Dzięki, usunięcie dump* plików zadziałało dla mnie.
Francuski Boiethios,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.