Clonare la propria slack su HD esterno

[joe]

Grazie zoros.
Utilizzerò la vecchia partizione con installata slackware-11.0 che mi ritorna utile visto che comunque è un sistema funzionante e configurato ai tempi.
Penso che sia il caso di spezzare i vari punti che mi hai suggerito muovendomi a passi e di volta in volta vi farò sapere ed eventualmente (con altissima probabilità) cercherò di togliermi i dubbi che mano mano mi verranno.
Grazie di nuovo. A presto

[joe]

Ah...aggiungo che sarebbe interessante migliorare questo primo passo:
- copiare il sistema attuale dallo stesso sistema avviato

Si potrebbe pensare ad utilizzare per esempio rsync e una bella lista di esclusione di ciò che non deve essere copiato.
In questo modo non servirà usare una live e tantomeno dover fermare il sistema.
Non è il mio caso, ma pensiamo ad un server che deve continuare a girare e mettiamo di voler fare un backup del sistema, ma un backup che cloni il sistema da qualche parte in modo che anche quello clonato sia ovviamente avviabile.

Secondo me sarebbe interessante approfondire questo aspetto:
- come usare rsync, con che opzioni
- cosa copiare esattamente, anzi cosa escludere del file system avviato.

Saluti. Spero d'essermi spiegato con poche parle

[joe]

meglio usare un Live CD, lo stesso CD/DVD di installazione di Slackware può andar bene ... per la copia usa "cp -Rpdf * /mnt_destinazione" ...

Mmmm....mi stavo scrivendo uno scriptino per trascrivere il comando sopra e lanciarlo al riavvio...sulla vecchia slack11 non ho connessione via bluetooth e devo andare a memoria, così lo script è una buona soluzione.

Il problema è che il comando da te suggerito:

cp -Rpdf * /dest

presenta quell'asterisco, che vorrebbe dire copia tutto....E deduco che presuppone di trovarsi nella root del sistema da clonare...giusto no?
Lavorando da una sistema terzo, live o meno avrò montato il sistema da clonare in /mnt/src per esempio, quindi quel comando presuppone di trovarsi in /mnt/src....dico bene, non avrebbe senso altrimenti stare sualla root del sistema terzo...direi proprio di sì

Va bè quindi mi confermerai che uno script del genere potrebbe andare...che dici?

Codice: Seleziona tutto

