[mascha]

Hallo Claus,

ich habe das Ganze nun noch einmal nachvollzogen (durchgeführt am 11.09.).

• Installation initramfs → Installation funktioniert nun
• Noch update der Pakete init und rpi → Reboot Raspberry
• Strom weggenommen (mehrmals). 23:53 Uhr endlich Erfolg: Er bootet nicht mehr (Konsole s. Bild im Anhang)
• btrfs check /dev/sdd2 (ohne repair!):

Code: [Select]

...
bad metadata [218415104, 218431488) crossing stripe boundary
bad metadata [238796800, 238813184) crossing stripe boundary
bad metadata [254722048, 254738432) crossing stripe boundary
bad metadata [254787584, 254803968) crossing stripe boundary
bad metadata [255180800, 255197184) crossing stripe boundary
bad metadata [255246336, 255262720) crossing stripe boundary
bad metadata [258195456, 258211840) crossing stripe boundary
bad metadata [258260992, 258277376) crossing stripe boundary
bad metadata [258457600, 258473984) crossing stripe boundary
bad metadata [270123008, 270139392) crossing stripe boundary
bad metadata [287358976, 287375360) crossing stripe boundary
Errors found in extent allocation tree or chunk allocation
checking free space cache
checking fs roots
checking csums
checking root refs
found 431951874 bytes used err is 0
total csum bytes: 394084
total tree bytes: 28409856
total fs tree bytes: 26591232
total extent tree bytes: 1163264
btree space waste bytes: 6014027
file data blocks allocated: 1117925376
referenced 1040932864
btrfs-progs v4.2+20150903

• mount /dev/sdd2 /mnt → konnte mounten und Verzeichnisse lesen
• btrfs check /dev/sdd2 → Ergebnis:

Code: [Select]

...
bad metadata [254722048, 254738432) crossing stripe boundary
bad metadata [254787584, 254803968) crossing stripe boundary
bad metadata [255180800, 255197184) crossing stripe boundary
bad metadata [255246336, 255262720) crossing stripe boundary
bad metadata [258195456, 258211840) crossing stripe boundary
bad metadata [258260992, 258277376) crossing stripe boundary
bad metadata [258457600, 258473984) crossing stripe boundary
bad metadata [270123008, 270139392) crossing stripe boundary
bad metadata [287358976, 287375360) crossing stripe boundary
Errors found in extent allocation tree or chunk allocation
checking free space cache
checking fs roots
checking csums
checking root refs
found 433418242 bytes used err is 0
total csum bytes: 395516
total tree bytes: 28409856
total fs tree bytes: 26591232
total extent tree bytes: 1163264
btree space waste bytes: 6012072
file data blocks allocated: 1119391744
referenced 1042399232
btrfs-progs v4.2+20150903

• Mount SD-Karte und Edit einer Datei auf der SD-Karte
• Ohne Reparatur in Rasperry gesteckt → Raspberry bootet wieder.

D.h. durch die Verwendung der SD-Karte am PC wurden die Fehler zwar nicht korrigiert, dennoch wurde irgendetwas durch die neuere BTRFS-Progs-Version geändert, so das die Karte dann wieder am Raspberry bootet.
Matthias

[fadi1]

Hallo
Ich habe auch immer wieder einmal das Problem mit dem Btrfs-file-system
(besonderst wenn meine Frau das FS innerhalb von 0.5sec zerstört) 

Ich habe dann versucht die Speicherkarte in Yavdr zu mounten.

Code: [Select]

root@vdr-server:/home/user# mount /dev/sdd2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sdd2,
       missing codepage or helper program, or other error
       Manchmal liefert das Syslog wertvolle Informationen â versuchen
       Sie  dmesg | tail  oder so

root@vdr-server:/home/user#

dmesg | tail

Code: [Select]

[ 1888.330702] device fsid ddf31082-bf1a-4e9f-8273-751f2b2da08c devid 1 transid 991 /dev/sdd2
[ 1888.331681] btrfs: disk space caching is enabled
[ 1888.331687] BTRFS: couldn't mount because of unsupported optional features (20).
[ 1888.348029] btrfs: open_ctree failed



und auch das Reparieren funktioniert nicht

root@vdr-server:/home/user# btrfsck /dev/sdd2
couldn't open because of unsupported option features (22).
btrfsck: disk-io.c:679: open_ctree_fd: Assertion `!(1)' failed.
Abgebrochen

danach nochmal probiert zu booten -> leider nicht

lg
Fadi1

[fadi1]

Hallo
nachdem ich den MLD erneut aufgesetzt habe das dank Backup schnell geht ist mir ein möglicher Fehler aufgefallen

Code: [Select]

mld> fdisk -l

Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
64 heads, 32 sectors/track, 7580 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

        Device Boot      Start         End      Blocks  Id System
/dev/mmcblk0p1               2          97       98304   b Win95 FAT32
/dev/mmcblk0p2              98        7580     7662592  83 Linux


Fdisk zeigt mir so die Laufwerks Namen
/dev/mmcblk0p1,  /dev/mmcblk0p2 

mount zeigt mir wie die Laufwerke eingebunden werden
nur wird dabei /dev/mmcblk0p2 2x mit unterschiedlichen Pfaden gemountet
das ist mir Neu und ich wundere mich das das überhaupt geht. Normalerweise kommt ja wenn man das manuell versucht die Meldung "the device is busy"

Code: [Select]

mld> mount
/dev/mmcblk0p2 on / type btrfs (rw,relatime,ssd,noacl,space_cache)
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
tmp on /tmp type tmpfs (rw,relatime)
run on /run type tmpfs (rw,relatime)
dev on /dev type devtmpfs (rw,relatime,size=369568k,nr_inodes=92392,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
log on /var/log type tmpfs (rw,relatime)
/dev/mmcblk0p1 on /media/SL08G-mmcblk0p1 type vfat (rw,relatime,gid=100,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/mmcblk0p2 on /mnt/data type btrfs (rw,relatime,ssd,noacl,space_cache)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
/etc/auto.dvd on /mnt/autofs type autofs (rw,relatime,fd=6,pgrp=1366,timeout=3,minproto=5,maxproto=5,indirect)
/etc/auto.net on /net type autofs (rw,relatime,fd=12,pgrp=1366,timeout=60,minproto=5,maxproto=5,indirect)
172.30.1.14:/srv/share/vdr on /mnt/data/tv/server type nfs (rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nolock,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=172.30.1.14,mountvers=3,mountproto=udp,local_lock=all,addr=172.30.1.14)
mld>


könnte ja sein das das der Fehler ist.
mir ist auch aufgefallen das der Fehler immer passiert wenn man etwas Umkonfiguriert. Dabei bleibt plötzlich das Systen hängen und nach dem harten auschalten Bootet der MLD nicht mehr

lg
fadi1

[clausmuus]

Ich bin hier inzwischen ein wenig weiter. Bei meinen Tests habe ich herausgefunden, dass sich ein beschädigtes btrfs Filesystem auf einem x86'er auch unter MLD problemlos mounten lässt. Ein MLD RPI hingegen bleibt einfach hängen, wenn man versucht das zu mounten. Es gibt keine Fehler Logs, sondern nur Logmeldungen nach denen das mounten erfolgreich war.
Der RPI Kernel ist etwas neuer als der x86'er Kernel. Die Kernel Version sollte demnach nicht schuld sein. Das btrfs ist bei beiden Kerneln identisch konfiguriert.
Aktuell stehe ich also etwas auf dem Schlauch...

Claus

Notitz: Dies sieht wie unser Problem aus: https://www.reddit.com/r/linux/comments/31s042/current_stable_kernels_3194_may_fail_to_mount/
Eventuell können wir auf den 4.1'er Kernel wechseln?

[clausmuus]

Hab's jetzt überprüft. Es ist tatsächlich der Bug im Kernel btrfs Treiber. Ich hab jetzt die initramfs um nen hotfix erweitert, der das Problem umschifft, bis wir auf nen neueren Kernel gewechselt sind, der den Fehler nicht mehr hat.

Ein upgrade der initramfs bei einer Installation nach dem 22.8. behebt das Problem (wenn mir kein Fehler unterlaufen ist).

Claus

[LarsX]

Ein Upgrade der initramfs bei einer Installation nach dem 22.8. behebt das Problem (wenn mir kein Fehler unterlaufen ist).

Wenn die MLD vor dem 22.8. auf dem Raspi installiert wurde, kann man das Problem nicht durch Upgrade des initramfs-Pakets lösen - im Sinne von verhindern? Das verwirrt mich.

[clausmuus]

Bei älteren Installationen muss Hand angelegt werden, da bei diesen Systemen die initramfs noch nicht zum booten verwendet wurde.
Wer ein solches System mit Problemen hat soll sich bei mir melden, dann beschreibe ich wie das umgestellt wird.

Claus

[Tommes]

Moin Moin,

Sorry, aus aktuellem Anlass möchte ich das Thema nochmal vorholen.

Kann es sein, daß das Problem
"Hartes Abschalten" --> "Kein Boot mehr"
immernoch besteht oder zumindest bei schlechter Bedienung noch auftreten kann ?

Ich habe mir inzwischen 3 funktionierende Installationen verheizt,
nun ist das System hin, das Backup und das Backup vom Backup auch
Man könnte sagen, ich gucke in die Röhre, da Neu-Installieren im Moment an der FB scheitert 

Irgendwie habe ich da BTRFS im Verdacht, daß das doch nicht sooooo gut ist für eine VDR System Partition 

[clausmuus]

Ich selber habe bisher nur ein System mehrfach durch hartes abschalten beschädigt. Das lag aber nicht am Filesystem, sondern an der verwendeten SD Karte (ist aber schon nen paar Jahre her). Seitdem ich die Karte nicht mehr verwende trat das Problem nicht wieder auf, auch nicht bei meinem einzigen Produktiven RPI, der etwa einmal pro Monat hart abgeschaltet wird.
Meine Vermutung ist, dass solche problematischen SD Karten nicht sauber arbeiten, und dem Vollzug eines Schreibvorgangs melden, noch bevor dieser durchgeführt bzw. beendet wurde. Solche SD Karten gibt es durchaus, auch heute noch. Wenn sich eine SD Karte so verhält, hat kein Filesystem eine Chance. Bei solchen Karten ist jedes harte Abschalten kritisch.
Bei der MLD fällt das leider besonders störend auf, da relativ häufig (in den paar berichteten Fällen) die Zentrale Konfigurationsdatei beschädigt wird (komplett leer war).  Warum das so ist, weiß ich nicht, da diese im normalen Betrieb nicht zum schreiben geöffnet wird. Eine Beschädigung deutet aber auf einen fehlgeschlagenen Schreibvorgang hin. Demnach müsste genau beim Ändern der Konfiguration (im Setup) abgeschaltet worden sein, oder am Ende des Boot Vorganges, da dann ein Config Parameter geschrieben wird.

[clausmuus]

Bist Du sicher, dass die installation nach einem harten Abschalten beschädigt war, und nicht nach einem normalen Herunterfahren oder Reboot?

[clausmuus]

Eventuell rührt das Problem auch nicht vom harten Abschalten her, sondern von einem komplett gefülltem Root Laufwerk.

[clausmuus]

Ich konnte den Fehler jetzt auf meinem RPI nachstellen. Das fehlen der /etc/rc.config (bzw. dass diese leer ist) hatte bei mir nichts mit dem Ausschalten zu tun. Bei Verwendung von langsamen SD-Karten kann es vorkommen, dass beim booten mehrere parallele Prozesse gleichzeitig versuchen die Datei zu ändern.
Ich habe jetzt einen Mechanismus eingebaut der dies verhindern soll. Ein update des "init" Paketes (im testing und unstable) spielt dieses ein.