Linux Mint LMDE 2 Error: The non-volatile variable storage is about full.

[erDiii]

Hallo,

ich habe mir Linux Mint LMDE 2 auf meinem Laptop installiert. Das System lief 4 Monate wunderbar. Nun fährt der Rechner mit folgender Fehlermeldung nicht mehr hoch: The non-volatile variable storage is about full. (3 Beeps)

Ich habe im Internet ein paar Lösungsansätze ohne Erfolg versucht. Nachdem ich die CMOS Batterie rausgemacht habe kommt noch die normale Meldung: 0271: Real Time Clock Error - Check Date and Time settings.

Da ich nicht mehr weiter weiß frage ich hier. Kennt jemand den Fehler und weiß wie er zu beheben ist? Ich lese überall das der Variablenspeicher voll ist und der Rechner keine neuen Variablen erzeugen kann. Im Internet sehe ich überall Befehle um die Dateien zu löschen, aber ich habe garkeine Möglichkeit in ein Terminal zu schreiben, da das System garnicht mehr bootet und ich auch nicht mehr ins BIOS komme.

Ich habe ein Thinkpad T430u.

Besten Dank

erDiii

- - - Beitrag zusammengeführt - - -

https://thinkpad-forum.de/threads/1...=The+non-volatile+variable+storage+about+full

Klingt so als wäre das genau mein Problem. Weiß inzwischen vll jemand wie man das beheben kann?

 

[erDiii]

Bei mir scheint es ein Winbond 25X40BV zu sein. Könnte der Baustein der über dem Winbond liegt auch ein SPI Flashbaustein sein? Wie finde ich das heraus?

 

[SammysHP]

Wie finde ich das heraus?

Modellnummer → Google → Datenblatt. 64 Kbit SPI Flash.

 

[jal2]

Bei mir scheint es ein Winbond 25X40BV zu sein. Könnte der Baustein der über dem Winbond liegt auch ein SPI Flashbaustein sein? Wie finde ich das heraus?

Ja, ist einer. Die Wahrscheinlichkeit ist gross, dass das BIOS im Winbond steckt (siehe Wiki Artikel). Wie gross ist das ausgepackte BIOS?

Modellnummer → Google → Datenblatt. 64 Kbit SPI Flash.

64MBit

 

[cubei]

Ohne SSD/HDD kommst du auch nicht ins BIOS?

 

[fishmac]

Ohne SSD/HDD kommst du auch nicht ins BIOS?

SSD, RAM und den Akku habe ich jeweils rausgenommen. Außerdem habe ich die Tastatur abgemacht und mit einer externen versucht, ohne Erfolg.

Offenbar nicht...

 

[cubei]

Offenbar nicht...

Das man ohne SSD nicht ins OS booten kann und ohne RAM nicht ins BIOS ist klar, deswegen wollte ich noch Mal sicher stellen dass probiert würde ohne SSD aber mit RAM ins BIOS zu kommen. Denn irgendwie hören sich manche Posts so an, als hätte es irgendwas mit Linux zu tun

 

[owl102]

Denn irgendwie hören sich manche Posts so an, als hätte es irgendwas mit Linux zu tun

Es mag durchaus sein, daß Linux Mint LMDE 2 der Auslöser des Problems war, aber das eigentliche Problem liegt im UEFI BIOS des Rechners.

UEFI bietet den Betriebssystemen einen nicht-flüchtigen Speicher an, dort werden neben Variablen auch die Booteinträge für das UEFI-Bootmenü gespeichert. Verhält sich das UEFI BIOS diesbezüglich fehlerhaft, kann es zu allen möglichen unschönen Effekten kommen. In diesem Falle ist vermutlich die Abfrage nach dem Booteintrag fehlerhaft, oder aber das BIOS meldet beim Anlegen des Booteintrages einen Fehler, obwohl es ihn anlegt. Dadurch sind vermutlich zu viele Booteinträge angelegt worden. (Denn Linux nutzt diesen Speicher lediglich für seinen Bootmenüeintrag, von dem es genau einen pro installiertem Betriebssystem geben sollte.) Aber das ist nur Kaffeesatzleserei von mir, würde das System noch booten, könnte man sich mit "efibootmgr -v" anschauen, was und wieviele Booteinträge es aktuell im UEFI Bootmenü gibt.

Daß der Rechner nun gar nicht mehr mag, nur weil dieser nicht-flüchtige Speicher nahezu voll ist, ist ebenfalls ein waschechter Bug des UEFI BIOS. Denn selbst wenn es zum Booten einen Teil des nicht-flüchtigen Speichers benötigen würde, hätte es den letzten Schreibzugriff vom Betriebssystem ablehnen müssen. Wenn man sich den eigenen Flur so voll mit Paketen vollstellt, daß nicht einmal mehr die Haustür aufgemacht werden kann, dann kann der Paketbote nichts dafür.

UEFI BIOS mit solchen Fehlern machen übrigens auch gerne Probleme, wenn man versucht, Windows neu zu installieren.

Wie auch immer, sollte man den Rechner wiederbeleben können, würde ich um UEFI einen großen Bogen machen, denn solche Probleme sind bei UEFI leider bei den allerersten Inkarnationen üblich, und die Hersteller fixen die Probleme in der Regel nur für aktuelle Modelle.

 

[Pferdle]

Es mag durchaus sein, daß Linux Mint LMDE 2 der Auslöser des Problems war, aber das eigentliche Problem liegt im UEFI BIOS des Rechners.

Aha, es ist das Problem vom UEFI, weil es durch Linux verursacht wird. Gut, daß doch einige Windows nutzen, die haben das Problem nicht :thumbsup:

UEFI BIOS mit solchen Fehlern machen übrigens auch gerne Probleme, wenn man versucht, Windows neu zu installieren.

Milliarden Leute installieren Windows milliarden-male neu und es passiert nichts.
Zumindestens was ich gefunden habe, bezieht sich alles auf Linux.
Man es sich auch einfach machen...alle anderen sind Schuld:thumbup:
Schließlich schreibt Linux zu viele Booteinträge ins UEFI und nicht das UEFI selbst. Würde Linux nur einen Eintrag nach der Installation rein schreiben, so wie es Windows macht, gäbe es das Problem nicht. Soweit ich die Beiträge hier im Forum zu dem Thema verfolgt habe, schreibt aber eben Linux Booteinträge auch ohne Neuinstallation, teilweise bei jedem Start des Notebooks, was bei einem nichtflüchtigen Speicher wohl eher Unfug ist.

 

[vlooe]

Wenn ich mir hier alles nochmal so anschaue hört es sich ja nach dem "Linux killt UEFI Thinkpads" bug an.
Dachte immer wenn der zuschlägt macht das ding keinen mux mehr.
Vermutlich ist das dann 2.0 vom selben Bug...

@Pferdle:
Die UEFI Spezifikation sieht vor, dass das OS Einträger ändern/anlegen darf(bei der installation sogar muss).
Wenn das UEFI vermurkst ist und beim ändern den alten Eintrag nicht richtig löscht ist der speicher irgendwann voll.

Dadurch, dass Linux häufig Einträge ändert tritt das Problem nur schneller auf.
Unterm Strich bleibt das UEFI vermurkst.

Linux hat somit nur dazu beigetragen den Murks (schneller/früher) aufzudecken.

 

[owl102]

Aha, es ist das Problem vom UEFI, weil es durch Linux verursacht wird. Gut, daß doch einige Windows nutzen, die haben das Problem nicht :thumbsup:

Den schwarzen Peter hin-und-her schieben bringt gar nichts. Tatsache ist, daß UEFI Funktionen anbietet, die Linux nutzt (und auch nutzen muß!), und die in diesem Falle ganz offensichtlich fehlerhaft sind. Und daß es überhaupt nichts nutzt, die SSD mit dem installiertem Linux auszubauen, damit kein Linux mehr da ist.

Milliarden Leute installieren Windows milliarden-male neu und es passiert nichts.

In der Regel wird Windows neu installiert, indem die Recovery-Funktion verwendet wird, dann gibt es kein Problem. Davon ab beruht meine Aussage, daß auf solchen UEFI BIOS auch die Neuinstallation von Windows problematisch sein kann, auf realen, eigenen Erfahrungswerten.

Ich wage auch zu beweifeln, daß Milliarden Leute milliarden-male Windows neu installieren. Mein Windows 8.1 mußte ich zumindest bis heute nicht neu installieren, ganz im Gegensatz zu den Vorgängerversionen.

