Riparare il file system di un NAS Synology

Oggi, mentre smanettavo con uno script per fare un backup del mio fido NAS Synology DS413j sulla mia altrettanto fida Time Capsule, ho scoperto nei log qualche segno di squilibrio del filesystem. Ho prontamente cercato nell’interfaccia del nuovissimo DSM 5.0 qualche funzionalità per lanciare un fsck ma, ahimè, pare che l’OS Synology sia incredibilmente carente di tale fondamentale funzione (!).

In ogni caso, non è un grosso problema, dato che è sempre possibile abilitare l’accesso al NAS tramite SSH/telnet, potendo così procedere ad un fsck manuale. Ovviamente, però, è necessario smontare prima il filesystem, cosa che a sua volta richiede l’arresto di tutti i servizi in esecuzione. Ora, l’OS Synology non rispetta molto il Linux FHS, per cui capire come fare ciò non è esattamente immediato. Fortunatamente basta googlare un po’ per trovare suggerimenti di chi ha già avuto questo problema, ma… nessuno pare avere già fatto ciò con il DSM 5 :(. Ecco come ne sono uscito.

Il primo passo consiste nell’abilitare l’accesso al NAS tramite telnet. SSH non va bene, perché verrà killato brutalmente dal primo comando che lanceremo. In realtà, anche telnetd farà la stessa fine, ma almeno la sessione in uso rimarrà attiva, permettendoci di andare avanti. Fatto ciò, ce la caviamo con poco:

slackberry ~ # telnet 10.0.0.245
Trying 10.0.0.245...
Connected to 10.0.0.245.
Escape character is '^]'.

SukkoNAS login: root
Password:

SukkoNAS> syno_poweroff_task
synologrotated stop/waiting
nmbd stop/waiting
synobackupd stop/waiting
webdav-httpd-ssl stop/waiting
afpd stop/waiting
smbd stop/waiting
synomkflvd stop/waiting
initctl: Unknown instance:
sshd stop/waiting
ntpd stop/waiting
crond stop/waiting
syslog-acc stop/waiting
cnid_metad stop/waiting
webdav-httpd stop/waiting
synomkthumbd stop/waiting
nfsd-adapter stop/waiting
httpd-user stop/waiting
img_backupd stop/waiting

SukkoNAS> mdadm --assemble --scan
mdadm: /dev/md/2 has been started with 4 drives.

SukkoNAS> e2fsck -fv /dev/md2
e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information

1.41.12-2668: ***** FILE SYSTEM WAS MODIFIED *****

      653213 inodes used (0.12%, out of 548544512)
       10604 non-contiguous files (1.6%)
         189 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 650056/2212/44
   425317438 blocks used (19.38%, out of 2194158192)
           0 bad blocks
          40 large files

      574022 regular files
       77959 directories
           0 character device files
           0 block device files
           3 fifos
           7 links
        1211 symbolic links (880 fast symbolic links)
           8 sockets
------------   
      653210 files

SukkoNAS> reboot

Broadcast message from root@SukkoNAS
        (/dev/ttyp0) at 20:49 ...

The system is going down for reboot NOW!

SukkoNAS> Connection closed by foreign host.
slackberry ~ #

Non c’è molto da dire, sono tutti comandi abbastanza basilari, a parte il primo, che è un comando non documentato Synology che serve a fermare tutti i servizi, e che quindi fa la maggior parte del “lavoro sporco” che ci serve (mettendoci anche un discreto tempo…). Peccato che smonti anche la partizione dei dati e fermi il device software RAID corrispondente, che va quindi riassemblato (eventualmente conviene fare un cat /proc/mdstat come primissimo comando, per capire come riassemblare il RAID a mano se la modalità automatica non dovesse funzionare), e quindi si può procedere con il vero e proprio fsck, per concludere con un reboot dell’intero NAS, in modo da tornare alla situazione normale.

Ci tengo a sottolineare che nel mio setup (RAID 5 puro) non viene utilizzato LVM. In caso contrario, un vgchange -ay qua o là avrebbe probabilmente aiutato.

You told me everything about a PoisonApple

Se mi fossi lasciato sfuggire l’offertona di una decina di giorni fa presso i negozi @Work di Torino, non me lo sarei mai perdonato. Ecco dunque l’ultimo arrivato in casa SukkoPera:

Chiudendo un occhio sulla mia ridicola sagoma riflessa ;), si tratta di un iMac 24 pollici (ora fuori produzione) revisionato e perfettamente funzionante, portato a casa a 599 Euro.

