Diskless client und sata device

    Das mit /dev/disk/by-uuid/ kannte ich noch garnicht. Super, wieder was gelernt.


    Donkey-Kong, dann ist das ja wirklich super einfach...

    Server: E35M1-M PRO, AMD E-350, Octopus DVB Adapter, vdr-2.3.1, streamdev-server, epgsearch, vdrmanager, vnsiserver

    Client: vdr, xinelibout, streamdev-client, (total outdated)

    devnix


    Mensch, damit habe ich jetzt nicht mehr gerechnet. Die man von hdparm hatte ich mir aber durchgelesen und denn y Parameter habe ich dann zwecks Masse überlesen. Er war ja auch relativ weit unten ;-). Ich wusste ohne deinen Tip sowieso nicht, wie ich ihn benutzten sollte. Ich habe es jetzt dann auch gleich mal getestet.


    Super Vielen Dank


    Donkey-Kong

    hi


    leider musste ich feststellen, das die udev Regel bei sda nur einmal funktioniert hat. Die Platte kam in den letzten paar Stunden 2 mal mit sda hoch und die udev Regel hat nur einmal funktioniert. Jetzt bleibt nur noch die lösung von devnix.


    Nochmal Danke an devnix


    Gruß Donkey-Kong

    hi
    ich bin manchmal etwas zu schnell mit meinen Aussagen (ist bei meinen Kollegen bekannt). Der manuelle Eintrag im Terminal.


    sudo hdparm -y /dev/disk/by-uuid/e0fe1b49-f40a-4a36-9266-05e9cc333dfa
    funktioniert zwar, aber der gleiche Eintrag in /etc/rc.local funktioniert nicht. rc.local läuft zwar durch (was es bei einem Fehler nicht macht), aber die Kontrolle sagt die Platte ist active/idle.


    für jeden weiteren Tip bin ich dankbar


    Donkey-Kong

    Naja, sobald Du die Platte irgendwie anfässt (mounten, nach Partitionen suchen, lesen/schreiben usw.) ist sie natürlich sofort wieder aktiv. Des weiteren muss auch erst udev voll aktiv sein, damit die "by-uuid"-links erstellt werden.


    PS: Du hat in der rc.local auch schon auf das sudo verzichtet, oder?

    Server: E35M1-M PRO, AMD E-350, Octopus DVB Adapter, vdr-2.3.1, streamdev-server, epgsearch, vdrmanager, vnsiserver

    Client: vdr, xinelibout, streamdev-client, (total outdated)

    @Werewolf


    ich versuche es gerade mit hdparm -y etc, da die udev Regel nicht zuverlässig funktioniert. Wenn ich da keine Lösung finde, probiere ich die udev Regel nochmal und baue noch ein sleep x in die rc.local.


    Der Befehl steht ohne sudo in der rc.local. Was mich nur wundert, wenn ich im Terminal den Befehl


    sudo hdparm -y /dev/disk/by-uuid/e0fe1b49-f40a-4a36-9266-05e9cc333dfa absetze und danach mit
    sudo hdparm -C /dev/sde den Status auslese bekomme ich
    /dev/sde: drive state is: standby


    wenn ich aber den Rechner starte und ich danach mit
    sudo hdparm -C /dev/sde den Status auslese bekomme ich
    /dev/sde: drive state is: active/idle


    Gruß Donkey-Kong

    Mal als Linux Anfänger in den Raum geworfen:
    Wieso eigentlich mit dem herausfinden des richtigen Gerätes herumärgern, wenn außer der einzigen Festplatte nur ein Cardreader im System steckt der den Befehl sowieso nicht entgegen nimmt.


    Code
    find /dev -name sa[abcdefg] -exec hdparm -y {} \;

    vdr (1.7.15/1.7.15) streamdev-server (0.5.1) skincurses (0.1.9) infosatepg (0.0.11) extrecmenu (1.2) epgsearch (0.9.25.beta17) femon (1.7.8) text2skin (1.3.1) streamdev-client (0.5.1) xineliboutput (1.0.90-cvs) live (0.2.0) noad (0.7.2)
    Suse (11.3) linux (2.6.34.8-0.2)

    Donkey-Kong


    Meine Bemerkung mit udev ziehlt darauf, an welcher Stelle im Boot-Prozess deine "rc-local" ausgeführt wird. Ich kenne ja dein System nicht.
    Grund: Dieser Link unter /dev wird vermutlich von udev bereitgestellt, und wenn das halt noch nicht vollständig gestartet ist, gibts den Link auch nicht -> Dein hdparm rennt ins Leere


    Eine zweite Möglichkeit ist, das im Laufe des Boot-Prozesses bzw. auch danach aus irgendeinem Grunde nochmal auf die Festplatte zugegriffen wird. So kann ein durchaus erfolgreich abgesetzter hdparm-Befehl durch das erneute hochfahren der Platte ausgehebelt werden.


    Am besten Du leitest die ausgaben mal in eine Log-Datei um (ggf auch direkt ein "hdparm -C" hinterher



    G-SezZ
    Kann man so machen, ist aber ziehmlich unsauber. Generell hab ich die Erfahrung gemacht, das einem diese Art von "Problemlösungen" früher oder später auf die Füsse fallen.

    Server: E35M1-M PRO, AMD E-350, Octopus DVB Adapter, vdr-2.3.1, streamdev-server, epgsearch, vdrmanager, vnsiserver

    Client: vdr, xinelibout, streamdev-client, (total outdated)

    @Werewolf


    In bin jetzt mal auf deine 2. Möglichkeit eingegangen und habe in der rc.local einen sleep 10 noch vorangestellt und sie da, es funzt. Hurra !!!
    Also ein Eintrag in der rc.local mit


    sleep 10
    hdparm -y /dev/disk/by-uuid/e0fe1b49-f40a-4a36-9266-05e9cc333dfa


    hat den Erfolg gebracht. Naja, nach drei Neustarts. Ich teste es die Tage noch ein paar mal, bevor das Thema entgültig gelöst ist.


    Danke schon mal an alle die mich unterstützt haben


    Gruß Donkey-Kong


    Edit: Ich glaube mit slepp x hätte dann die udev Regel zuverlässiger funktioniert.

    Einmal editiert, zuletzt von Donkey-Kong ()

    Zitat

    Original von Donkey-Kong
    Edit: Ich glaube mit slepp x hätte dann die udev Regel zuverlässiger funktioniert.


    Die udev Regel funktionert mit Sicherheit zuverlässiger! Und zwar genau deshalb, weil UUIDs, wie schon weiter oben erwähnt, ein Feature der jeweiligen Dateisysteme sind (deshalb tauchen in by-uuid auch nur Partitionen auf, aber nicht die Platte selbst). Erzeugst Du also ein neues Dateisystem, bekommst Du auch eine neue UUID. In der udev Regel kannst Du aber Eigenschaften der Platte direkt abfragen (wie z.B. Seriennummer, Modell, Hersteller, usw.). Die ändern sich i.d.R. nie!


    Bye...


    Dirk

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden