6110: Hartverdrahtete Probleme lösenSeit Debian Lenny gibt es Probleme, die von Suspend-Logiken verursacht werden, wenn ein Migriertes System die SWAP-Partition an einer geänderten Position vorfindet. Das Booten in einer neuen Umgebung wird dann von folgendem Dialog unterbrochen:
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... resume: libgcrypt version: 1.4.1
resume: Could not stat the resume device file '/dev/sda14'
Please type in the full path name to try again
or press ENTER to boot the system:
Was ist passiert? Nun, in diesem Beispiel wurde ein Template auf einem System erstellt, dessen SWAP-Partition sich auf "/dev/sda14" befand. Dieses Template wurde später auf einem System eingespielt, dessen SWAP-Partition sich nun auf "/dev/sda12" befindet. Die Information "/dev/sda14" ist aber leider hart verdrahtet und wird seit Lenny nun auch tatsächlich bei jedem Booten benutzt. 1. AbhilfeGenerell ist es nützlich, das Unterverzeichnis "/etc" immer dann nach der Partitionsbezeichnung der SWAP-Partition zu durchsuchen, wenn sich die Position der SWAP-Partition bei einer Migration ändert. Dazu können Sie die Suchfunktion des Midnight-Commanders verwenden. Konkret lösen Sie das Problem, wenn sich die Position der SWAP-Partition ändert, wie folgt:
Den entscheidenden Hinweis, wie das Problem behoben werden kann, habe ich aus zwei alten Diskussionen (geführt in den Jahren 2008 und 2007) entnommen, die ein Teilnehmer mit dem Namen "pluvo" mit anderen Diskussionsteilnehmern geführt hatte:
2. Weitere Recherche-Ergebnisse und EinsichtenDas hier aufgestoßene Thema kam für mich völlig überraschend. Eigentlich wollte ich nur mal schnell ein weiteres produktives System von Etch auf Lenny bringen, weil es einfach nur noch öde ist, sich mit Problemen herumschlagen zu müssen, die nur deshalb auftreten, weil das laufende System 3 Jahre alt ist und dementsprechend hoffnugslos veraltet. Doch statt nun endlich zügig das Template einspielen und das System maßschneidern zu können, artete diese Aktion zu einer weiteren über mehrere Tage verteilten Recherche-Aktion aus. Was ich hierbei gelernt habe, werde ich, wenn ich mich um Squeeze kümmern werde, in das Gesamtkonzept einfließen lassen müssen, denn die in Kapitel 1 gemachten Vorschläge kurieren ja nur Symptome, nicht aber die Ursachen. 2.1. Recherche-ErgebnisseHier trage ich zusammen, was ich sonst noch so finde. 2.1.1. Ist ein Resume-Device eigentlich sinnvoll?
Nein! Dieser Link hier erklärt sehr anschaulich, warum ein Resume-Device ziemlicher Käse ist: http://forum.ubuntuusers.de/topic/etc-initramfs-tools-conf-d-resume-ohne-resume/ Hier stehen vor allem 2 Argumente, die gegen ein Resume-Device sprechen:
2.2. EinsichtenUnd hier trage ich zusammen, welche Empfehlungen ich aus den oben aufgelisteten Recherche-Ergebnissen in künftigen Versionen von "Debian für Unternehmer" ableiten werde. 2.2.1. Ist ein Resume-Device eigentlich sinnvoll?
Besonders dann, wenn Ihr System eigentlich gar kein SWAP-Device hat (Stichwort Rettungsfestplatte), wäre dementsprechend auch gar keine SWAP-Partition da, die als Resume-Device missbraucht werden könnte. Konsequenz: Sagen Sie dem Initramfs-Image, dass es sich um Resume-Devices nicht kümmern soll. Dazu öffnen Sie die Datei "/etc/initramfs-tools/conf.d/resume": nedit /etc/initramfs-tools/conf.d/resume Kommentieren Sie den dort befindlichen Eintrag mit einem "#" aus. Im hier genannten Beispiel würde die Aktion so aussehen: Vorher
RESUME=/dev/sda14 Nachher
# RESUME=/dev/sda14 Sie müssen nun noch das Initramfs-Image aktualisieren, damit Ihre Änderungen in der Datei "/etc/initramfs-tools/conf.d/resume" in das Image hingelangen: update-initramfs -u 2.2.2. Wozu eigentlich muss "userspace software suspend" laufen?
Wenn die Software Uswsusp gar nicht gebraucht wird, sondern ihre Existenz nur Probleme verursacht, dann empfehle ich, sie am besten gleich zu deinstallieren: apt-get remove uswsusp --purge Ich habe diese Aktion jetzt (25.04.2010) nicht getestet, kann also nicht sagen, welche Folgen sie haben wird. Aber künftig (Squeeze), werde ich sie wohl standardmäßig empfehlen, besonders dann, wenn das Ziel wichtig ist, ein schlankes System zu erstellen, also ein managebares System ohne unnötigem Firlefanz. 2.2.3. Argument gegen Suspending aus Sicht der Datenkonsistenz
Es ist praktisch nicht mehr möglich, nur noch mit einem Betriebssystem alle im täglichen Leben anstehenden Aufgaben zu erledigen. Einfachstes Beispiel:
Multiboot ist daher aktuell die Regel. Mit den Bordmitteln von Lenny kann Multiboot um Virtualisierung ergänzt (nicht ersetzt, sondern nur ergänzt) werden. Wenn aber in einer Multiboot-Umgebung verschiedene Betriebssysteme auf die gleichen Daten zugreifen, dann werden Suspend-Logiken ganz schnell zu einem unkalkulierbaren Risiko. Warum? Selbst wenn Sie es schaffen würden, jedem System einen eigenen SWAP-Bereich zuzuweisen, damit die Systeme sich gegenseitig die ausgelagerten RAM-Inhalte nicht überschreiben, wäre es denkbar, dass Sie vor dem Suspenden verschiedene Dateien offen haben, vielleicht sogar im Schreib-Modus. Sie können sich sicherlich denken, was passieren wird, wenn verschiedene Systeme die gleichen Dateien jeweils im Schreib-Modus bearbeiten und zu willkürlichen Zeitpunkten mal eben schlafen gelegt werden. Falls nicht, hier kommt die Antwort: Sobald ein System aus dem Tiefschlaf erwacht, haben sich die Inhalte der betroffenen im Schreib-Modus geöffneten Dateien bereits verändert. Die so entstehende Dateninkonsistenz ist in Produktivumgebungen nicht wirklich lustig.
|