Ridimensionamento e backup di partizioni

Ho cominciato a capire a quale applicativo posso affidarmi per eseguire il backup di partizioni, in vista del prossimo avanzamento di versione da fc-32 fino a fc-35.

Ho provato a salvare una partizione dove qualche giorno fa ho installato con tanta fatica fc-34.
Ho visto con GParted (già presente in una pendrive) che la partizione impegnava oltre 110 GiB a fronte di circa 5,78 GiB usati.
Ho pensato di ridimensionare la partizione in modo da potere poi copiare il suo contenuto in uno spazio di circa 10,80 GiB (mi sono mantenuto largo per prudenza).
Ho generato in un altro disco una partizione di pari dimensione ed ho avviato la copia.

Finita la copia, prima di cancellare il contenuto della partizione di partenza, ho riavviato proprio fc-34, soprattutto per verificare che continuasse a funzionare dopo il ridimensionamento della partizione che lo contiene, ma ahimè, non parte.

Inoltre il GParted della pendrive mi segnala un anomalia di gestione sul tipo di file “btrf”
Anche il file copiato da GParted è di tipo “btrf”.

Francamente non capisco. I file erano già così, prima del ridimensionamento e funzionava tutto.

Perchè fc-34 NON parte più?

La mia è solo una supposizione, ma potrebbe dipendere anche dal fatto che ridimensionando la partizione l’UUID del disco è stato cambiato ed è il motivo per il quale il sistema non si avvia… almeno credo.
Potresti fare un tentativo controllando da una live se l’UUID presente sul file /etc/fstab corrisponde effettivamente all’UUID della partizione attuale.

@ oStile10001

Ho guardato:

  • in Gparted la partizione ridimensionata è la sdd3
  • in
[petrus@petrus ~]$ ls -l /dev/disk/by-uuid
totale 0
lrwxrwxrwx. 1 root root 10  3 feb 18.00 1518-E4FA -> ../../sdc5
. . .
lrwxrwxrwx. 1 root root 10  3 feb 18.00 46dd87b4-8b17-4aea-85fa-e3af90a26f4e -> ../../sdd3
. . .
lrwxrwxrwx. 1 root root 10  3 feb 18.00 B3D4-AD39 -> ../../sdd1
. . .
lrwxrwxrwx. 1 root root 10  3 feb 18.00 7eba1092-fd6d-4549-a94b-8601edb4dccb -> ../../sdd2
. . .

e in “$ sudo mount /dev/disk/by-uuid/46dd87b4-8b17-4aea-85fa-e3af90a26f4e /mnt” di sdd3 risulta:

$ cat /mnt/root01/etc/fstab

#
# /etc/fstab
# Created by anaconda on Sun Jan 30 11:24:57 2022
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
# partizione sdd3
UUID=46dd87b4-8b17-4aea-85fa-e3af90a26f4e /                       btrfs   subvol=root01,compress=zstd:1 0 0
#
# partizione sdd2
UUID=7eba1092-fd6d-4549-a94b-8601edb4dccb /boot                   ext4    defaults        1 2
# partizione UEFI (sdd1)
UUID=B3D4-AD39          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=46dd87b4-8b17-4aea-85fa-e3af90a26f4e /home                   btrfs   subvol=home01,compress=zstd:1 0 0

No, purtroppo per me, come puoi vedere lo UUID non è cambiato. Se fosse cambiato mi diventerebbe tutto più semplice.

Grazie per la lampadina accesa.

Che dice un check sulla partizione, smontata mi raccomando?

# btrfs check --readonly /dev/sdd3

Purtroppo la prova non posso farla. Il disco è stato formattato e ripartizionato per ospitare solamente dati.
:man_shrugging:

Grazie lo stesso.