Dopo boot va solo ssh

[Paolo Holzl]

In seguito ad un reboot tenendo premuto il tasto Power il mio TS-410 é partito ... in tutti i sensi.

Riesco ad agganciarlo da QNAPFinder sotto Windows e cambiarci la configurazione ma non entro più via Web e neppure mappo le unità condivise (condivisione Windows).

A questo punto accedo via ssh
fdisk -l

Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 66 530141 83 Linux
/dev/sda2 67 132 530142 82 Linux swap / Solaris
/dev/sda3 133 243138 1951945693 83 Linux
/dev/sda4 243139 243200 498012 83 Linux

Disk /dev/sda4: 469 MB, 469893120 bytes
2 heads, 4 sectors/track, 114720 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

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

Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 66 530141 83 Linux
/dev/sdb2 67 132 530142 82 Linux swap / Solaris
/dev/sdb3 133 243138 1951945693 83 Linux
/dev/sdb4 243139 243200 498012 83 Linux

Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 * 1 66 530141 83 Linux
/dev/sdc2 67 132 530142 82 Linux swap / Solaris
/dev/sdc3 133 243138 1951945693 83 Linux
/dev/sdc4 243139 243200 498012 83 Linux

Disk /dev/md9: 542 MB, 542769152 bytes
2 heads, 4 sectors/track, 132512 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

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

L'impressione é che quindi lui non abbia montato il raid (giusto?).
Faccio un dmesg che riporta tanti

[ 2472.720000] sd 2:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 00 10 96 68 00 00 04 00
[ 2472.720000] end_request: I/O error, dev sda, sector 1087080
[ 2472.720000] Buffer I/O error on device sda2, logical block 6696
[ 2489.490000] sd 2:0:0:0: [sda] Unhandled sense code
[ 2489.490000] sd 2:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
[ 2489.490000] sd 2:0:0:0: [sda] Sense Key : 0x3 [current] [descriptor]
[ 2489.490000] Descriptor sense data with sense descriptors (in hex):
[ 2489.490000] 72 03 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 2489.490000] 00 10 96 6c

In pratica mi sembra di capire che si sia 'fumato' sda2 dei tre dischi che ho in RAID5.
Tempo fa via Email mi aveva avvisato di problemi su alcuni cluster.

Che fare?
SDA2 é quello sul secondo slot da sinistra?
Considerate che via Web non riesco ad entrare (sembra non trovi le pagine) ma solo in ssh.

Che comandi posso dare (per esempio per capire lo stato del raid e dei singoli dischi) e magari disabilitare il secondo come corrotto?
Mi basta fermare il QNAP e farlo ripartire con il secondo disco estratto per poi sotituirlo a caldo?
Sono un po preoccupato per via dei dati contenuti.

Il firmware é 1.0208 (0000)
Come posso sapere la situazione voi cosa fareste?

[luciano]

Innanzitutto il fw non può essere quello che hai scritto. Cmq poco importa in questo caso.

Se vai in /share non ci sono le condivisioni di default? (Qmultimedia, public etc?)

[Lead srl]

Quel firmware che vedi (1.0208) non è il firmware "ufficiale" del NAS, ma bensì è solo di boot, quindi il sistema operativo non è effettivamente mai partito.
Dato che da SSH hai visto quel problema prova a far partire il NAS senza il disco 2 inserito, alle volte capita che un disco corrotto blocchi il boot.
Se anche così non dovesse andare la situazione si fa delicata.
Ciao

[Paolo Holzl]

Scusa in che senzo sil SO non é partito, allora chi mi risponde all ssh?

Ho fatto un riavvia con il secondo disco estratto.
Ci ha messo un po ad entrare in linea ma poi finalmente ho potuto riagganciarlo in ssh.
Ho controllato dmsg e ho riscontrato gli stessi errori per cui ho immaginato che sda2 non fosse il secondo slot.
Ho riprovato il boot estraendo il primo disco, il boot é stato più rapido e gli errori sono scomparsi, insomma il disco bacato é il primo a sinistra.
Ho fatto l'ennerismo reboot che riporto per le parti che ritengo potrebbero essere utili

