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 list [email protected] http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp
