Spin-Up nach dem Herunterfahren, aber vor dem Abschalten

Hinweis: In dem Thema Spin-Up nach dem Herunterfahren, aber vor dem Abschalten gibt es 12 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Hallo Community,


    seit einigen Tagen tritt ein Fehler auf, der kurz nach der Installation von Leap 42.2 nicht zu bemerken war:


    Fährt man das System über die entsprechenden Buttons des KDE-Menüs herunter, läuft der Shutdown die meiste Zeit ganz normal. Kurz nach dem Spin-Down der Festplatte (SATA, intern) gibt es aber einen teilweisen Spin-Up! Teilweise ist er, weil der Rechner schon vor dem Erreichen der Maximaldrehzahl ausgeschaltet wird.


    Für mich wäre das kein Problem, aber das Parken einer Festplatte geschieht meines Wissens schon länger dadurch, daß nach dem Abschalten der Stromzufuhr die Rotationsenergie in elektrische umgewandelt wird, welche ausreicht, um den Arm in die Parkstellung zu bewegen. Im vorliegenden Fall hat die Platte ihre Nenndrehzahl noch nicht ganz erreicht, daher ist auch nicht die volle Energie vorhanden.


    1. Reicht die Energie geschätzt für den Parkvorgang aus? Zur Zeit ist das wohl der Fall, aber bleibt das auch so?
    2. Wie kann man das Wiederanlaufen verhindern?


    Mit freundlichen Grüßen


    Frank

    Für den Inhalt des Beitrages 101662 haftet ausdrücklich der jeweilige Autor: fvwm2-user

  • Was hast du denn vor einigen Tagen getan, damit dieser "Fehler" auftritt?
    Und warum glaubst du, das sei ein Fehler?
    Vielleicht hast du ja irgendein Ding installiert/konfiguriert, das schlicht ziemlich spät noch mal auf die Idee kommt schreiben zu wollen?


    Und warum sollte es ein Problem sein, wenn die Köpfe mal nicht geparkt werden?
    Ist das ein Notbuch, das du ständig rumwirfst?


    Zudem ist das sehr, sehr hardwarespezifisch.
    Ohne Angabe, was das __exakt__ für eine Platte ist (alleine die Modellnummer ist zu wenig. Es braucht auch Nebenrevisionsnummern und all den Kram.), wird dir niemand verlässliche Aussagen machen können.


    Weil das nun so spezifisch ist, solltest du lieber den Herstellersupport bemühen.


    Selbstverständlich gibt es einige Programme, die dir da helfen könnten.
    hdparm wäre da dein erster Feind.


    Falls du vorhast, das einfach einzusetzen, ohne man hdparm zu studieren, solltest du vorher eine neue Platte besorgen.
    Mit "studieren" meine ich "studieren". Lesen genügt nicht.

  • Es gab ein paar Updates, deren Installation ich dem System erlaubt habe, mehr nicht.


    Installiert oder konfiguriert habe ich ansonsten nichts. Ich wüßte auch kein Programm, was für mich von Interesse wäre, welches zu dem Zeitpunkt des Shutdowns noch schreiben könnte.


    Das Problem bei den Köpfen ist, daß diese glatt sind und auf einem glatten Plattenbereich "kleben bleiben" können. Daher gibt es einen leicht strukturierten Bereich, IIRC gewellt, der das Ankleben verhindert. Dazu müssen die Köpfe aber auch dort ankommen ...


    Die 1-TB-Samsung-Platte ist altgedient, aber wohl kaum altersschwach, sie wird im Wechsel mit einer 1-TB-Seagate für das Arbeitssystem eingesetzt. Zum Ausprobieren, welches das nächste Arbeitssystem wird, dienen zwei 250-GB-Seagates.


    Hierbei ist zu sagen, daß der Vorgänger 13.1 auf die Schnelle installiert wurde, aber leidlich ging, während Leap 42.2 sorgfältiger installiert wurde, wegen guter Einsatzfähigkeit aber auch nicht mehr Zeit gebraucht hat.


    Daß das Problem an der Platte liegt, würde mich wundern, die läuft nach dem Spin-Down doch erst dann wieder an, wenn der Strom aus und wieder eingeschaltet wird oder ein Zugriff erfolgt. Da der Strom bis zum Zeitpunkt des Spin-Ups an geblieben ist, können wir diese Ursache ausschließen, also muß es da einen Zugriff geben, oder ein Ereignis, welches als solcher gewertet wird.


    Vielleicht noch hilfreich: Installation des System 22./23.11.2016, letzte Woche lief der Shutdown noch ganz normal.

    Für den Inhalt des Beitrages 101679 haftet ausdrücklich der jeweilige Autor: fvwm2-user

  • Du liest schon, was man dir so antwortet?
    Ja?
    Glaub ich nicht.
    Lies es bitte nochmal.


    Und bitte -falls du weiterhin hartnäckig meinst, ein Update hätte das fabriziert- poste doch bitte das zypper Log.
    Und, was journalctl noch kennt, bevor es verstummt.
    (Mag sein, dass du das Systemlog erst persistent konfigurieren musst)

  • Offensichtlich lese ich das, sonst würden meine Antworten nicht in der Reihenfolgen kommen wie Deine Fragen.


    zypper.log und die letzten Ausgaben von journalctl vor dem Abschalten poste ich, wenn ich weiß, wie man sie in einem Extra-Fenster anzeigen lassen kann, ohne Zeilennummerierung. Sollte letztere hilfreich sein, sollte die Code-Funktion ausreichen, oder?


    Daß die Platte nach Jahren ohne Probleme ganz von allein startet, kurz nach den ersten Systemupdates eines neuen Betriebssystems (die haben relativ lange auf sich warten lassen), kommt mir als Hardwarefehler unwahrscheinlich vor.


    Mit freundlichen Grüßen


    Frank

    Für den Inhalt des Beitrages 101776 haftet ausdrücklich der jeweilige Autor: fvwm2-user

  • Was hast du gegen die Zeilennummerierung der Code-Tags??

    Für den Inhalt des Beitrages 101778 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Die Anzeige ist wie sie ist. Es gibt keine andere. Das ist systemspezifisch bei Burning Board. Wenn du magst, beschwere dich bei WoltLab.
    Wenn du mit Zeilennummerierung nichts posten möchtest ... sry .. deine Entscheidung. Dann wird es mit Hilfe aber auch schwer bis unmöglich.

  • Offensichtlich lese ich das, sonst würden meine Antworten nicht in der Reihenfolgen kommen wie Deine Fragen.

    Die Reihenfolge in der Post hier erscheinen hängt garantiert nicht davon ab,
    ob und wann du etwas liest.
    Es gibt kein Forum-to-!userbrain Interface.


    Wenn das nochmalige Lesen nicht hilft,
    kannst es ja mal mit Lesen&Verstehen versuchen.

  • @Sauerland und Alero: Ich habe nichts gegen die Nummerierung, hatte aber die Befürchtung, die könnte Verwirrung verursachen.


    Berichtigung: zypper.log ist 331 KB lang, zu lang für Code (und jeden Leser).


    journalctl (gekürzt): Nachricht geht nur bis 10000 Zeichen, auch mit Code. Die gekürzte Version der Ausgabe von journalctl hat ca. 24 KB, was nun?


    Vielleicht noch ein paar Angaben zum (Eigenbau-)System:
    Miditower mit AMD Phenom II Vierkerner @3 GHz, 4 GB RAM, 1-TB-Samsung-3,5"-Platte, openSUSE Leap 42.2 64bit, Filesysteme nach Vorschlag: BTrFS für /, XFS für /home

    Für den Inhalt des Beitrages 101794 haftet ausdrücklich der jeweilige Autor: fvwm2-user

  • Miditower mit AMD Phenom II Vierkerner @3 GHz, 4 GB RAM, 1-TB-Samsung-3,5"-Platte, openSUSE Leap 42.2 64bit, Filesysteme nach Vorschlag: BTrFS für /, XFS für /home

    zweifelhaft, ob da ein Maxitower etwas geändert hätte.


    um etwas mehr über deine Festplatte und ihren Gesundheitszustand zu erfahren gibt es immer 2 Anlaufpunkte
    1. hdparm
    2. S.M.A.R.T


    für das 2. installiere dir bitte die smartmontools

    Code
    zypper in smartmontools


    wie du das erledigt hast liest du mal ein bisschen bei ubuntu und gibst für eine erste Übersicht ein

    Code
    smartctl -a /dev/sda


    vielleicht siehst du irgend etwas interessantes dabei
    ----------
    für 1. brauchst du nichts zu installieren. Du gibst als root einfach ein:

    Code
    hdparm -I /dev/sda

    dann weißt du alles, was die Platten über sich selbst wissen.
    Im Zweifelsfall stellst du das Ergebnis hier ein.

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 101801 haftet ausdrücklich der jeweilige Autor: wurzel99