windows 11 pro e slackware 15 [risolto]

[Rama]

il cubo o lo scivolamento è il solo effetto spezziale che mantengo, però ho nostalgia dell'effetto pioggia, era veramente perfetto;
lo so, non serviva a nulla ma i visitatori rimanevano stupiti;

[Rama]

è possibile trasferire la Slack dall'unica partizione del secondo disco in cui si può installare in un'altra sul primo disco che sia lei (dopo installata) che Debian vedono?

[rik70]

è possibile trasferire la Slack dall'unica partizione del secondo disco in cui si può installare in un'altra sul primo disco che sia lei (dopo installata) che Debian vedono?

Certo. Dovrai poi aggiustare qualcosa ovviamente.

Offtopic:
La faccenda GRUB vs LILO meriterebbe un approfondimento. Mi sa che apro un'altra discussione.

[gian_d]

La cosa mi incuriosisce: lo spostamento di un'installazione da una partizione/disco ad un'alta come andrebbe fatto? immagino con dd o sbaglio?
Sul merito di "aggiustare" presumo che ti riferisca ad esempio ai riferimenti al disco/partizione sul bootloader a /etc/fstab et similia.

[albatros]

Con dd copi anche la struttura del filesystem e ci fai una copia esatta, ma se dimensioni o tipo del filesystem sono diversi io userei rsync.

[Rama]

risolto alla mia maniera, cioè come lo zio Podger quando appende un quadro ;-P
visto che gparted non dava errori (una volta installata la Slack sul disco) ho voluto vedere cosa succedeva con il dvd d'installazione (Slackware Live) e qui c'erano cose strane: la partizione da 100 giga sul primo disco dove volevo installare la Slack risultava ext4 ma subito prima c'era un campo dove spuntava un riferimento a windows;
ho quindi fatto una riformattazione veloce, senza cancellare il contenuto, e l'installer l'ha finalmente vista e l'installazione è partita;
nat. non ho perso occasione per incasinare tutto, quindi quando si è arrivato al punto a mettere il bootloader gli ho detto di usare Lilo, malgrado mi avesse avvertito che non era un disco MBR;
pensavo che una volta non andato a buon fine Lilo bastasse dirgli di usare Elilo, cosa che ha fatto col risultato che il bios non vedeva affatto la partizione e ho dovuto rifare l'installazione;

direi che 'sta Live è da raccomandare ai neofiti:
ha i pacchetti aggiornati (ad inizio marzo quella che ho scaricato io);
l'installazione è in grafica -pseudo: è come nella Slack, solo che la finestra in cui la si fa è all'interno di un desktop con sfondo, barra, ecc...;
consente di creare un user in fase d'installazione, la mancanza di questo è un grosso scoglio per i novizi;

nat. ci sono aspetti negativi:
l'avvio è molto lento, presumo perché carica proprio tutto in ram, non aspetta che uno richiami un programma per farlo;
non consente di scegliere cosa installare, quindi sto procedendo a una bella ripulita con pgktool;

ora cerco di restare calmo qualche giorno e documentarmi su come modificare Elilo per usare un kernel compilato prima di pasticciare, ma dubito ci riesca ;-P

[rik70]

ora cerco di restare calmo qualche giorno e documentarmi su come modificare Elilo per usare un kernel compilato prima di pasticciare, ma dubito ci riesca ;-P

La sintassi del config di elilo è molto simile a quella di lilo.
Devi solo stare attento se/quando lanci 'eliloconfig', in quanto copia nella partizione EFI il loader, il link simbolico /boot/vmlinuz - che se è lo huge va bene, ma se è il generic son 'azzi se non gli aggiungi anche l'initrd - e sovrascrive elilo.conf.

Di default tutta sta 'roba sta in '/boot/efi/EFI/Slackware' e lì dovrà andare anche il tuo kernel personalizzato e il suo initrd.

Morale:
se intendi usare elilo devi fare tutto a mano, soprattutto se usi il kernel generic. Non esiste un comando simile a lilo -v che ti salva la cuffia.

Oppure prova refind, che è una bomba secondo me.

[rik70]

La cosa mi incuriosisce: lo spostamento di un'installazione da una partizione/disco ad un'alta come andrebbe fatto? immagino con dd o sbaglio?
Sul merito di "aggiustare" presumo che ti riferisca ad esempio ai riferimenti al disco/partizione sul bootloader a /etc/fstab et similia.

Come diceva albatros, dd va bene se la partizione di destinazione è identica come dimensione a quella di partenza.
Se invece è più grande, puoi usare 'partclone' e poi riespandere il filesystem della nuova partizione.
Altrimenti rsync, coi flag '-aAXv'.

Con dd e partclone occhio però che avrai 2 UUID del filesystem identici: il 'vecchio' dovrai eliminarlo.

Sì, poi se usi rsync per clonare su un nuovo filesystem devi aggiustare nel caso fstab e probabilmente anche il bootloader, se entrambi utilizzano gli UUID.

[Rama]

alla fine non credo di aver bisogno di pasticciare con elilo;
gli è che ho la fissazione di usare un governatore di frequenza, per questo compilo, ma a quanto pare non c'è bisogno, gkrellm mi dà una frequenza con minimo 2400, media attuale 2600 e massimo 4200, il che corrisponde alle specifiche del processore, i5-8279U;
sono contento: ho mantenuto Win11 e messo la Slack;
aprop di Win, fo sommessamente notare che non riconosce il masterizzatore blu-ray esterno su usb mentre i vari Linux non fanno una piega;

[gian_d]

Con dd copi anche la struttura del filesystem e ci fai una copia esatta, ma se dimensioni o tipo del filesystem sono diversi io userei rsync.

Ecco, il mio dubbio è se, a differenza di dd, rsync faccia una copia esatta dell'intero albero di directory, ovvero faccia una clonazione perfetta dell'installazione. Se la memoria non mi inganna, rsync restituisce degli errori nel momento in cui va a copiare alcuni file speciali. Purtroppo non ricordo quali, ma ricordo che in passato nel fare dei backup mi sono scontrato con questi errori e alla fine mi sono accontentato di fare solo i backup dei dati e di file di sistema importanti da recuperare e inserire in una nuova installazione pulita (es. configurazioni personalizzate del sistema e degli utenti).

Ovviamente questa è una concezione sporca del backup. In un mondo perfetto (ammesso che esista...) il mio backup ideale sarebbe quello di fare un clone perfetto di un'installazione che permetta di avviarla al posto dell'originale nel caso si scassi il disco dell'originale o venga scarciofato (leggi "corrupt") il file system dell'originale (es. incautamente ho fatto da root rm -r * nella directory radice). Presumo (o forse mi sbaglio) che tutto questo non si possa fare con rsync e si debba necessariamente ricorrere a dd.

Restiamo in un contesto probabile in cui potremmo usare dd: supponiamo che il filesystem sia lo stesso (ext4), il punto cruciale è se la partizione di partenza e quella di destinazione abbiano le stesse dimensioni. A questo punto il problema si riconduce a tre possibili contesti:
1) partizione input e partizione output hanno le stesse dimensioni. Il problema non sussiste, dd è la soluzione ottimale

2) input ha una dimensione maggiore di output. Il problema esiste ma non è risolvibile, non si può cavare vino dalle rape.

3) input ha una dimensione minore di output. Ecco, qui ho un dubbio atroce: cosa succede? dd lascia lo spazio residuo della partizione di destinazione trattandolo come spazio vuoto del file system che si aggiunge automaticamente a quello che è stato scritto? Sarebbe la soluzione ottimale, in sostanza si trasferisce un'installazione in uno spazio più grande (e disponibile) mantenendone l'integrità operativa. Ma se così non è allora non ho idea di cosa possa succedere.

Tutto questo al netto del fatto che ricorrere a dd per fare un backup frequente di un sistema non è certo il massimo dal momento che si sottopone il disco di destinazione a stress sistematici per lo più inutili.

[gian_d]

