Ah vabè, non cambia molto ;) allora diciamo che per me è bruto cambiare l'uuid oltre a non capirne l'utilità o meglio, la praticità in caso di recovery, come home scritto precedentemente
On 28 Apr 2017 12:03 am, "Giancarlo Dessì" <[email protected]> wrote: > bruto con una t, non brutto ;) > > Il 27/04/2017 23:52, Filippo Meloni ha scritto: > > Non riesco a capire cosa intenda con soluzioni brutte. È normale prassi > utilizzare lo standard /dev/** nella configurazione di grub e fstab. > Inoltre usando i device hai anche meno problemi con il BIOS è il disco di > first boot. > > È molto più brutto modificare l'uuid di un disco ogni volta, soprattutto > se si tratta di procedure automatiche. > > > > On 27 Apr 2017 7:32 pm, "Giancarlo Dessì" <[email protected]> wrote: > >> Ma si tratta di soluzioni brute che accantonano il problema e possono >> generare il conflitto nei casi non previsti. Ad esempio, GRUB configurato >> dalla slackware non incontra problemi, il fstab della slackware l'avevo già >> impostato per riferire allo standard /dev/sdx, ma avevo dimenticato di >> adattare il fstab di Ubuntu. E infatti ubuntu mi montava entrambe le >> partizioni sullo stesso punto di mount! Peraltro mi risulta che l'UUID è >> tenuto in particolare considerazione in ambiente Windows. Non è il mio caso >> dato che non ho sistemi Windows installati (alleluja, ho da un po' tagliato >> definitivamente il cordone ombelicale) però non credo che sia cosa buona e >> giusta mantenere due partizioni con UUID e etichette di volume uguali nella >> stessa macchina se ospita anche un sistema Windows. >> >> Comunque, Roberto Metere mi ha dato l'imbeccata giusta, dopo i vari >> aggiustamenti penso di essere riuscito a superare il problema, devo solo >> fare il test finale. Il primo si è interrotto a causa di un errore di >> sintassi nello script al momento di fare e2fsck. >> >> Il 27/04/2017 17:59, Filippo Meloni ha scritto: >> >> Puoi ovviare al cambio di UUID configurando GRUB in modo che utilizzi il >> device /dev/sd* invece che l'UUID e configurando fstab nello stesso modo, >> evitando gli UUID >> >> Il giorno 27 aprile 2017 10:12, Giancarlo Dessì <[email protected]> ha >> scritto: >> >>> Ciao lista, >>> >>> dopo anni e anni di rischi di perdita dei dati, pur disponendo dei >>> dischi di riserva, mi sono finalmente deciso a predisporre un sistema di >>> backup. Il disco master ha tre partizioni primarie (per ubuntu, slackware e >>> swap) e 5 partizioni logiche per i dati, di cui due usate per tenere >>> separate le directory /var/lib e /var/www della slackware, allo scopo di >>> mantenere i database MySQL e il sito web in caso di reinstallazione. Il >>> disco di riserva ha un partizionamento uguale. >>> >>> Il backup è impostato con una serie di script bash, uno per ciascuna >>> partizione, ad eccezione della swap, che possono essere eseguiti >>> all'occorrenza in modo indipendente oppure richiamati in concatenazione da >>> uno script genitore. Quest'ultimo è avviato da cron ogni lunedì alle 7.15: >>> a quell'ora esco per andare al lavoro, perciò lascio il computer acceso per >>> eseguire i job, al termine dei quali si avvia lo shutdown. Il tutto gira >>> sulla slackware. Per ogni script la sequenza di operazioni è la seguente: >>> mount della partizione del disco di riserva (1) registrazione dell'avvio su >>> un file di log (2) esecuzione del backup (3) registrazione del >>> completamento sul file di log (4) smontaggio della partizione di backup. >>> >>> Ogni script usa rsync per fare la copia completa di ciascuna partizione >>> ad eccezione di quello relativo alla partizione della slackware (su >>> /dev/sda2). Quando è avviata la slackware le altre partizioni sono montate >>> e quindi rsync lavorerebbe anche sulle partizioni montate, con conseguente >>> saturazione della partizione di backup su /dev/sdb2. Per evitare una >>> concatenazione di comandi rsync per ciascuna directory della radice della >>> slackware ho perciò pensato di fare il backup a basso livello con dd >>> if=/dev/sda2 of=/dev/sdb2. Peraltro credo che sia una soluzione migliore >>> nel caso dovessi avviare, all'occorrenza, il sistema dal disco sdb: >>> basterebbe invertire i cavi e ritoccare alcuni collegamenti simbolici da >>> una live. >>> >>> Dopo varie prove per correggere gli errori, alla fine il tutto funziona, >>> sia manualmente sia con il cron. Tranne un piccolo dettaglio. Facendo un >>> sistema di backup analogo nel computer di mia moglie, in cui gira di >>> default la Ubuntu, ho notato che l'esecuzione del backup con dd cambia >>> anche lìUUID della partizione immagine (/dev/sdb1) assegnandogli lo stesso >>> UUID della partizione master (/dev/sda1). Nel mio pc non me ne ero accorto >>> perché monto le partizioni identificandole con il tradizionale /dev/sdX >>> invece dell'UUID. Con blkid ho però verificato che la partizione di backup >>> della slackware ha lo stesso UUID della partizione master. >>> >>> La cosa mi urta perché non vorrei che un giorno saltasse fuori qualche >>> conflitto a causa di qualche applicazione che pasticcia con due partizioni >>> che hanno lo stesso identificatore. Apparentemente sembra che il sistema >>> non ne risenta, anche perché le partizioni di sdb sono normalmente smontate >>> e lo stesso GRUB, pur usando l'UUID, carica regolarmente il kernel dal >>> disco sda, ma non mi fido. A questo punto la sola alternativa che mi viene >>> in mente è quella di fare il backup con una serie di comandi rsync >>> concatenati per ciascuna directory, escludendo i punti di mount delle altre >>> partizioni, ma vorrei una soluzione più semplice. Mi vengono in mente due >>> opzioni (ammesso che siano possibili): >>> >>> 1) eseguire dd evitando che modifichi l'UUID della partizione di backup >>> >>> 2) eseguire in automatico una sovrascrittura dell'UUID subito dopo >>> l'esecuzione di dd riassegnandogli quello precedente >>> >>> Non so se sia possibile farlo o se esistono altre strade possibili, >>> perciò ben venga qualsiasi suggerimento. >>> >>> Ringrazio per l'attenzione, ciao. >>> >>> PS: visto che mi sto facendo un'esperienza in proposito, potrebbe essere >>> utile per farne un talk per il prossimo linux day? >>> >>> -- >>> ********************************************************* >>> Giancarlo Dessì >>> http://www.giand.it >>> http://twitter.com/gian_d_gian >>> >>> Slackware Linux... because it works! >>> ********************************************************* >>> >>> _______________________________________________ >>> Gulchelp mailing list >>> [email protected] >>> http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp >>> >> >> >> >> _______________________________________________ >> Gulchelp mailing >> [email protected]http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp >> >> >> -- >> ********************************************************* >> Giancarlo Dessìhttp://www.giand.ithttp://twitter.com/gian_d_gian >> >> Slackware Linux... because it works! >> ********************************************************* >> >> >> _______________________________________________ >> Gulchelp mailing list >> [email protected] >> http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp >> >> > > _______________________________________________ > Gulchelp mailing > [email protected]http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp > > > -- > ********************************************************* > Giancarlo Dessìhttp://www.giand.ithttp://twitter.com/gian_d_gian > > Slackware Linux... because it works! > ********************************************************* > > > _______________________________________________ > Gulchelp mailing list > [email protected] > http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp > >
_______________________________________________ Gulchelp mailing list [email protected] http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp
