gelöst: File system error was found on volume....

[AgentMax]

Ok, danke. Jetzt bin ich etwas weiter. Jetzt kommt das hier:

root@DiskStation:~# fsck.ext4 -pvf -C0 /dev/vg1000/lv
/dev/vg1000/lv is mounted.
e2fsck: Cannot continue, aborting.

Habe dann umount probiert:

root@DiskStation:~# umount /dev/vg1000/lv
umount: /volume1: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)

 

[dil88]

Du machst nach wie vor irgendetwas falsch. Der Befehl "syno_poweroff_task -d" dient genau dem Zweck, Filesysteme zu unmounten. Bitte poste die komplette Eingabesequenz.

 

[AgentMax]

Hier:

root@DiskStation:~# syno_poweroff_task -d
Connection to 192.168.0.21 closed.
MBP-Michael:~ michael$ ssh admin@192.168.0.21
admin@192.168.0.21's password:
admin@DiskStation:~$ sudo -i
Password:
root@DiskStation:~# vgchange -ay
1 logical volume(s) in volume group "vg1001" now active
1 logical volume(s) in volume group "vg1000" now active
root@DiskStation:~# fsck.ext4 -yvf -C0 /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
/dev/vg1000/lv is mounted.
e2fsck: Cannot continue, aborting.

 

[dil88]

Vielleicht wurde hier in DSM 6.1 etwas geändert, da bin ich überfragt.

 

[AgentMax]

OK, danke für deine Hilfe. Also doch das Volume löschen und neu erstellen.
Erst mal eine Ersatz Syno kaufen um die 40TB vorher zu sichern....

 

[Puppetmaster]

Ich spar mir jetzt mal die Frage nach dem bestehenden Backup ...

 

[dil88]

Vielleicht wartest Du noch ein wenig oder schreibst Götz einmal eine PN, der kennt das DSM wie kein Zweiter. Ansonsten könntest Du auch noch ein Ticket bei Synology aufmachen, bevor Du so einen Aufwand betreibst.

Edit: Puppetmasters Gedanke schoss mir zugegebenermaßen auch durch den Kopf.

 

[AgentMax]

Ich habe ein Backup auf Amazon. Aber ich würde mir gerne den Traffic erst mal ersparen. Da geht es lokal schneller.

 

[AgentMax]

Ich konnte es jetzt mit umount -l unmounten.
Leider wird es weiterhin als "in use" angezeigt.

root@DiskStation:~# umount -l /dev/vg1000/lv
root@DiskStation:~# umount -l /dev/vg1000/lv
umount: /dev/vg1000/lv: not mounted
root@DiskStation:~# fsck.ext4 -yvf -C0 /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
/dev/vg1000/lv is in use.
e2fsck: Cannot continue, aborting.

 

[dil88]

Meiner Meinung nach läuft der "syno_poweroff_task -d" nicht korrekt. Ich fürchte, dass Du so nicht weiterkommst. Was gibt "syno_poweroff_task --help" aus?

 

[AgentMax]

Das hier:

root@DiskStation:~# syno_poweroff_task -help
DS shutdown progress.

usage: syno_poweroff_task [OPTIONS]

-h display this help
-d debug mode

Ich habe mir jetzt 10x8TB NAS Platten bestellt.
Auf diese spiegle ich dann erst mal das aktive System und mache das Volume neu.
Danach migriere ich auch gleich auf die 8TB. Speicherplatz war jetzt eh am Ende.
Besser als 6 Monate das Online Backup herunterzuladen.

 

[goetz]

Hallo,
falls Du noch Lust hast, schau mal was mount bei laufendem System ausgibt.
Von meiner DS1513+ DSM 6.1

root@ds:~# mount
/dev/md0 on / type ext4 (rw,relatime,journal_checksum,barrier,data=ordered)
...
/dev/mapper/vg1000-lv on /volume1 type ext4 (rw,relatime,journal_checksum,synoacl,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)

ist eine einzelne Platte als SHR.
Und dann noch mal schauen was mount sagt wenn syno_poweroff_task -d durchgelaufen ist.

Gruß Götz

 

[petehild]

Bei meiner DS916+ sind die von dir gezeigten Einträge bei mount weiterhin vorhanden...

Ist es normal, dass syno_poweroff_task -d die SSH Verbindung killt?

Edit: Seit dem reboot läuft laut top
/sbin/debugfs -q /.remap.vg1000.lv /dev/vg1000/lv
das Volume ist nicht gemounted

Edit2: hatte allerdings auch nen FS Error vorher

 

[petehild]

Es lag wirklich daran, dass syno_poweroff_task -d scheinbar mittendrin den SSH Dienst neustarted. Daher wird die Verbindung beendet und syno_poweroff_task wird mittendrin abgebrochen.

Abhilfe schafft, wenn man syno_poweroff_task -d im Hintergrund startet, dann läuft es weiter wenn die SSH Verbindung zusammen bricht.

Also als erstes:

syno_poweroff_task -d &

 

[dil88]

Macht Sinn, danke für die Information!

 

[AgentMax]

Danke. Meine Platten sind heute gekommen und das Backup läuft erst mal. Danach werde ich es nochmal probieren.

 

[petehild]

Bei mir wurden zwar diverse Fehler durch fsck.ext4 gefunden und gefixt, allerdings traten schon nach kurzer Zeit neue "Filesystem errors" auf (defekte HDD). Daher habe ich jetzt auch in neue Platten investiert

 

[superingo]

Hallo,

hier die Lösung für mein System mit dem aktuellen DSM 6.1 mit 4 Platten im SHR und einer Diskgruppe. Vielleicht hilft es jemandem...

Putty / telnet:

DS login: admin
Password: xxx
admin@DS:~$ sudo -i
Password: xxx
root@DS:~#

Auflistung (Beispiel) der Devices unter /dev/
ls -d /dev/vg*
/dev/vg1 /dev/vga_arbiter

Bei mir ist also /vg1 richtig. In diesem Verzeichnis ist mit
ls /dev/vg1/
volume_1
aufgeführt, nicht "lv" wie in vielen Beispielen oben.

syno_poweroff_task -d
hat bei mir nicht funktioniert, erst

syno_poweroff_task –d &
startet den Befehl offensichtlich richtig

vgchange -ay

fsck.ext4 -pvf /dev/vg1/volume_1

reboot

 

[dil88]

Danke für die Informationen - insbesondere die abweichenden!

 

[Deepbluesee]

Hallo
leider kommt bei mir folgende Fehlermeldung:

1 logical volume(s) in volume group "vg1000" now active
sh-4.3# fsck.ext4 -pvf -C 0 /dev/vg1000/lv
fsck.ext4: Bad magic number in super-block while trying to open /dev/vg1000/lv
/dev/vg1000/lv:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>