Ovviamente, ero e rimango un utente GNU/Linux, per cui il mio primo lavoro su tale mirabolante macchina è stato quello di installarci MacOS X e Slackware in dual boot. Quelli che seguono sono i passi che ho seguito. So che ci sono centinaia di guide al dual-boot in giro per la rete, ma io non ne ho seguita nemmeno una ed ho fatto di testa mia, come da Slackwarista D.O.C. ;).

  1. Avviare dal DVD di MacOS X Snow Leopard (tenendo premuto ‘C’ all’accesione).
  2. Quando compare la prima schermata, dal menù Utility lanciare l’Utility Disco.
  3. Partizionare il disco come desiderato. Il mio iMac ha un disco da 320 GB, che ho così suddiviso:
    • /dev/sda1: Partizione di sistema EFI
    • /dev/sda2 (70 GB): MacOS X
    • /dev/sda3 (50 GB): Slackware
    • /dev/sda4 (200 GB): Dati

    Ignorando quella di sistema, la prima partizione è quella che ho poi indicato come target dell’installazione; la seconda è stata temporaneamente lasciata come spazio libero; per la terza ho scelto il filesystem HFS+ senza journal (vedremo dopo perché).

  4. Installare MacOS X a piacimento.
     
     
  5. Avviare il MacOS X appena installato e installare rEFIt.
  6. Riavviare il Mac due volte, finché non compare il menù di rEFIt, quindi da esso lanciare il Partitioning Tool e sincronizzare le tabelle delle partizioni.
  7. Avviare dal GParted Live CD (o equivalente, come ad esempio SystemRescueCd) e creare una partizione ext4 (o con il filesystem Linux preferito) nello spazio precedentemente lasciato libero. Questo è necessario perché, per poter ospitare senza troppe complicazione MacOS X e GNU/Linux, il disco deve avere una tabella delle partizioni ibrida GPT/MBR. Se creassimo la partizione con il classico (c)fdisk, la partizione sarebbe unicamente visibile nella struttura MBR e non sarebbe possibile avviarla.
  8. Riavviare, lanciare il Partitioning Tool di rEFIt e sincronizzare nuovamente le tabelle delle partizioni.
  9. Avviare dal DVD di Slackware e procedere all’installazione nella partizione appena creata.
     
     
  10. Godersi il dual boot :).
     

Credo che si potesse evitare il passaggio 6 semplicemente non lasciando la partizione come spazio libero, ma formattandola con qualunque filesystem e riformattandola poi come necessario durante l’installazione di Slackware. Forse avrei anche potuto crearla da Utility Disco ma non ci ho pensato subito, ed ho preferito riportare la procedura esattamente come l’ho svolta.

La più grande pecca di questa procedura, dovuta alla mia scarsa familiarità con EFI e la GPT (in particolare non ho idea se si possano utilizzare più di 4 partizioni con la tabella ibrida, cosa che richiederebbe l’utilizzo di partizioni estese nella struttura MBR), è che ho dovuto installare Slackware interamente in una partizione, senza suddividere / da /var e /boot come mi piace tanto fare. Addirittura, non ho potuto creare nemmeno una partizione di swap! Mi adatterò utilizzando un banale file di swap, sperando che le performance non ne risentano troppo (suvvia, in fondo la belva ha 2 GB di RAM! :p ).

La scelta del filesystem HFS+ non journaled per la partizione dei dati è dovuta al fatto che Linux è in grado di montare tale filesystem in lettura e scrittura, mentre se avessi attivato il journaling, Linux avrebbe montato la partizione read-only. In questo modo ho a disposizione parecchio spazio per scambiare dati tra i due sistemi operativi, anche se al prezzo di qualche pericolo in più in caso di spegnimento “irregolare” della macchina, ma in fondo ho un UPS mica per niente! :)

Vi terrò aggiornati su ulteriori esperimenti!

Tristezza

UNIX, l’appello di SCO. Disperato.

Il morto vivente che rivendica diritti su UNIX riprova a mordere Novell chiedendo nuovi giudizi e – se necessario – nuovi processi. SCO non ha un soldo né un business, ma gli azzeccagarbugli ancora scribacchiano.

Leggete l’articolo intero qua.

ffmpeg: Audio encoding failed

Qualche giorno fa, mentre encodavo qualche nuovo video per i Decade tramite il buon ffmpeg, sono incappato nel seguente errore:

[libmp3lame @ 0x80a64b0]lame: output buffer too small (buffer index: 9195, free bytes: 597)
Audio encoding failed

La soluzione è stata semplicemente quella di aggiornare LAME alla versione più recente. Quando è successo avevo la 3.98.2; ora sono passato alla 3.98.4 e il problema è sparito.

Il mio pacchetto della nuova versione per Slackware 12.2 è disponibile qua. Per chi volesse utilizzarlo su altre versioni della distribuzione, il relativo port per Slackmatic si trova qua. Maggiori informazioni sul mio repository arriveranno appena ho tempo ;).