Cubietruck mit Igor Debian - Read-only-Filesystem

[PythonF]

Ich habe für meine Hausautomatisierung einen Cubietruck mit folgendem Debian image:
http://www.igorpecovnik.com/2013/12/24/ ... ard-image/
Der Cubietruck hat einen internen Nand-speicher und zzgl noch eine SSD 60GB.
Auf dieser liegt mein Root Dateisystem. Es lief auch alles gut, bis ich etwas geändert habe:
Originalbeitrag aus Heimautomatisierungsforum (da es sich aber um ein Debian problem handelt, wende ich mich an euch)
http://forum.fhem.de/index.php/topic,30440.0.html
-------------------------
Hey FHEM-Forum,
Auch wenn es sich primär um ein Linuxproblem handelt, hoffe ich hier Hilfe zu bekommen.
Ich habe auf meinem Cubietruck mit erfolgreichem FHEM nach folgender Anleitung SmartVISU und smarthome.py (obwohl ich letzters wahrscheinlich nicht benötige) für ein fronthem BETA installiert: https://github.com/mknx/smarthome/wiki/ ... und-1-Wire .
smartVISU lief und lies sich aufrufen. Daraufhin habe ich den Cubietruck neu gestartet. FHEM und smartVISU starteten nicht und liesen sich auch nicht über /etc/init.d/fhem start oder /etc/init.d/smarthome start aufrufen. Es kam die Fehlermeldung

Code: Alles auswählen

Can't open ./log/fhem-2014-12.log: Read-only file system at fhem.pl line 2152.

. Mein Debian läuft auf einer SSD. Bei

Code: Alles auswählen

mount -o remount,rw /dev/sda1

kam die Fehlermeldung

Code: Alles auswählen

mount: can't find /dev/sda1 in /etc/fstab or /etc/mtab

Meine geringen Linuxkenntnisse reichen in meinem aktuellen Wissenstand leider nicht dafür aus, dieses Problem ohne Hilfe zu beheben.
Ich hoffe, ihr könnt mir weiterhelfen.

Zugriff über Putty und dem entsprechend auch pingen ist noch möglich.Es läuft das Igor-Image auf dem Cubietruck.Ein apt-get upgrade habe ich auch ausgeführt.

Hier der auszug aus fstab:

Code: Alles auswählen

# UNCONFIGURED FSTAB FOR BASE SYSTEM
/dev/nand2  /           ext4    defaults,noatime,nodiratime,data=writeback,comm$k,commit=600,errors=remount-ro        0       0
/dev/nand1      /boot   vfat    defaults        0       0 

fstab -l

Disk /dev/nand: 7700 MB, 7700742144 bytes
255 heads, 63 sectors/track, 936 cylinders, total 15040512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/nand doesn't contain a valid partition table

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sda: 60.0 GB, 60022480896 bytes
81 heads, 63 sectors/track, 22973 cylinders, total 117231408 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 2048 117231407 58614680 83 Linux

und falls es weiter hilft hier auch noch:

root@cubietruck:/opt/fhem/contrib/dblog# mount
/dev/root on / type ext4 (ro,noatime,nodiratime,errors=remount-ro,commit=600)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1023328k,nr_inodes=181936,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=131072k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=131072k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
/dev/nand1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=1048576k)

-------------------------------

Ich hoffe, ihr könnt mir weiter helfen. Bei weiteren Fragen, hoffe ich schnellstmöglich zu antworten, da es sich um ein Problem handelt, was ich möglichst schnell gelöst haben möchte.

Beste Grüße
Fabian

[smutbert]

Hi,

hast du beim verschieben/kopieren des /-Dateisystems auf die SSD überhaupt eine Zeile in der fstab dafür hinzugefügt oder eine vorhandene geändert? Die /dev/nand2 … Zeile im Ausschnitt der fstab mountet das /-Dateisystem jedenfalls 100%ig nicht von einer SSD und ich frage mich ob du dein System überhaupt schon tatsächlich von SSD laufen hattest.

(Mit dem internen Speicher (nand) würde ich auch etwas vorsichtiger sein. denn der scheint viele Schreibvorgänge nicht so besonders gut zu verkraften — ich würde eher von deiner µSD Karte booten und das /-Dateisystem dann wahlweise entweder auch darauf oder eben auf die SSD legen.)

Poste doch einmal die komplette fstab (oder war sie das oben schon?) und die Ausgaben dieser Befehle

Code: Alles auswählen

$ cat /proc/cmdline 
# lsblk
# blkid

(das /dev/root aus der Ausgabe von mount hilft - zumindest mir - hier überhaupt nicht weiter…)

[PythonF]

Ich habe das System nach folgender Anleitung, so denke ich, auf die SSD verschoben und zzgl. noch ein resize der Partition auf 60GB durchgeführt, denke ich.
http://www.fhemwiki.de/wiki/Cubieboard_3

Root Filesystem auf SATA Festplatte umziehen (bereits bestehende Installation)

root@cubietruck:~# cat /proc/cmdline
console=tty1 root=/dev/sda1 rootwait loglevel=8 rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=EDID:1280x720p60 panic=10 consoleblank=0
root@cubietruck:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 55.9G 0 disk
└─sda1 8:1 0 55.9G 0 part /
nand 93:0 0 7.2G 0 disk
├─nand1 93:1 0 16M 0 part /boot
└─nand2 93:2 0 7.1G 0 part
root@cubietruck:~# blkid
/dev/nand1: SEC_TYPE="msdos" UUID="59F9-B580" TYPE="vfat"
/dev/nand2: UUID="4393bd51-1586-4500-9be4-b7c308151edf" TYPE="ext4"
/dev/sda1: UUID="4393bd51-1586-4500-9be4-b7c308151edf" TYPE="ext4"