La cosa mi incuriosisce: lo spostamento di un'installazione da una partizione/disco ad un'alta come andrebbe fatto? immagino con dd o sbaglio?
Sul merito di "aggiustare" presumo che ti riferisca ad esempio ai riferimenti al disco/partizione sul bootloader a /etc/fstab et similia.

Come diceva albatros, dd va bene se la partizione di destinazione è identica come dimensione a quella di partenza.
Se invece è più grande, puoi usare 'partclone' e poi riespandere il filesystem della nuova partizione.
Altrimenti rsync, coi flag '-aAXv'.

Con dd e partclone occhio però che avrai 2 UUID del filesystem identici: il 'vecchio' dovrai eliminarlo.

Sì, poi se usi rsync per clonare su un nuovo filesystem devi aggiustare nel caso fstab e probabilmente anche il bootloader, se entrambi utilizzano gli UUID.

Ops, mentre scrivevo la risposta ad Albatros non mi ero accorto della tua. In effetti hai risposto ai miei dubbi! Quindi la soluzione migliore sarebbe rsync con i flag adeguati. Devo verificare negli script che avevo fatto per i backup la corrispondenza dei flag usati per rsync. Fino a qualche anno fa lo usavo per fare un backup settimanale che lanciavo il sabato mattina con cron mentre andavo al lavoro, poi è passato tutto in cavalleria da quando ho acquistato un po' di dischi aggiuntivi per ampliare lo spazio e revisionata tutta l'architettura dello storage.Nel frattempo sono passati un paio d'anni, a mio rischio e pericolo perché non sto facendo il backup oltre a mantenere un paio di dischi da un TB ciascuno inutilizzati.

Prima o poi devo decidermi a rimettere in auge l'impianto con tutte le buone intenzioni

[erio]

visto che e' una cosa che faccio...usare dd il problema della differenza di dimensione del disco non si pone basta che sia piu' grande quando ha finito di clonare il disco io uso gparted, far fare un controllo del disco che fa espandere la partizione alla sua grandezza reale, penso vada bene anche fsck.

[gian_d]

Naturalmente il discorso degli UUID è una questione di lana caprina. Io li uso sia per grub sia per fstab ma la loro gestione non è un aspetto complicato, anzi, volendo si potrebbe anche studiare un sistema che mantenga sui backup delle configurazioni di riserva pronte all'uso. A quel punto l'eventuale ripristino di un sistema si ridurrebbe alla modifica delle impostazione nel bios del disco da avviare. Detto così sembra semplice, è tutto il resto che richiede tempo e pazienza per predisporlo... :-\

@ erio: il problema però è che a differenza di rsync dd è molto più lungo e martoria di più i dischi.

[erio]

rsync o dd i dati devono essere trasferiti sul nuovo disco quindi lo stress e' assicurato per entrambi i modi e se si usa gparted non ci sono due uuid ma solo quello in uso quando fa il controllo.

[albatros]

Dipende da cosa copi con dd. Per alcuni anni l'ho usato per fare una copia "esatta" delle mie 4 partizioni (mbr) del vecchio portatile in un hard disk esterno più grande. Facevo qualcosa tipo

Codice: Seleziona tutto

for i in {1..4}
do
dd if=/dev/sda$i of=/media/user/backup_p$i 
done

Questa è una copia byte per byte delle partizioni in dei files, la puoi usare ad esempio anche per cercare file cancellati con software appositi.
Usandola al contrario potevo ripristinare lo stato del portatile al momento del backup con uno sforzo minimo, mentre se avevo bisogno di accedere ai dati di una partizione salvata in questo modo potevo montare il filesystem clonato su file come dispositivo loopback.
Però puoi usare dd anche per copiare singoli file o un device.

Negli ultimi tempi preferisco usare rsync, che è molto più veloce, usura meno i dischi e ben si presta a backup giornalieri e remoti.
I file che creano problemi sono quasi sempre file speciali che non ha senso salvare, tipo, non so, la partizione /proc, che già escludo dal backup, copiando solo i dati e i file di configurazione, non il software di sistema.

Consiglio di non sottovalutare l'importanza di backup frequenti e di copie dei dati più importanti in luoghi fisicamente distanti o su server remoti.