SRC=$1
DST=$2
[ ! -d $DST ] && echo "destinazione inesistente" && exit 1
cp -Rpdf $SRC/* $DEST


Va lanciato semplicemente, ma è banale, con:
nome_script.sh /mnt/source /mnt/dest

Va bè provo.

[joe]

Ok, ha finito, è andato tutto liscio, ma con una "piccola" differenza di dimensione tra il sistema copiato e l'originale.
Sempre quando ero sul sistema terzo da cui ho eseguito la copia, ho lanciato il comando "du -s" sulle directoies $SRC e $DEST e ho ottenuto:

Codice: Seleziona tutto

6571832 /mnt/hd/slack12
6571680 /media/wd2/slackware/slack121-sysbackup060309

Quindi il sistema clonato contiene qualcosa in meno rispetto all'originale, come si vede mancano circa 150KB.
Quali files non sono stati copiati? A naso direi che non si tratta di nulla di cui preoccuparsi, ma volendo come potrei fare per capire cosa non è stato copiato?

[zoros]

direi che sei stato molto chiaro, infatti hai specificato che ti trovavi sul sistema "terzo" quindi il "du" è stato fatto senza riavviare ... perché già al primo riavvio i due sistemi differiscono per via della creazione di vari files temporanei di runtime ...

tra questi files temporanei ci sono alcuni che non vengono ricopiati, tipo i socket ... 150kb non sono tantissimi, quindi è plausibile ...

con il cp non hai una vera clonazione, bit a bit ... ottieni comunque lo scopo e il metodo è anche efficace per passare un sistema completo già configurato su un'altro tipo di filesystem (tipo da ext3 a reiserfs) ...

[joe]

direi che sei stato molto chiaro, infatti hai specificato che ti trovavi sul sistema "terzo" quindi il "du" è stato fatto senza riavviare ... perché già al primo riavvio i due sistemi differiscono per via della creazione di vari files temporanei di runtime ...

L'ho specificato proprio per questo. Sia la destinazione che soprattutto la sorgente erano "dormienti", proprio per quello mi aspettavo di trovare la stessa identica dimensione.

tra questi files temporanei ci sono alcuni che non vengono ricopiati, tipo i socket ... 150kb non sono tantissimi, quindi è plausibile ...

con il cp non hai una vera clonazione, bit a bit ... ottieni comunque lo scopo e il metodo è anche efficace per passare un sistema completo già configurato su un'altro tipo di filesystem (tipo da ext3 a reiserfs) ...

Quindi dici che non c'è convenienza a prendersi troppo disturbo per una verifica di cosa siano esattamente quei 150 KB....in effetti mi sembra ragionevole...se il sistema clonato non funzionerà al limite vedrò di fare qualche verifica anche su questo punto. Quindi diciamo che il primo passo è andato ok.

Come già avevo accennato qualche post sopra, non tipare una buona lternativa cercare una via per copiare il sistema senza la necessità di un sistema d'appoggio terzo?
Non ho visto risposte su questo punto...è perchè non ha senso la questione oppure semplicemente non vi sono motivi particolari? Non chiedo (solo ) per incalzare ma per cercare di capire meglio e per cercare d'ottimizzare la procedura.

[zoros]

...
Come già avevo accennato qualche post sopra, non tipare una buona lternativa cercare una via per copiare il sistema senza la necessità di un sistema d'appoggio terzo?
Non ho visto risposte su questo punto...è perchè non ha senso la questione oppure semplicemente non vi sono motivi particolari? Non chiedo (solo ) per incalzare ma per cercare di capire meglio e per cercare d'ottimizzare la procedura.

mi pare che metodi e script per fare il backup di un sistema in run-time siano abbastanza comuni, in particolare con rsync ... basta cercare su Internet ... anche con il cp puoi farlo a sistema avviato, devi solo escludere alcune directory (/mnt,/tmp,/var/tmp, ecc.) ... quindi devi farti uno script ...

penso però che lavorare a sistema smontato sia la cosa più "sana" ... comunque io uso questo metodo per raccogliere in vari archivi compressi un sistema Linux completo preconfigurato e "ripulito" dalle personalizzazione (tipo utenti, ecc.) ... con questa base posso replicare a piacere l'installazione ... non è una cosa nuova, è semplicemente una cosa comoda ...

[joe]

Concordo con quanto affermi, sicuramente, lavorando a sistema non avviato è una scelta intrinsecamente meno problematica.
Certo resta come in ogni cosa l'aspetto della destinazione d'uso, vedi il discorso del server (possibilmente) non riavviabile tanto per fare un'esempio. E comunque mi pare in ogni caso più comodo utilizzare cp o rsync lavorando dal sistema che si usa sempre...
Per fare l'esempio, oggi ho riavviato in slackware-11 e però mi sono accorto che non aveva bluez installato (ai tempi in cui la utilizzavo collegavo il cellulare via cavo usb....adesso uso un dongle bluetooth)...quindi non avevo connessione e mi sarebbe servita. Alla fine ho risolto aspettando che terminasse la copia e optando per un caffè che mi sarei risparmiato potendo lavorare sullo stesso sistema che utilizzo sempre....

In soldoni, proseguo il percorso consigliato, annotandomi di cercare in rete quali directoryes sono da escludere per clonare un sistema in runtime.

Proseguiamo quindi:
Il secondo punto consisteva nell'editare /etc/fstab mettendo unicamente la linea:

/dev/root / auto defaults 1 1

Banale: nel mio caso ci riferiamo a /media/hdesxterno/path_to_sysbackup/ect/fstab, giusto?
A cosa servirebbe questo linea?

[zoros]

...
Il secondo punto consisteva nell'editare /etc/fstab mettendo unicamente la linea:

/dev/root / auto defaults 1 1

Banale: nel mio caso ci riferiamo a /media/hdesxterno/path_to_sysbackup/ect/fstab, giusto?
A cosa servirebbe questo linea?

la linea in fstab

Codice: Seleziona tutto

/dev/root / auto defaults 1 1

non serve assolutamente a niente, ma purtroppo senza questa linea lo script /etc/rc.d/rc.S fallisce il controllo di integrità del filesystem e va in reboot continuo (insomma, va in loop) ... non entro nel merito della faccenda, ma proprio non ti serve un fstab "tarato" esattamente sulle partizioni esistenti ...

[joe]

Sono incappato in un problema impostando lilo.
Dove mettere lilo?
Avevamo detto nel MBR del disco usb, per poi far partire il pc da usb.

Io ho dato questo comando:
lilo -r /media/wd2/slackware/slack121-sysbackup060309 -M /dev/sda

Quindi come root del sistema ho usato la dir in cui ho copiato il tutto e in cui è presente la dir "etc/" contenete il lilo.conf editato con l'unica linea come detto sopra.

Problema, il PC non parte se ha il disco usb attaccato.
Intendo che non parte proprio, nè dal disco interno ne dal disco esterno: mi ritrovo davanti la scritta ASUS e per sblocarre la situazione devo premere il tasto "power", staccare l'usb del disco e riavviare.
È un comportamento che ho notato da quando avevo preso quell'hd. HD alimentato attraverso il proprio alimentatore, si tratta di un WD da 1 TB...ora non ricordo il nome del modello, dovrei controllare sulla scatola mi sa, ha un case ventilato e nero.
lsusb dice:
Bus 001 Device 005: ID 1058:1001 Western Digital Technologies, Inc. External Hard Disk

Quando avvio il PC, stacco l'usb dell'HD premo power, e attacco di nuovo l'usb...Anche un attimo prima di quando sparisce la scritta ASUS e compare la schermata di GAG. Penso che sia un problema di alimentazione...ma non saprei.
Fatto stà che ho provato anche una manovra del genere:
- HD staccato: accendo il PC
- poco prima che scompaia la scritta ASUS atacco l'usb dell'HD e premo ESC
- posso selezionare il CD, l'HD interno e un anonimo "Removable device": già questo è strano perchè di solito quando è attaccata la pennina usb e premo esc, dice "kingstone data traveler ecc ecc", insomma quel removable device mi fa pensare che non habbia riconosciuto l'hd esterno per quello che è.
Infatti scegliendolo, parte comunque da HDD interno.

Soluzioni:

A) risolvo il problema della partenza "sana" dal disco USB

B) modifico in qualche modo il lilo che sta sulla attale partizione della slack-12.1 (ricordo che nel MBR del dico ho GAG), aggiungendo il disco esterno /dev/sda, in modo da creare la situazione seguente a cascata:
1- avvio dall'HDD interno e parte gag
2- gag passa la palla alla partizione /dev/hdc6 dove nel superblocco trova lilo della 12.1 originale.
3- il lilo di cui sopra mi deve consentire di sclgliere anche il disco esterno, passando la palla al lilo del sistema clonato installato proprio nel MBR del disco.
4- A questo punto è come se avessimo avviato da USB: comanda il lilo che sta nel MBR del disco esterno. In teoria dovrebbe essere in grado d'avviare il sistema clonato.
Ovviamente è tutto da testare.

La soluzione A è decisamente preferibile, perchè mantiene l'avvio indipendente dal disco interno: se fossi costretto alla soluzione B e cancellassila partizione contente la slackware-12.1 originale, se ne andrebbe anche lilo. Quindi non riuscirei ad avviare il lilo che sta sull'HD esterno.

[zoros]

hey joe, mi pare che proprio "non ti piace vincere facile" ... hai un paio di complicazioni da risolvere ...

riallacciandomi a quanto scrivi, ho notato che dischi e pennine USB vengono rilevate per il boot solo se innestate prima di avviare il PC ... se il BIOS si blocca è probabile che non riesca a riconoscere un disco così grande ... può essere anche un problema di interfaccia USB, magari nel BIOS puoi settare qualche paramentro relativo alle porte USB ...

ci sono altri comportamenti che variano tra una scheda madre e l'altra ... per esempio alcuni BIOS se ne fregano del MBR e tentano l'avvio del settore 1, traccia 0, testina 1, che corrisponde al boot-sector della prima partizione (cioè il disco in cui sta Windows di solito) ... quel settore, per dischi molto grandi, è il settore assoluto 63 (il MBR è lo 0) ... per le pennine la geometria è diversa ... per dirti che anche quel settore potrebbe bloccarti il PC ...

direi che non è facile ...

[joe]

Ho cercato un po' in rete e a quanto pare anche altri hanno riscontrato questo problema, ho letto che dipenderebbe dalla scheda madre che proprio non supporta HD così grandi.
La soluzione per non far bloccare il PC all'avvio c'è, ma si tratta di disabilitare dal bios il rilevamento delle periferiche usb all'accensione.
In pratica per evitare il blocco bisogna rinunciare all'avvio da usb. Mi pareva che non vi fosse il serpente che si manga la coda no?

Parliamo di lilo.
Sull'attuale sistema installato in /dev/hda6 ho lilo nel superblock della stessa partizione. All'avvio GAG fa partire questo lilo.
Sarebbe possibile configurarlo per far partire anche il sistema che sta su un'altro HD? Come?
Vista la particolarità della situazione, mi farebbe comodo una opinione circa un possibile lilo.conf.

Grazie intanto per la disponibilità e la pazienza fin qui dimostrata.

[zoros]

...
Grazie intanto per la disponibilità e la pazienza fin qui dimostrata.

Be! ... non ringraziare ... ogni tanto domanda e offerta si incontrano ... perché poi i tuoi "esperimenti" sono utili anche a me, quindi grazie ... è certo però, a questo punto, che il thread è andato proprio fuori tema ...

ho detto in precedenza che alcuni BIOS non caricano il MBR ma tentano un boot del boot-sector della prima partizione (che suona tanto di sudditanza ad un certo OS) ... per questo avevo fatto un "modificatore" del boot-sector (per FAT32, ma forse anche per NTFS), in pratica un semplice codice che non modifica la struttura del boot-sector, ma, se avviato, si occupa di far partire il MBR ... il codice è qui, completo di sorgente ... sinceramente non so se l'idea funziona, o meglio: il codice funziona, non so se effettivamente risolve la situazione descritta ...

per quanto riguarda lilo.conf sarebbe meglio installare un Lilo sulla root (non sul MBR) del disco USB ... a quel punto dall'altro Lilo, quello primario sull'HD ide, la partizione avviabile Linux verrebbe trattata come "other", un po' come si fa con windows:

Codice: Seleziona tutto

other = /dev/sda2
  label = sda2


[joe]

Mmmm, mi sa proprio che c'è un problema bios che blocca tutto. Infatti dopo aver impostato il "lilo interno" come hai suggerito (e avevo già provato qualche giorno fà quella soluzione...senza troppa convinzione). Al boot scelgo la voce "ramusb" che si riferisce al "lilo esterno" installato sul primo settore della partizione /dev/sda2.
Ma ottengo immediatamente l'errore:
Error: 0x01.

Nel README di lilo (/usr/doc/llilo-22.8/README) leggo:

0x01 "Illegal command". This shouldn't happen, but if it does, it may
indicate an attempt to access a disk which is not supported by the
BIOS. See also "Warning: BIOS drive 0x<number> may not be accessible"
in section "Warnings"

Cercherò ulteriori info in rete, ma potrebbe anche essere che non si riesca proprio a concretizzare questa soluzione.
Forse paradossalmente disabilitando nel bios il rilevamento di periferiche usb da cui fare il boot, non sarei costretto a staccare il disco all'avvio per evitare il blocco....manovra che potrebbe forse dare problemi al successivo riconoscimento del disco anche senza tirare in ballo direttamente l'avvio da usb.

In ogni caso, vedo sul wikislack che vi è anche un guida che propone un metodo differente: ovvero utilizzare direttamente il lilo interno per avviare il sistema del disco usb....senza troppi passaggi tra bootloaders.
Nel frattempo ieri sera ho ceduto alla creazione di una nuva partizione da 15 GB /dev/sda3 formattata in ext3. Dentro vi ho copiato il sistema che avevamo clonato sulla /dev/sda2....

OT: parted non supporta il ridimensionamento del filesystem ntfs, infatti quei 15GB li ho ricavati ridimenisionando la partizione da 200 GB che avevo formattato in ntfs. Ho eseguito l'operazione rimuovendo tale partizione e ricreandola da 185GB poi ho creato quella da 15GB. Ora vedo che vi è il comando "ntfsresize" che probabilmente mi avrebbe consentito di ridimensionare prima il filesystem e forse in seguito parted sarebbe riuscito a ridimensionare la partizione.... invece così adesso devo ricreare il filesystem ntfs con mkfs.ntfs, non è un problema, ma è un'operazione piuttosto lenta.

Insomma, adesso ho una partizione da 15GB /dev/sda3 formattata in ext3 e contenete il sistema clonato. Farò qualche prova, magari seguendo la guida del wiki, giusto per prendere più confidenza con ramdisk, lilo ecc. Infatti potrebe anche essere che nelle operazioni fi qui svolte abbia ciccato qualche punto.
Vi terrò aggiornati sugli sviluppi.

[joe]

Allora, la guida che ho seguito e questa:
http://www.slacky.eu/wikislack/index.ph ... rom_usb%22.
EDIT: Il link sopra non funge provate con questo: http://tinyurl.com/nt5ndv

In sintesi la guida prevede l'installazione di slackware in una partizione dell'hd esterno e l'impostazione del MBR dell'HD interno per avviarla.

Nel mio caso ho la partizione /dev/sda3 dell'hd esterno in cui ho copiato la slackware-12.1. Quindi non l'ho installata nel modo classico, ma ho usato cp...
Inoltre ho installato lilo non nel MBR del disco interno ma nel superblocco della partizione /dev/hda6, che vado a pescare con gag all'accensione della macchina.
Aggiungo che la ricompilazione del kernel non l'ho eseguita utilizzando già un kernel huge-smp della 12.1:
a questo proposito devo evidenziare che la voce CONFIG_PARTITION_ADVANCED è settata ad "y" nel kernel huge, mentre la guida consigliava di disabilitarla....ho tenatato comunque lascaindola. Per info:
http://cateee.net/lkddb/web-lkddb/PARTI ... ANCED.html

Purtroppo in fase d'avvio ottengo un errore che ho copiato a mano (carta e penna) e che vi riporto:

Codice: Seleziona tutto

Delay riconoscimento unita usb
initrd.gz: Loading kernel modules from initrd image
mount: mountinng dev sda3 on /mnt failed: No such device or address.
ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.
              You can try to fix it. Type `exit' when things are done.
/bin/sh: can't access tty: Job control turned off.
/ $_


Ecco, non sò, da questo errore sapreste dirmi qualcosa di più su cosa e perchè non ha funzionato?
Grazie in anticipo, a presto.