Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#26 25-03-2022 23:45:11

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

willy64 a écrit :

il faut éviter de connecter le disque et son clone en même temps sur le même ordinateur car l'utilisation simultané a tendance à perturber le système qui ne sait pas lequel prendre des deux


C'est précisément le but ici, donc clonage simple inapplicable.

willy64 a écrit :

Si on veut un clonage en simultané, le mieux est de se tourner vers une solution de raid matériel ou logiciel


Très mauvaise idée. Le RAID réplique les erreurs de manipulation, effacements accidentels et corruptions de données sur tous les disques.
Le RAID, c'est pour la tolérance de panne ou la performance et c'est tout, pas pour le clonage et encore moins la sauvegarde.


Il vaut mieux montrer que raconter.

En ligne

#27 26-03-2022 00:27:27

willy64
Membre
Inscription : 21-03-2019

Re : [résolu] cloner un SSD chiffré

raleur a écrit :

Très mauvaise idée. Le RAID réplique les erreurs de manipulation, effacements accidentels et corruptions de données sur tous les disques.
Le RAID, c'est pour la tolérance de panne ou la performance et c'est tout, pas pour le clonage et encore moins la sauvegarde.


Oui je connais le principe du Raid mais d'après ce que j'ai compris de la demande, totoZero7 veut avoir un ssd de secours afin de prendre le relais si son ssd principal plante. Donc, soit il fait régulièrement un clone de son SSD afin d'avoir un ssd le plus à jour possible en effectuant une sauvegarde de ses données personnelles à intervalle régulier (toutes les 30 minutes, 2 h, 6 h, etc. soit il met en place un système raid. Bien évidemment, le raid ne protège pas des erreurs de manipulations humaines, là dessus je suis d'accord. Et je n'ai pas dit que le Raid était une sauvegarde, j'ai utilisé le mot "clonage" simplement car en Raid 1, les données sont copiées sur les deux disques, donc au niveau des données, il y a clonage, dédoublement, copie, bref, les données sont écrites sur les deux disques et en cas de défaillance de l'un ou de l'autre, le système peut continuer à fonctionner.

J'ai posté simplement parce que je trouve que c'est bien plus compliqué de changer l'UUID, pour un système destiné au "secours" en cas de plantage du premier, tout en assurant une copie des données les plus récentes. C'est un peu usine à gaz alors que des solutions simples pourraient être envisagées et si c'est un soucis de continuité de fonctionnement, opter pour le Raid 1 smile

Hors ligne

#28 27-03-2022 15:42:48

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

Je reformule pour désactiver spécifiquement de SSD


Voici ce que j'ai à l'écran quand j'ai une clé usb branchée que je viens de démonter (avec l'utilitaire Disques ou avec le terminal).

lsblk -f

sdc                                                                                                        
└─sdc1                  vfat        FAT32    tosh16Go B351-D30E



Avec l'utilitaire Disques (gnome-disk-utility), il y a une case pour "éjecter ce disque"
Si je clique dessus et qu'ensuite je fais un lsblk -f, je ne vois plus la clé USB avec la commande lsblk -f

lsblk -f

vide




Maintenant, si je veux faire pareil avec le SSD et que tout est démonté, ça affiche ceci:

sdd                                                                                                        
├─sdd1                  ext2        1.0               1ad1838b-a329-45f9-9be8-0610fea0e30f                  
├─sdd2                                                                                                      
└─sdd5                  crypto_LUKS 2                 4b40da24-1506-4705-80b8-66d072b9c9ad  



Mais l'utilitaire ne me propose pas "d’éjecter le disque".

C'est pour cela que je cherche la solution avec le terminal
Comment éjecter avec le terminal ?

J'ai une autre question
Est-ce que "démonté" est suffisant pour retirer le disque SSD d'un port USB (ou autre) en toute sécurité ou faut-il absolument que le disque soit démonté ET éjécté avant de le retirer ?

Hors ligne

#29 27-03-2022 17:32:34

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

J'ai rencontré un changement - Le NOM de volume se renomme tout seul
Après l'étape "Renommer [sda5_crypt]" qui a été réussi, j'ai arreté et éteint le disque.

Quand j'ai ouvert de nouveau le volume chiffré, le NOM avait changé.
J'avais initialement changé pour "sdclone_crypt" avec cette commande:

sudo dmsetup rename luks-4b40da24-1506-4705-80b8-66d072b9c9ad sdclone_crypt



Et là ça m'affiche "crypto_LUKS" comme NOM quand je l'ouvre.
Cela dit, j'ai ouvert en mettant ce nom (enfin, je pensais que crypto_LUKS était le système de fichier et non le NOM)
# j'ai ouvert le volume chiffré ainsi

sudo cryptsetup open --type luks /dev/sdd5 crypto_LUKS



lsblk -f

sdd                                                                                                          
├─sdd1                    ext2        1.0               1ad1838b-a329-45f9-9be8-0610fea0e30f                  
├─sdd2                                                                                                        
└─sdd5                    crypto_LUKS 2                 4b40da24-1506-4705-80b8-66d072b9c9ad                  
  └─crypto_LUKS         LVM2_member LVM2 001          yIJgYh-oT4j-BkqR-7qe4-4weR-eGDI-b8WZ2f                
    ├─debM11SSDclo-root   ext4        1.0               0c670bab-560f-4b24-8854-5f6026f8e1d7                  
    └─debM11SSDclo-swap_1 swap        1                 c602329f-c370-4d7f-83cb-505fc13b33be  





Maintenant, si j'ouvre avec l'utilitaire de disque, il me remets "luks-4b40da24-1506-4705-80b8-66d072b9c9ad" comme NOM.

J'en déduis qu'on peut ouvrir en métant le NOM de son choix.


Question
------------
Si je veux faire une manipulation avec le nom "crypto_LUKS" mis lors de l'ouverture du volume chiffré et que le nom dans /etc/crypttab soit "sdclone_crypt",
Est-ce que ça craint ?

Comment ça se fait que le volume ne s'ouvre pas avec le bon NOM même avec l'utilitaire ?
Comment savoir le nom d'ailleurs, vue de l'extérieur ? Et-il possible d'ouvrir avec le vrai NOM sans le savoir avant ?

Hors ligne

#30 27-03-2022 18:26:14

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

totoZero7 a écrit :

C'est pour cela que je cherche la solution avec le terminal
Comment éjecter avec le terminal ?


Démonter les systèmes de fichiers, désactiver les volumes logiques, fermer les volumes chiffrés suffit. Il est inutile d'éjecter. Si tu "éjectes" le support, tu ne pourras plus l'utiliser sans le débrancher et le rebrancher.

totoZero7 a écrit :

Si je veux faire une manipulation avec le nom "crypto_LUKS" mis lors de l'ouverture du volume chiffré et que le nom dans /etc/crypttab soit "sdclone_crypt",
Est-ce que ça craint ?


Oui, cela peut perturber update-initramfs pour générer l'initramfs. update-initramfs doit déterminer quels volumes chiffrés dans /etc/crypttab doivent être ouverts par l'initramfs, et pour cela il compare les noms des volumes dans /etc/crypttab et les noms des volumes chiffrés ouverts. Un moyen de forcer l'ouverture d'un volume chiffré par l'initramfs consiste à ajouter l'option "initramfs" pour ce volume chiffré dans /etc/crypttab.

totoZero7 a écrit :

Comment ça se fait que le volume ne s'ouvre pas avec le bon NOM même avec l'utilitaire ?
Comment savoir le nom d'ailleurs, vue de l'extérieur ? Et-il possible d'ouvrir avec le vrai NOM sans le savoir avant ?


Un volume chiffré LUKS n'a pas de nom intrinsèquement. Il n'a que le nom qu'on lui donne arbitrairement lors de son ouverture.


Il vaut mieux montrer que raconter.

En ligne

#31 28-03-2022 11:52:10

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

Je rencontre un problème avec crypttab


- J'ai démarré sur mon SSD1 (et non sur le Live).
- J'ai branché le SSD2 et l'ai déverrouillé en lui donnant le NOM "sdclone_crypt" Le même nom que celui qui est dans le fichier /etc/crypttab

sudo cryptsetup open --type luks /dev/sdd5 sdclone_crypt


- Activé les volumes logiques

sudo vgchange -ay debM11SSDclo


- Puis monté la partition système dans ce répertoire :

sudo mount /dev/mapper/debM11SSDclo-root /mnt/plouf/



- Puis monté ces périphériques et lancé chroot

sudo mount --bind /dev/ /mnt/plouf/dev
sudo mount --bind /sys/ /mnt/plouf/sys
sudo mount -t proc /proc /mnt/plouf/proc
sudo chroot /mnt/plouf /bin/bash
sudo mount -a



- Je lance la reconstruction de l'initramfs et j'obtiens un avertissement

update-initramfs -u


cryptsetup: WARNING: target 'sda5_crypt' not found in /etc/crypttab




Là je ne comprends pas car j'ai biens suivi la procédure.
Pourquoi il me demande "sda5_crypt" ?
Note: je suis sur mon SSD1 et lui s'appelle 'sda5_crypt' mais bon. Si je suis sur l'autre système grâce à chroot, ça ne devrait pas se mélanger... si ?

Hors ligne

#32 28-03-2022 13:33:45

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

update-initramfs ne devrait se préoccuper que des volumes chiffrés supportant la racine ou le swap sélectionné pour l'hibernation.
Toujours dans le chroot, regarde dans /etc/initramfs-tools/conf.d/resume si le swap indiqué dans la variable RESUME n'est pas encore celui du système originel ou "auto". Dans ce cas modifie-le comme dans /etc/fstab, et update-initramfs ne devrait plus afficher l'avertissement.

Il vaut mieux montrer que raconter.

En ligne

#33 28-03-2022 13:57:11

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

Il était mis sur l'ancien. Je l'ai changé et c'est passé

Pour update-grub, ça a changé le grub de SSD1 et non de SS2 on dirait (debM11SSD2 = SSD1)  (debM11SSDclo = SSD2)

root@debM:/# sudo update-grub


Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-11-amd64
Found initrd image: /boot/initrd.img-5.10.0-11-amd64
Found linux image: /boot/vmlinuz-5.10.0-10-amd64
Found initrd image: /boot/initrd.img-5.10.0-10-amd64
Found Debian GNU/Linux 11 (bullseye) on /dev/mapper/debM11SSD2-root
done



C'est pas le grub de SSD1 qui devrait changer ?

Hors ligne

#34 28-03-2022 14:10:04

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

autre chose, quand j'ouvre un autre terminal, je m'aperçois que mon disque secondaire "disk3" est monté sur "/mnt/plouf" alors qu'il devrait être monté sur /disk3

toto@debM:~$ lsblk -f


NAME                      FSTYPE      FSVER    LABEL    UUID                                   FSAVAIL FSUSE% MOUNTPOINT
sdb                                                                                                          
└─sdb1                    crypto_LUKS 1                 5b8a3dc3-3fdd-4045-a5a2-11fc067fdfd6                  
  └─sdb1                  ext4        1.0      other    7e9ee5ca-dc94-4ca7-b4a6-d8f9202e7bcf    289,2G    63% /mnt/plouf/disk3





je n'ose pas fermer l'ordi de peur d'avoir fait une erreur

Hors ligne

#35 28-03-2022 14:14:20

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

os-prober a détecté le système installé dans debM11SSD2, donc update-grub a mis à jour la configuration de debM11SSDclo (os-prober ne détecte pas le système depuis lequel il est exécuté). Tu peux vérifier dans /boot/grub/grub.cfg.

Il vaut mieux montrer que raconter.

En ligne

#36 28-03-2022 14:17:57

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

totoZero7 a écrit :

quand j'ouvre un autre terminal, je m'aperçois que mon disque secondaire "disk3" est monté sur "/mnt/plouf" alors qu'il devrait être monté sur /disk3


Si ce montage est défini dans /etc/fstab, il a été effectué lors de l'exécution de mount -a dans le chroot. Il est peut-être monté deux fois, vérifie dans /proc/mounts.


Il vaut mieux montrer que raconter.

En ligne

#37 28-03-2022 14:27:35

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

En effet, il figure aussi dans le fstab
Il a été monté 2 fois

toto@debM:~$ cat /proc/mounts |grep disk3


/dev/mapper/sdb1 /disk3 ext4 rw,relatime 0 0
/dev/mapper/sdb1 /mnt/plouf/disk3 ext4 rw,relatime 0 0



Mais du coup, ça fait quoi concrètement ? ça peut faire des erreurs ?
est-ce que je dois, lors d'une future manipulation, débrancher le disk3 ? ou tout autre support qui serait enregistré dans le fstab ?

Hors ligne

#38 28-03-2022 14:35:48

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

totoZero7 a écrit :

Mais du coup, ça fait quoi concrètement ? ça peut faire des erreurs ?


Ça monte le système de fichiers et le rend accessible à deux endroits différents. Tu as déjà fait la même chose avec /dev et /sys (bind mount) pour préparer le chroot. C'est parfaitement prévu et géré.

totoZero7 a écrit :

est-ce que je dois, lors d'une future manipulation, débrancher le disk3 ? ou tout autre support qui serait enregistré dans le fstab ?


Non. Plutôt, à ta place j'éviterais d'exécuter mount -a dans un chroot et je monterais seulement ce qui est nécessaire, ici /boot. Mais a priori tu ne devrais plus avoir besoin de refaire un chroot si le clone modifié boote bien tout seul.

Dernière modification par raleur (28-03-2022 14:36:20)


Il vaut mieux montrer que raconter.

En ligne

#39 28-03-2022 14:45:57

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

Je n'ai pas encore fait le test de démarrer le SSD2, je ferai ça plus tard.
Mais avant, j'ai 2 observations


1. Lors des modifications, il n'a pas eu de changement sur les PARTUUID
SSD1 (/boot)

sudo blkid /dev/sda1


/dev/sda1: UUID="755370b5-d296-4af0-942e-1b8e3dd51628" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="077bd2db-01"



SSD2 (/boot)

sudo blkid /dev/sdd1


/dev/sdd1: UUID="1ad1838b-a329-45f9-9be8-0610fea0e30f" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="077bd2db-01"



Question
-------------
Faut il les changer ?
Comment changer le partuuid ?




2. Pendant la modification du Contenu des volumes logiques UUID de [/root], j'ai eu une rencontre étrange
En voulant nettoyer l'uuid de root ou même en voulant le modifer directement j'obtiens ce message:

sudo tune2fs -U clear /dev/debM11SSD2/root


tune2fs 1.46.2 (28-Feb-2021)

This operation requires a freshly checked filesystem.

Please run e2fsck -f on the filesystem.



Du coup, j'exécute la commande est ça me demande si je dois optimiser ou pas

sudo e2fsck -f /dev/debM11SSD2/root


e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
Inode 1838784 extent tree (at level 1) could be narrower.  Optimize<y>? no
Inode 3146607 extent tree (at level 1) could be shorter.  Optimize<y>? no
Inode 3146609 extent tree (at level 1) could be shorter.  Optimize<y>? no
Inode 3146610 extent tree (at level 1) could be shorter.  Optimize<y>? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/debM11SSD2/root: 245253/59981824 files (0.7% non-contiguous), 64234906/239910912 blocks



J'ai mis de "no" à la demande.
J'ai refait cet exercice, un autre jour, en méttant des "yes" pour voir la difference

sudo e2fsck -f /dev/debM11SSDclo/root


e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
Inode 1838784 extent tree (at level 1) could be narrower.  Optimize<y>? yes
Inode 3146607 extent tree (at level 1) could be shorter.  Optimize<y>? yes
Inode 3146609 extent tree (at level 1) could be shorter.  Optimize<y>? yes
Inode 3146610 extent tree (at level 1) could be shorter.  Optimize<y>? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/debM11SSDclo/root: ***** FILE SYSTEM WAS MODIFIED *****
/dev/debM11SSDclo/root: 245253/59981824 files (0.7% non-contiguous), 64234902/239910912 blocks



Question: Mettre "yes" ou des "no" pour optimize, ça fait quoi au juste ? qu'est-ce que cela a modifié ?
Est-il préférable de mettre des yes ou des no ?

Hors ligne

#40 28-03-2022 15:02:58

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

totoZero7 a écrit :

Faut il les changer ?
Comment changer le partuuid ?


Primo, ce ne sont pas de vrais PARTUUID car la table de partition DOS/MBR ne supporte pas les PARTUUID (contrairement à GPT). Ce sont des PARTUUID synthétiques générés par le noyau (depuis une certaine version) à partir de l'identifiant disque du MBR et du numéro de partition.
Secundo, comme ils ne sont pas utilisés dans ton installation tu n'as pas vraiment besoin de les changer (ou plutôt l'identifiant du disque).
Pour changer l'identifiant du disque, tu peux utiliser fdisk en mode expert (x puis i). Il faudra soit entrer un nombre décimal, soit un nombre hexadécimal préfixé par 0x.

totoZero7 a écrit :

sudo e2fsck -f /dev/debM11SSDclo/root


Je ne pense pas que mettre un UUID à zéro soit une bonne idée. Un UUID est censé être unique, zéro est tout saut unique. Si tu as besoin de changer un UUID, spécifie plutôt random ou time.

totoZero7 a écrit :

Mettre "yes" ou des "no" pour optimize, ça fait quoi au juste ? qu'est-ce que cela a modifié ?


