In der cmdline.txt.hdd steht
root=PARTUUID=BE9E2BE4-36E8-494E-A025-E3AA4A3F6B0D
In der /etc/fstab steht
PARTUUID=F89B1E92-CB3E-4BF3-843E-A7C731F62CDF
Das war ein Fehler von mir. Waren zu dem Zeitpunkt identisch. Sorry! aber hier steckt das Problem mit der Schreibberechtigung.
Die PARTUUID muss identisch sein. Du bekommst sie mit
sudo sgdisk -i 1 /dev/sda | grep unique | cut -d ' ' -f 4
heraus. Welche UID bekommst Du raus? Das solltest Du korrigieren und noch mal versuchen Deine Pi zu starten.
c64emulator hat hier von Problemen mit einer read only gemounteten SD Platte berichtet. Seine Lösung war UUID und nicht PARTUUID zu benutzen. Mir scheint Du hast ein ähnliches Problem. Keine Ahnung warum ich das bei mir nicht nachvollziehen kann :s
Habe übers Wochenende mal etliches probiert und folgendes herausgefunden:
Es ist nicht egal, mit welchem Rechner du die UUID ermittelst (Laptop, Lenovo W520 mit Mint 17.3 oder dem RasPi). Und es spielt eine Rolle wie du sie ermittelst (mit 'blkid' oder 'sgdisk'). Weiter spielt die Groß-/Kleinschreibung eine Rolle.
Habe alle möglichen Kombinationen durchexerziert.
Ergebnis:
In der 'cmdline.txt' steht die mit
sudo sgdisk -i 1 /dev/sda | grep unique | cut -d ' ' -f 4
ermittelte UUID als PARTUUID benannt in Großbuchstaben.
... root=PARTUUID=F89B1E92-CB3E-4BF3-843E-A7C731F62CDF ...
In der 'fstab' steht die auf dem RasPi mit
blkid | grep sda1 | cut -d ' ' -f 4
ermittelte PARTUUID ohne "" in Kleinbuchstaben.
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot vfat defaults 0 2
#
# PARTUUID= mit 'blkid' auf dem Pi ermittelt
# /dev/sda2
PARTUUID=49bb85a7-d5a8-4f9a-920c-de82d6cfc6af none swap sw 0 0
# /dev/sda1
PARTUUID=f89b1e92-cb3e-4bf3-843e-a7c731f62cdf / ext4 defaults,noatime 0 1
# /dev/sda3
PARTUUID=228dde32-5511-45c3-beb9-235482ebc5c6 /home ext4 defaults,noatime 0 0
In dieser, und nur in dieser Kombination habe ich ein bescheibbares System.
Hier habe ich noch den rootdelay Parameter erwähnt. Den würde ich auch noch mal mit aufnehmen.
Den Parameter 'rootdelay' habe ich probiert aber ohne spürbares Ergebnis und darum erst einmal weggelassen.
:thumbs1: Erstmal einen ganz, ganz herzlichen Dank für die bis hierher geleistete Hilfe und Unterstützung! :thumbs1:
Ein ebenso großes Problem ist aber geblieben unabhängig von meinen Versuchen mit dem Schreibschutz.
Das Teil ist nach dem Umstieg auf das USB-Laufwerk lahm wie eine Schnecke geworden.
Start mit reiner SD-Card < 10 sec.
Jetzt mit USB-HDD bei 1Min 38 sec bis zum Prompt.
Der Aufruf der GUI dauert, nach Eingabe von 'startx' geschlagene 3Min, bis das Menü bedienbar ist.
Der Aufruf von 'shutdown' dauert von Menü-Anklicken bis zum Dialog 'End Session' 20 sec.
Beim Start von OpenOffice kann man einen Kaffee trinken gehen.
Leider kann ich nicht sehen, was der Rechner die ganze Zeit macht und ich habe auch keine Ahnung, wie dem bei zu kommen ist.
Nach der Beendigung der GUI zum Prompt habe ich den Bildschirm fotografiert. Das Bild und das benannte Protokoll habe ich mal im Anhang angefügt.
Über Hilfe zu diesem Problem würde ich mich seeeehr freuen.
Gruß reinhard
PS.: Mir ist aufgefallen, dass immer nur der 1. Aufruf eines Programmes so zeitintensiv ist. Werden denn bei jedem Programmstart Daten im Cach angelegt?
Ist das auf der SD auch oder erst mit der USB-HDD? Wenn ja, warum? Kann man das Abschalten? Wenn das auf der SD nicht aktiv ist braucht man es auf der HDD genau so wenig. Gilt das auch für den Systemstart? Ist deswegen das booten so langwierig?
Frage, Fragen, Fragen ....