Lange Startzeiten bei Openlec 3.2.4

  • Hallo,

    ich habe noch nicht mal die Videodatenbank eingebunden und nur eine externe Festplatte dran. Und Openelec braucht je nach Gemütszustand 30-200 Sekunden zum starten vom XBMC. Betreibe mit eine guten SD Karte und schnellen USB Stick (Storage) den Pi. In der cmdline.txt steht boot=/dev/mmcblk0p1 disk=/dev/sda1 ssh quiet

    Jemand Tipps ?

    Mfg

  • Sicher, dass der USB Stick sda1 ist?
    Ich verstehe echt nicht, warum so viele User scheinbar vor der Benutzung von LABEL oder UUID Angst haben. Manchmal erstpart das einiges an Fehlersuche. Und gerade die Verwendung von LABEL ist so einfach und dennoch (relativ) sicher im Gegensatz zu sdX...

    Gruß

    P.S.: 30s sind als Startzeit garnicht schlecht :) Aber ich gebe Dir Recht: Es sollte dauerhaft so sein und nicht nur sporadisch.

    OpenELEC 5.0 Final (5.0.7 / 5.0.8 github) | SolidRun CuBox-i4Pro (CPU: ARM Cortex A9 | GPU: Vivante GC2000)
    Kein kodi.log => Kein Support! | Spendier' mir ein Bier!

    Einmal editiert, zuletzt von root2 (6. März 2014 um 13:49)

  • Klar, gerne :)

    Im Grunde geht es darum, dass man sich eine unnötige (und vermeidbare) Fehlerquelle einhandelt, wenn man nur die Angaben übernimmt, die in diversen Posts geistern, à la "disk=/dev/sda1"

    Schau doch mal hier vorbei. Vielleicht hilft Dir das schon etwas weiter.

    Es ist nicht so, dass die obige Lösung Quatsch ist und nicht funktioniert. Genausowenig stellt mein vorschlag ein Allheilmittel gegen Boothänger dar. Aber es ist halt nach obiger Herangehensweise nicht so sicher, wie die Verwendung von LABEL oder UUID zum Einbinden der Storage Partition.

    Gruß und viel Erfolg!

  • Da sage ich mal besten Dank, scheint dadurch jetzt besser zu laufen !

    Wie kriege ich die UUIDs der verwendeten Partitionen raus und binde die in die cmdline.txt ein ?


    Fein, dann hoffen wir doch mal, dass es so bleibt ;)

    Zur Sache mit der UUID:
    Am einfachsten geht das an einem PC mit Linux.

    Dazu den USB Stick bzw. die Festplatte anstecken und dann gleich danach mit dmesg den Kernel-Ringpuffer anzeigen lassen:
    Dabei werden wohl auch ein paar unnötige Zeilen mit ausgegeben, die letzten sollten aber die interessanten sein. und könnten in etwa so aussehen:

    Code
    ...
    [288856.370550] sd 20:0:0:0: Attached scsi generic sg6 type 0
    [288856.372351] sd 20:0:0:0: [sde] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
    [288856.372747] sd 20:0:0:0: [sde] Write Protect is off
    [288856.372750] sd 20:0:0:0: [sde] Mode Sense: 33 00 00 08
    [288856.373247] sd 20:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [288856.375640]  sde: sde1
    [288856.376758] sd 20:0:0:0: [sde] Attached SCSI disk

    In diesem Beispiel ist der neu hinzugefügte USB Datenträger als sde (/dev/sde) erkannt worden.

    Als nächstes folgendes eingeben:

    Code
    ls -l /dev/disk/by-uuid/ | cut -d' ' -f 9- | grep sde


    oder falls es nicht funktioniert die etwas einfachere Variante:

    Code
    ls -la /dev/disk/by-uuid/ | grep sde

    Das Ergebnis sollte etwas in dieser Art sein (wenn das vorherige ls in Verbindung mit dem cut nicht funktioniert hat und der untere Befehl verwendet wurde, wird noch etwa mehr an Info dabei stehen aber die UUID sollten dennoch da sein):

    Code
    030B-869C -> ../../sde1
    b81e5013-98e1-4f24-8dd4-2751b28b02d1 -> ../../sde2

    Die beiden Zeichenketten sind die UUIDs der in diesem Fall vorhandenen Partitionen auf dem USB Laufwerk:
    Die UUID von /dev/sde1 (der FAT32 "Boot" Partition) ist 030B-869C
    Die UUID von /dev/sde2 (der EXT4 "Storage" partition) ist b81e5013-98e1-4f24-8dd4-2751b28b02d1

    Die UUIDs können dann in die cmdline.txt wie folgt eingebunden werden:

    Code
    boot=UUID=030B-869C disk=UUID=b81e5013-98e1-4f24-8dd4-2751b28b02d1 quiet

    Ich hoffe das war verständlich genug.

    Gruß

Jetzt mitmachen!

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