Je suppose que ça fait gagner un peu d'espace disque. Vu le taux d'occupation actuel, ce n'est pas une priorité.


Il vaut mieux montrer que raconter.

En ligne

#41 28-03-2022 18:07:56

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

Je vais mettre PARTUUID de côté donc.


Par-contre je n'ai pas compris cette histoire de zéro avec e2fsck.
Je vais détailler mon procédé et tu me dis là où c'est pas bon et où zéro intervient

4. Contenu des volumes logiques UUID de [/root] -
------------------------------------------------
# 4.1 - Affiche l'uuid actuel
sudo tune2fs -l /dev/debM11SSD2/root |grep UUID

# 4.2 - Générer aléatoirement un UUID
cat /proc/sys/kernel/random/uuid

# 4.3 - Ensuite, mettre le paramètre "clear" qui va nettoyer l'uuid
sudo tune2fs -U clear /dev/debM11SSD2/root

  4.3.1 - Ce message apparait (This operation requires a freshly checked filesystem) Faire donc la commande:
sudo e2fsck -f /dev/debM11SSD2/root

  4.3.2 - Refaire 4.3 et passer à 4.5

# 4.5 - Faire la modification (remplacer l'uuid ci dessous par le random):
sudo tune2fs -U 0c670bab-560f-4b24-8854-5f6026f8e1d7 /dev/debM11SSD2/root     //(exemple)

# 4.4 - Vérifier si le changement d'uuid à fonctionné
sudo blkid /dev/debM11SSD2/root



J'ai été contraint d'utiliser "e2fsck -f" d'après le message après avoir exécuté tune2fs -U clear.
et il me semble que ça a fait la même chose quand j'ai zapé la commande clear et suis passé direct a un UUID nouveau, sur un autre essai.

Hors ligne

#42 28-03-2022 18:40:12

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

En fait "tune2fs -U clear" ne met pas l'UUID à 0 mais l'efface, le système de fichiers n'a donc plus d'UUID. C'est inutile, on peut changer l'UUID directement avec "tune2fs -U random" sans l'effacer d'abord.

Il vaut mieux montrer que raconter.

En ligne

#43 28-03-2022 18:57:51

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

Donc le zéro c'est "tune2fs -U clear" et pas "e2fsck -f"
ok pour ça


Mais il y a toujours un message (je viens de refaire 2 tests) sans passer par clear

sudo tune2fs -U 91e30d07-3a0f-45cc-a24d-4ecce12a4928 /dev/debM11SSDclo/root

tune2fs 1.46.2 (28-Feb-2021)

This operation requires a freshly checked filesystem.

Please run e2fsck -f on the filesystem


.

sudo tune2fs -U random /dev/debM11SSDclo/root

tune2fs 1.46.2 (28-Feb-2021)

This operation requires a freshly checked filesystem.

Please run e2fsck -f on the filesystem.




Que ce soit l'une ou l'autre, j'ai quand même le message alors que je n'ai pas utilisé "clear"
Pourquoi j'ai ce message ?

Hors ligne

#44 28-03-2022 22:30:59

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

Je l'ignore. En tout cas ça n'a rien à voir avec "clear", c'est lié à tune2fs -U.

Il vaut mieux montrer que raconter.

En ligne

#45 28-03-2022 22:37:26

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

Vocabulaire
debM11SSDclo-root et debM11SSDclo-swap sont des volumes ou des partitions ?
je capte mal la différence avec les volumes chiffrés




Bon, j'ai booté dessus et ça fonctionne.
Note: lors de l'allumage, au moment de mettre la passphrase, il y avait une phrase juste au dessus (que je n'ai pas mémorisé bien sûr), qui disait attendre un UUID (celui du root)
ça n'a rien bloqué. Mais est-ce normal cet affichage alors que je n'ai pas ça avec l'autre SSD ?



Merci raleur !
3 semaines dessus avec un tuto de + de 300lignes (oué tout le monde n'est pas geek).
Je suis content, j'ai été au bout de la procédure qui m'a retourné la tête, mais c'est quand même pas rapide à faire ni à comprendre. C'est pas n'importe-qui qui peut s'y aventurer.
Cela dit, j'ai approché de plus près ce satané cryptsetup qui m'était vraiment obscur alors que je l'utilise au quotidien que ce soit avec le système ou en container à part et je peux même chrooter (Nom nouveau pour moi) le SSD cloné pour le mettre à jour depuis mon SSD1 ! ; et rien que pour ça, ça vaut la tarte que je me suis prise.
(à la base, j'avais juste changé le HDD pour un SSD et je me suis retrouvé dans une aventure...)
Je marque en résolu


Du coup, si on peut faire autrement, et surtout plus facilement, je veux bien avoir des avis comme willy64 en a fait une proposition

Dernière modification par totoZero7 (28-03-2022 22:39:16)

Hors ligne

#46 29-03-2022 14:52:10

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

totoZero7 a écrit :

debM11SSDclo-root et debM11SSDclo-swap sont des volumes ou des partitions ?
je capte mal la différence avec les volumes chiffrés


Ce sont des volumes logiques LVM, pas des partitions. Les volumes chiffrés sont aussi gérés par le "device-mapper", c'est pourquoi on les voit aussi dans /dev/mapper/, mais créés par cryptsetup et non LVM. Les deux peuvent s'utiliser comme des partitions.

totoZero7 a écrit :

Note: lors de l'allumage, au moment de mettre la passphrase, il y avait une phrase juste au dessus (que je n'ai pas mémorisé bien sûr), qui disait attendre un UUID (celui du root)


L'UUID du système de fichiers ext4 du volume logique root ou l'UUID du volume chiffré LUKS ?

totoZero7 a écrit :

Du coup, si on peut faire autrement, et surtout plus facilement, je veux bien avoir des avis


Si le but est d'obtenir une copie opérationnelle du système qui puisse cohabiter avec le système originel, j'ai déjà donné mon avis plus haut : au lieu de cloner le disque, il aurait fallu créer le partitionnement et les volumes à la main puis y copier le contenu des systèmes de fichiers. Cela aurait évité de devoir changer tous les UUID et les noms du VG et du volume chiffré, mais il aurait quand même fallu modifier les fichiers de configuration et regénérer l'initramfs et grub.cfg.

Dernière modification par raleur (29-03-2022 15:35:24)


Il vaut mieux montrer que raconter.

En ligne

#47 29-03-2022 15:05:59

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

erreur de lecture.
En effet c'est l'UUID du volume chiffré LUKS et non le root qui s'affiche

cryptsetup: waiting for encrypted source device UUID=4b40da24-1506-4705-80b8-66d072b9c9ad

Hors ligne

#48 29-03-2022 15:35:55

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

Donc ça me paraît un peu normal.

Il vaut mieux montrer que raconter.

En ligne

#49 29-03-2022 15:44:14

totoZero7
Membre
Distrib. : Debian 11 bullseye
Noyau : 5.10.0-19-amd64
(G)UI : Mate 1.24.1
Inscription : 05-07-2020

Re : [résolu] cloner un SSD chiffré

raleur a écrit :

il aurait fallu créer le partitionnement et les volumes à la main puis y copier le contenu des systèmes de fichiers.

ça sera le sujet de mon prochain post XD car je plane déjà à installer Debian avec l'assistant, alors en manuel... il va me falloir obligatoirement de l'aide.


L'idée actuelle est de pouvoir faire un rsync (manuellement) de SSD1 vers SSD2 sur des sections choisies pour que le système du SSD2 soit le plus à jour possible (1 fois tous les 3 mois c'est bien, vu que mes dossiers perso sont, eux, sauvegardés en plus sur un autre support) en prenant les changement de configurations de logiciels/Bureau/VM qui se passe dans le temps et aussi les dossiers perso qui grossissent au fur à mesure.
Je ne sais pas si mon idée est correct, mais c'est ainsi que je vois la chose et qui me parait assez simple à faire tout en maîtrisant ce que je fais.

La question est: est-ce que c'est jouable ? ou est-ce farfelu ?
car comme les UUID et les NOMS de VG sont différents, je ne peux pas faire une syncho complète ! Peut-être qu'il y a d'autres éléments à ne pas inclure.

Admettons que cela soit jouable, quels seraient les dossiers à ne surtout pas transférer pour ne pas péter le système bis ?

Hors ligne

#50 31-03-2022 23:56:48

raleur
Membre
Inscription : 03-10-2014

Re : [résolu] cloner un SSD chiffré

Pour que je sois sûr de bien comprendre, tu voudrais synchroniser seulement les données et configurations des utilisateurs ou bien aussi le système et les paquets au lieu de le mettre à jour normalement avec apt en chrootant ou en bootant sur le SSD2 ?

Il vaut mieux montrer que raconter.

En ligne

Pied de page des forums