Würde Linux nur einen Eintrag nach der Installation rein schreiben, so wie es Windows macht, gäbe es das Problem nicht.

Erstens: Linux schreibt auch nur einen Eintrag bei der Installation hinein. So wie ich es verstanden habe, scheint irgendwie der Schreibauftrag im UEFI festzuhängen, und der Rechner dupliziert dann durch einen Fehler im UEFI den Eintrag selbstständig bei jedem Booten. Zweitens: Da wir keinen Zugriff mehr auf das BIOS haben, ist die Diagnose schwer. Daß es sich hierbei um dieses Problem handelt, ist lediglich eine Vermutung.

BTW: Es gibt/gab auch UEFI, die nur den Booteintrag von MS-Windows akzeptiert haben, oder nur den Booteintrag von MS-Windows und RHEL. Man sieht also, wie hier manche Hersteller gearbeitet bzw. gestümpert haben, "Hauptsache Windows läuft irgendwie, der Rest ist egal". Hinzu kommt, daß die Hersteller bei der Implementierung mit Microsoft zusammen gearbeitet haben, schließlich sollte ja Windows funktionieren. Da kann als Folge sehr gut eine Lösung bei herausgekommen sein, die bei mehr Mainboard-Herstellern funktioniert bzw. deutlich weniger Probleme macht als Linux, die man aber nicht für Linux duplizieren kann, weil Closed Source. Also wurde es bei Linux stur-doof nach UEFI Spezifikation implementiert, was die bekannten Folgen hatte. Mittlerweile sind ja einige Workarounds für bekannte UEFI-Fehler im diesbezüglichen Linux-Code enthalten, aber ob die bzgl. Sorgenfreiheit an die Lösung von Microsoft heranreichen, wage ich zu beschweifeln, daher würde ich (wie schon geschrieben) Linux nach Möglichkeit nur auf akutellen Rechnermodellen im UEFI-Modus installieren. Microsoft hat nun einmal den Luxus, daß die Hersteller mit ihnen zusammenarbeiten müssen, Linux die Last, daß die Hersteller in der Regel nicht mit ihnen zusammenarbeiten wollen.

Soweit ich die Beiträge hier im Forum zu dem Thema verfolgt habe, schreibt aber eben Linux Booteinträge auch ohne Neuinstallation, teilweise bei jedem Start des Notebooks

Mit ist keine Linux-Distribution bekannt, die das so macht.

- - - Beitrag zusammengeführt - - -

Dadurch, dass Linux häufig Einträge ändert tritt das Problem nur schneller auf.

Wieso sollte Linux diese Einträge (häufig) ändern? Bei mir wird lediglich bei der Installation ein einziger Eintrag angelegt.

 

[erDiii]

Ja, ist einer. Die Wahrscheinlichkeit ist gross, dass das BIOS im Winbond steckt (siehe Wiki Artikel). Wie gross ist das ausgepackte BIOS?

Das kann ich dir sagen, wenn ich bei meinem Kollegen bin, weil ich habe keinen weiteren Laptop. Ich sags dir wenn ich soweit bin. Ich warte aktuell auf den Pomona Clip, wenn ich Glück habe ist der am Samstag bei mir.

 

[erDiii]

Gestern war es soweit. Ich habe zuerst die Software installiert, den Raspberry angeschlossen und losgelegt. Bei mir hat flashrom keinen SPI Flash gefunden. Ich habe den Sitz des Pomona Clips geprüft, den Raspberry neugestartet, die Kabel mehrfach kontrolliert und kontrollieren lassen. Die Tage wollte ich versuchen das ganze mit einer externen Stromquelle zu versuchen.

Wie gross ist das ausgepackte BIOS?

Die Bios Größe war genau so groß wie in deiner Anleitung: 40000h (4194304), die Länge von BIOS.BIN war genauso groß.

Ich wuerde es so machen wie dort beschrieben. Wenn es zwei SPI-Flashbausteine gibt, musst Du den CS Pin des anderen Bausteins eventuell auf Vcc ziehen.

Wie muss man das genau machen? Ich habe ein Kabel des CS Pin von dem anderen Baustein an den Vcc Pin vom Winbond gezogen, ist das richtig?

 

[jal2]

Gestern war es soweit. Ich habe zuerst die Software installiert, den Raspberry angeschlossen und losgelegt. Bei mir hat flashrom keinen SPI Flash gefunden. Ich habe den Sitz des Pomona Clips geprüft, den Raspberry neugestartet, die Kabel mehrfach kontrolliert und kontrollieren lassen. Die Tage wollte ich versuchen das ganze mit einer externen Stromquelle zu versuchen.

Ein externe Stromversorgung sollte eigentlich nicht notwendig sein, bei mir hatte der Raspberry immer genug "Saft". Wenn die Schaltung Deines T430u beim SPI der des T430 gleicht, ist da auch eine Diode in die Stromversorgung zum SPI Flash eingebaut, so dass Du nur die SPI-Flashs und nicht den Rest des Mainboard versorgst.

1. Hast Du die Pins am Winbond richtig gezaehlt (Pin 1 am Punkt, gegenueber ist Pin 8!)?
2. Der SPI Flash laeuft mit 3,3V, nicht aus Versehen die 5V des RaspberryPI anlegen!
3. Erst den RaspberryPI mit dem Flash verbinden, danach bestromen - damit es beim Aufsetzen des Ponoma-Clips keinen Kurzschluss gibt.
4. Hast Du einen originalen Ponoma (also einen blauen) oder einen der billigeren schwarzen Nachbauten? Bei letzteren hatte ich auch mal zwei Stueck, mit denen ich keinen Kontakt zum Flash bekam.

Wie muss man das genau machen? Ich habe ein Kabel des CS Pin von dem anderen Baustein an den Vcc Pin vom Winbond gezogen, ist das richtig?

Ja, so habe ich das damals auch gemacht. Ist aber nicht immer notwendig, nur wenn flashrom immer den anderen Baustein erkennt bzw. das Schreiben immer mit einem Verify-Error abbricht.

 

[erDiii]

Sorry das ich erst jetzt antworte, ich war für einige Tage nicht zuhause.

1. Hast Du die Pins am Winbond richtig gezaehlt (Pin 1 am Punkt, gegenueber ist Pin 8!)?
2. Der SPI Flash laeuft mit 3,3V, nicht aus Versehen die 5V des RaspberryPI anlegen.
3. Erst den RaspberryPI mit dem Flash verbinden, danach bestromen - damit es beim Aufsetzen des Ponoma-Clips keinen Kurzschluss gibt.
4. Hast Du einen originalen Ponoma (also einen blauen) oder einen der billigeren schwarzen Nachbauten? Bei letzteren hatte ich auch mal zwei Stueck, mit denen ich keinen Kontakt zum Flash bekam.

1. Die Pins habe ich korrekt gezählt und mehrfach überprüft.
2. Wäre möglich, dass wir 5V angelegt haben

3. Wir haben sowohl davor als auch danach bestromt.
4. Es ist ein original blauer Pomona Clip.

 

[jal2]

Hi,

ich habe das Mainboard von erDiii bei mir auf dem Tisch und weder mit seinem noch mit meinem Ponoma-Clip wird das SPI-Flash erkannt. Danach habe ich mal X-Grabber benutzt und am Chip-Select ein Oszilloskop angeschlossen. Es sieht so aus, als ob es der RaspberryPi nicht schafft, den CS Pin unter 2V zu ziehen. Die Stromaufnahme von 3,3V aus dem Raspi liegt bei ca. 120mA, das sollte fuer zwei SPI-Flash OK sein.
Ich vermute, dass die (unbestromte) Southbridge verhindert, dass CS auf Low geht. Man koennte den Chip ausloeten und separat neu flashen. Hat jemand eine andere Idee?




EDIT: Stromlaufplan des T430u


Update: Der Versuch oben im Bild erfolgte am falschen SPI-Flash, das war der Flash des EC (U19). Das SPI-Flash, das das BIOS enthaelt, befindet sich in der Naehe der Audio-Buchse (U23, Seite 49 im Stromlaufplan, dort fehlerhaft mit 8MByte bezeichnet):



Durch den Kondensator dicht daneben war nicht genug Platz fuer den Ponoma-Clip, deshalb habe ich X-Grabber benutzt.

Update2: erDiii hat das Mainboard getestet, es funktioniert wieder.