[/share/HDC_DATA] # dmesg
...
[ 42.130000] sdb:
[ 42.130000] sdc: sdc1 sdc2 sdc3 sdc4
...
[ 42.170000] sd 4:0:0:0: [sdc] Sector size 0 reported, assuming 512.
...
[ 42.180000] md: linear personality registered for level -1
[ 42.180000] md: raid0 personality registered for level 0
[ 42.180000] md: raid1 personality registered for level 1
[ 42.180000] md: raid10 personality registered for level 10
...
[ 42.580000] sdb1 sdb2 sdb3 sdb4
[ 42.610000] sd 3:0:0:0: [sdb] Sector size 0 reported, assuming 512.
[ 42.630000] sd 3:0:0:0: [sdb] Attached SCSI disk
[ 42.630000] md: Waiting for all devices to be available before autodetect
[ 42.630000] md: If you don't use raid, use raid=noautodetect
[ 42.630000] md: Autodetecting RAID arrays.
[ 42.630000] md: Scanned 0 and added 0 devices.
[ 42.630000] md: autorun ...
[ 42.630000] md: ... autorun DONE.
...
[ 43.960000] VFS: Mounted root (ext2 filesystem) on device 1:0.
[ 43.960000] Freeing init memory: 136K
[ 44.580000] kjournald starting. Commit interval 5 seconds
[ 44.580000] EXT3-fs (sdb1): mounted filesystem with writeback data mode
[ 44.710000] kjournald starting. Commit interval 5 seconds
[ 44.710000] EXT3-fs (sdc1): mounted filesystem with writeback data mode
[ 44.980000] md: md9 stopped.
[ 45.000000] md: bind<sdb1>
[ 45.000000] md: bind<sdc1>
[ 45.020000] raid1: raid set md9 active with 2 out of 4 mirrors
[ 45.090000] md9: bitmap initialized from disk: read 5/5 pages, set 113747 bits
[ 45.090000] created bitmap (65 pages) for device md9
[ 45.090000] md9: detected capacity change from 0 to 542769152
[ 45.110000] md9: unknown partition table
LA RIGA PRECEDENTE MI PREOCCUPA
...
[ 47.490000] kjournald starting. Commit interval 5 seconds
[ 47.500000] EXT3-fs (md9): using internal journal
[ 47.500000] EXT3-fs (md9): mounted filesystem with writeback data mode
[ 47.800000] md: md13 stopped.
[ 47.840000] md: bind<sdb4>
[ 47.840000] md: bind<sdc4>
[ 47.850000] raid1: raid set md13 active with 2 out of 4 mirrors
[ 47.970000] md13: bitmap initialized from disk: read 4/4 pages, set 81921 bits
[ 47.980000] created bitmap (57 pages) for device md13
[ 48.010000] md13: detected capacity change from 0 to 469893120
[ 48.030000] md13: unknown partition table
[ 49.390000] kjournald starting. Commit interval 5 seconds
[ 49.440000] EXT3-fs (md9): using internal journal
[ 49.440000] EXT3-fs (md9): mounted filesystem with writeback data mode
[ 49.800000] kjournald starting. Commit interval 5 seconds
[ 49.830000] EXT3-fs (md9): using internal journal
[ 49.830000] EXT3-fs (md9): mounted filesystem with writeback data mode
[ 49.920000] kjournald starting. Commit interval 5 seconds
[ 50.040000] EXT3-fs (md13): using internal journal
[ 50.040000] EXT3-fs (md13): mounted filesystem with writeback data mode
...
[ 59.740000] raid6: int32x1 61 MB/s
[ 59.910000] raid6: int32x2 82 MB/s
[ 60.080000] raid6: int32x4 83 MB/s
[ 60.250000] raid6: int32x8 77 MB/s
[ 60.250000] raid6: using algorithm int32x4 (83 MB/s)
...
[ 61.140000] md: raid6 personality registered for level 6
[ 61.140000] md: raid5 personality registered for level 5
[ 61.140000] md: raid4 personality registered for level 4
...
[ 68.850000] kjournald starting. Commit interval 5 seconds
[ 68.860000] EXT3-fs (md9): using internal journal
[ 68.860000] EXT3-fs (md9): mounted filesystem with writeback data mode
[ 72.480000] active port 0 :139
[ 72.480000] active port 1 :445
[ 72.480000] active port 2 :20
[ 78.980000] md: md0 stopped.
[ 80.060000] md: md0 stopped.
[ 80.660000] Unable to find swap-space signature
[ 87.050000] md: md0 stopped.
[ 88.030000] Unable to find swap-space signature
...
[ 144.640000] warning: process `pic_raw' used the deprecated sysctl system call with 8.1.2.
[ 148.030000] rule type=2, num=0
[ 163.880000] Loading iSCSI transport class v2.0-871.
[ 164.610000] iscsi: registered transport (tcp)

[Paolo Holzl]

Innanzitutto il fw non può essere quello che hai scritto. Cmq poco importa in questo caso.

Se vai in /share non ci sono le condivisioni di default? (Qmultimedia, public etc?)

In /share trovo solo
drwxrwxr-x 30 admin administ 1024 Jan 24 08:30 ./
drwxr-xr-x 18 admin administ 1024 Jan 24 08:30 ../
drwxrwxrwx 2 admin administ 1024 Sep 19 2005 HDA_DATA/
drwxrwxrwx 2 admin administ 1024 Dec 7 2005 HDB_DATA/
...
drwxrwxrwx 2 admin administ 1024 Dec 7 2005 HDY_DATA/
drwxrwxrwx 2 admin administ 1024 Dec 7 2005 HDZ_DATA/
drwxrwxrwx 3 admin administ 1024 Jan 24 08:30 MD0_DATA/
drwxrwxr-x 28 admin administ 1024 Feb 28 2006 external/

Per il firmware avevo preso per buono Versione che mi dava QNAP finder.
Il workgroup del NAS é visibile anche da Linux, sotto Windows7 vedo anche le risorse teoricamente mappabili (di fatto non le mappa).
A naso mi verrebbe da dire che sta condividendo qualcosa che non ha montato o ha cha montato difettato (nella fat o altro).

Mi verrebbe da fare un e2fsck di qualcosa ... ma voglio essere relativamente sicuro, e poi su cosa, su md9?

Oltretutto non ho proprio capito come fare dei test sullo stato del raid.

[luciano]

in MD0_DATA dovresti avere tutti i dati. Concordo anch'io sul fatto che una parte della sequenza di boot del firmware sia corretta, altrimenti non potresti accedere via SSH. Puoi incollare anche l'output di un "df -h"?

[Paolo Holzl]

Purtroppo MD0_DATA é vuoto.

anche df -h é preoccupante
Filesystem Size Used Available Use% Mounted on
/dev/ram0 32.9M 15.6M 17.4M 47% /
tmpfs 32.0M 84.0k 31.9M 0% /tmp
/dev/sda4 310.0M 250.0M 59.9M 81% /mnt/ext
/dev/md9 509.5M 98.1M 411.4M 19% /mnt/HDA_ROOT
tmpfs 32.0M 0 32.0M 0% /.eaccelerator.tmp

considera che almeno un terabyte era caricato.

Ancora più preoccupante questa scoperta
[/] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md13 : active raid1 sdc4[0] sdb4[1]
458880 blocks [4/2] [UU__]
bitmap: 41/57 pages [164KB], 4KB chunk

md9 : active raid1 sdc1[0] sdb1[1]
530048 blocks [4/2] [UU__]
bitmap: 65/65 pages [260KB], 4KB chunk

Considera che non é un Raid1 ma era un Raid5.

[luciano]

Tutto questo con il disco-1 estratto? Se lo rimetti dentro che ottieni?

[Paolo Holzl]

Ora vi aggiorno sulla situazione.

Ho fatto partire il NAS con tutti i dischi estratti e anche così ho avuto problemi.
Ho quindi fatto il reset premendo nel buco dietro.
Ho aggiornato il firmware del TS-410 all'ultima versione 3.6.0 inserendo un disco nuovo nello slot 4 (lasciando estratti l'1,2,3 in modo da vedere di rimontarli in seguito).

Il tutto riparte correttamente (ho dovuto azzerare la cache del browser per vedere bene la schermata), ho configurato i dati di rete, nome, password ecc. Alla fine ho dato il permesso di formattare il disco.

Alla ripartenza entrando sullo stesso IP pensavo di finire nella schermata amministrativa, invece mi ritrovo la stessa schermata di configurazione (provato più volte) (e sì che i settaggi li ha presi, ip e tutto il resto).

Anche dal Qnap Finder se lancio 'interfaccia amministrativa' ottengo 'The requested resource was not found on this server'

Che fare?

[luciano]

Il disco "nuovo" che hai inserito nello slot 4 è NUOVO oppure è stato usato già su qualche altro sistema? In altre parole, sei certo non ci siano già delle partizioni sopra?

[Paolo Holzl]

Sei un grande! Il problema era proprio quello, non avevo ipotizzato che come disco 'nuovo' intendesse uno totalmente senza partizioni (tantopiù che avvertiva che in formattazione avrebbe cancellato i dati!) ed era solo parzialmente partizionato per cui aveva tutto il posto che gli serviva.

Ottimo .. ora parte ... siamo al momento clou fa il boot con il disco sul quarto slot ma a me interessano i dati che sono sugli slot 1,2,3 (stessa posizione stesso ordine) che erano in Raid 5.

Cosa devo fare?
Inserire i dischi 'al volo' a macchina accesa per poi dire che sono in Raid 5 senza farli formattare?
Rifare il boot con i dischi inseriti?

Incomincio a capire un po di più del QNAP, non pensavo che il firmware venisse caricato da disco, pensavo fosse caricato in una Eprom.

In pratica non partendo più il Raid 5 non caricava più il firmware ... può essere?
Se fosse così penso che una configurazione impostata come ora sia meglio, un disco 'di boot' con il firmware e magari un area condivisa per dati 'cancellabili' e un Raid 5 con altri tre dischi.

[luciano]

...ok, ma il punto è: se prima cmq accedevi al volume RAID-5 e i dati non li abbiamo trovati, perchè dovrebbero esserci adesso?

[Paolo Holzl]

In realtà il Raid5 non era attivo.
In pratica per qualche ragione non era in grado di fare il mount della catena Raid.
Forse ...

[luciano]

mmh non vorrei fare il menagramo ma la vedo dura.... cmq il punto è questo: il volume RAID-5 che avevi prima era il primo volume creato, ovvero era il volume che faceva il boot. Se lo rimetti dentro.... non ho idea di cosa possa succedere, cmq sia se proprio vuoi fare la prova (del resto non hai nulla da perdere visto che nella nuova installazione ancora non hai niente) metti dentro i 3 dischi a boot completato, cioè con l'installazione sul volume singolo del disco 4.

[Paolo Holzl]

Finalmente ho risolto tutto e sto ricuperando tutti i dati su un disco esterno. Poi sostituirò il disco rotto e rigenererò il Raid 5 lasciando il boot dal quarto slot.
Sono riuscito tramite l'assistenza di Taiwan che prima ho contattato in Skype (sul sito i riferimenti), li ho fatti accedere via Teamviewer a una delle mie macchine con Fedora in modo che avessero l'accesso sia via ssh che via Web.

Riporto i comandi che hanno fatto (tolti gli errori e i comandi inutili) che mi hanno permesso di mappare nuovamente l'unità e riaccedere a 2,5 TB di roba.
Ho lasciato cat ls ecc. per capire che sono andati lì a ricercare delle informazioni.

cat /proc/mdstat
mdadm -E /dev/sda3
mdadm -E /dev/sdb3
mdadm -E /dev/sdc3
mdadm -E /dev/sdd3
fdisk -l
df
umount /dev/sdd3
ls

(questo il punto clou!)
config_util 1
storage_boot_init 2

df
ls -al
cd /media
cat /proc/mdstat
cd /share
mkdir MD0_DATA
mount /dev/md0 /share/MD0_DATA/ -t ext4

Tutta questa storia cosa mi ha insegnato, il QNap che ho é strepitoso con una buona comunity ed un ottima assistenza.
Che il limite più vistoso é il fatto che salvi il Firmware sul disco e non in una Eprom che di fatto vanifica la totale 'fault tollerance' del Raid (ovvero tutto bene se non si rompe proprio un cluster del Firmware che viene letto quando ancora il Raid deve essere attivato).
Soluzione, tenere un disco per il boot (con un backup immagine fuori) e fare il Raid sui tre rimanenti.

Grazie a tutti.

[luciano]

Paolo, un paio di considerazioni... innanzitutto grazie per aver condiviso la tua esperienza, se facessero tutti come te le community crescerebbero molto + velocemente!
Circa la soluzione adottata dai tecnici QNAP che hai postato, mi viene da dire a chiunque altro la legga - e non sappia per filo e per segno quello che stà facendo - di farlo fare a loro!

Per quanto riguarda il discorso RAID.... i modelli di fascia + alta - quelli con processori Intel x intenderci - funzionano esattamente come dici tu. Ovvero il firmware è tutto su delle memorie flash (DOM) in alcuni modelli addirittura ridondate. Per non far lievitare troppo i costi dei modelli di fascia SOHO, questa soluzione ad oggi non è utilizzata per questi ultimi...