Forum libero

> > > > > Ti serviva un binario di extundelete?
> > > > > Prova con quello che è dentro questo pacco:
> > > > > http://mirror.archlinuxarm.org/arm/community/extun...
> > > >
> > > > Qualcuno ha compilato un eseguibile per arm?
> > > >
> > > > Si copia in bin e funziona?
> > > >
> > > > Grazzie, se fallisce ogni altro metodo lo provo.
> > >
> > > In realtà devi ringraziare l'oloturio che si è ricordato che il raspa è arm, ho verificato i repository, sono armv5 per i pacchetti generici, solo il kernel è compilato ad hoc (il raspberry pi è un armv6).
> > >
> > > Se possono esserti utili le seguenti info:
> > >

> > > $ file $(which extundelete)
> > > /usr/bin/extundelete: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, BuildID[sha1]=256ee96066b941d983cfcbdad7a49b2e2731ce4b, stripped
> > > $ ldd $(which extundelete)
> > > libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0xb6fcb000)
> > > libext2fs.so.2 => /usr/lib/libext2fs.so.2 (0xb6f8c000)
> > > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6ec4000)
> > > libm.so.6 => /usr/lib/libm.so.6 (0xb6e23000)
> > > libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb6dfc000)
> > > libc.so.6 => /usr/lib/libc.so.6 (0xb6cce000)
> > > /lib/ld-linux.so.3 (0xb6fd6000)
> > > libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb6cad000)
> > > 

> > >
> > > Siccome è linkato dinamicamente si aspetterà le lib nelle posizioni che vedi sopra, che sono per arch, non è detto che siano tutte uguali le altre distro; se nel tuo caso sono in posizione diversa puoi fare un link simbolico con ln -s per fargliele trovare dove se le aspetta.
> > > Se ti manca qualche shared object tra quelli elencati puoi trovare i primi due (ext2) in questo pacchetto:
> > > http://mirror.archlinuxarm.org/arm/core/e2fsprogs-...
> > > Gli altri dovresti averli nel sistema.
> >
> > La cosa si fa complessa. Perché non è come nel DOS che copiavi un programma, aggiungevi la directory al PATH e tutto funziava?
>
> Anche il DOS soffriva degli stessi problemi, solo che tendenzialmente chi fa programmi per windows ti da l'exe con una cartella di shared library (dll) e tu copi tutto, programma e dipendenze.
> Volendo gestire il sistema minimizzando le duplicazioni su linux ti trovi giocoforza a separare programmi e dipendenze, almeno quando queste sono comuni a più programmi.
> Prova a contare nella tua c: in questo momento le occorrenze di msvcrt*.dll e in quante versioni diverse le hai dentro.

Terrò questa soluzione come extrema ratio.

Per ora la roadmap è la seguente:
Sono riuscito a estorcere dai forum un'informazione secondo cui, tramite una docking station, al NAS è possibile collegare qualsiasi disco incluso nella lista di compatibilità per dischi interni (la lista per quelli esterni ne elenca pochi e nessuno soddisfacente). Quindi
1. Comprare una docking station USB e un disco da 2 TB come quelli del NAS (o più?).
2. Sui forum dicono tutti che collegando un disco del NAS al computer, con Linux se ne vede il contenuto, cosa che perlappunto a me non riesce. Provare se collegando con la docking station e bruciando un bastoncino d'incenso a Velsharoon riesce.
3. Se il punto 2. non è riuscito, accendere il NAS, umount forzato di /dev/md0, /dev/sda e /dev/sdb (smontandoo i dispositivi sul NAS ***PRESUMO*** che il NAS non possa scrivere sui dischi sovrascrivendomi i file, chissà che succede però) e a questo punto dd di /dev/md0 sul disco USB esterno. A questo punto dovrei avere un'immagine, presumibilmente con filesystem ext4, su cui provare extundelete.
4. Se il 3. non riesce perché per incommensurabile colmo di sfiga il NAS non riconosce il disco USB esterno nonostante l'informazione ricevuta, provare a vedere se dal NAS sia possibile vedere il portatile montandolo cifs come //192.168.0.x, e fare dd di /dev/md0 sull'unità montata del portatile.