[smutbert]

Auch in der Anleitung fehlt mir das Anpassen der fstab. Poste bitte wirklich die komplette fstab (oder waren die 2 Zeilen oben schon alles?)

[PythonF]

Ja, das war alles, was in /etc/fstab steht:

# UNCONFIGURED FSTAB FOR BASE SYSTEM
/dev/nand2 / ext4 defaults,noatime,nodiratime,data=writeback,comm$
/dev/nand1 /boot vfat defaults 0 0

[smutbert]

Dann hänge /dev/sda1 noch einmal irgendwo anders ein, zB

Code: Alles auswählen

# mkdir /mnt/tmp
# mount /dev/sda1 /mnt/tmp

damit wir sicher sind, die richtige fstab, dh die auf der SSD anzupassen, die liegt danach unter /mnt/tmp/etc/fstab und sollte ungefähr so aussehen

Code: Alles auswählen

/dev/sda1 / ext4 defaults,noatime,errors=remount-ro        0       0
/dev/nand1 /boot vfat defaults 0 0

(die commit=… Option ist nicht notwendig und noatime und nodiratime ist doppelt gemoppelt, also habe ich die Optionen etwas gekürzt)

[PythonF]

Hab jetzt über eine SD-Karte gebootet und die datei folgendermaßen geändert:

# UNCONFIGURED FSTAB FOR BASE SYSTEM
/dev/nand2 / ext4 defaults,noatime,nodiratime,data=writeback,comm$
/dev/nand1 /boot vfat defaults 0 0
/dev/sda1 / ext4 defaults,noatime,errors=remount-ro 0 0

Nach einem poweroff, dem entfernen der SD-Karte und erneutem Start bekomme ich immernoch die Meldung "read-only filesystem"

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted
Welche Auswirkungen auf mein System hat eigentlich diese Fehlermeldung?

[smutbert]

Wenn du die SSD (sda1) wie von mir beschrieben manuell mountest, sollte es egal sein, wie du gebootet hast, aber die Zeile mit nand2 musst du entfernen, sonst gibt es zwei Einträge für / und das wäre einer zu viel.

EDIT
GPT ist ein Partitionierungsschema. Welches du verwendest ist egal, solange es der Kernel versteht. Zum Partitionieren und Anzeigen der Partitionen kannst du statt fdisk einfach gdisk verwenden.

[PythonF]

Der Fehler mit "read-only-Filesystem" bleibt leider bestehn.

Danke für die Info

[smutbert]

und was sagt

Code: Alles auswählen

mount -o remount,rw /dev/sda1

jetzt?

[PythonF]

root@cubietruck:~# mount -o remount,rw /dev/sda1
mount: cannot remount block device /dev/sda1 read-write, is write-protected

Wenn ich ohne microSD-Karte boote.
Beim Start mit microSD kommt folgendes:

Code: Alles auswählen

root@cubietruck:~# mount -o remount,rw /dev/sda1
mount: can't find /dev/sda1 in /etc/fstab or /etc/mtab
root@cubietruck:~# nano /etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
/dev/mmcblk0p1  /           ext4    defaults,noatime,nodiratime,data=writeback,$

[PythonF]

Wenn ich von SD Karte boote kann ich auf der SSD schreiben, wenn ich sie so mounte

mount /dev/sda1 /mnt/tmp

einzige Änderung die ich noch vorgenommen habe, war das ändern der Reihenfolge inerhalb von fstab (copy und paste aus dem Beitrag).
Jetzt funktioniert alles wieder einwandfrei.

Zum Thema nand/SSD/microSD
Meine aktuelle Konfiguration hatte ich ja schon beschrieben.
Ist es sinnvoll daran etwas zu ändern, in Bezug auf Betriebssystem auf der SSD.
Ich ging bis jetzt eigentlich davon aus, dass beim Systemstart die Datei uEnv.txt gelesen wird und daraufhin von SSD gebootet wird?

Kann es sein, dass es am Wechsel der Reihenfolge liegt, dass es wieder funktioniert?
Habt ihr eine Idee, weshalb es vorher auch funktioniert hat, denn eigentlich habe ich an fstab keine Änderungen vorgenommen, die zum Ausfall hätten führen können.

Beste Grüße und Danke für die sehr schnelle Hilfe, vorallem an smutbert!!

Fabian

[smutbert]

Eventuell wurde das Dateisystem auf der SSD nicht sauber geunmountet. Nach der Meldung

Code: Alles auswählen

mount: cannot remount block device /dev/sda1 read-write, is write-protected

wäre die Ausgabe von dmesg interessant gewesen, aber dafür ist es jetzt wohl zu spät. Es könnte nämlich sein, dass das Dateisystem beschädigt war oder ein Fehler mit der SSD aufgetreten ist, der das System dazu veranlaßt hat, das Dateisystem readonly zu mounten und solange das so ist, funktioniert eventuell auch das mit dem remount nicht.

Das Mounten im von der µSD-Karte laufenden System könnte dann das Journal aufgeräumt haben und so den Fehler behoben haben. Die Reihenfolge der Zeilen in der fstab spielt jedenfalls keine Rolle, allerdings muss nach der letzten Zeile ein Zeilenumbruch (!) folgen.


Jetzt brauchst du eigentlich nichts mehr zu ändern, weil die Schreibzugriffe auf das /-Dateisystem sowieso auf der SSD landen. (Ich war nach einigen Berichten im Cubieboard-Forum etwas übervorsichtig und habe den integrierten Speicher gar nicht angerührt und nur von µSD gebootet…)