Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Comme il y a différents formats, je ne sais pas ce qu'il faut mettre après partclone.[]. J'ai recopié la commande, vue, sur ubuntu-fr.org
https://doc.ubuntu-fr.org/partclone
J'ai modifié le -b en -c (je ne sais pas pourquoi ils ont mis -b) sachant que pour cloner c'est -c
par ailleurs, je n'ai vu nulle part d'explication au sujet de partclone.[extfs] pour cloner, sauf pour restaurer.
Dernière modification par totoZero7 (28-03-2022 21:36:20)
Hors ligne
1 - Puis-je cloner entièrement, d'un seul coup, tout le système chiffré avec ces différentes partitions dedans, avec une commande du terminal comme "partclone" ?
Partclone n'apporte rien par rapport à dd si le disque est entièrement chiffré.
Est-ce que la marque du SSD joue sur quoi que ce soit dans la démarche de cloner un disque ?
Seulement si on utilise les outils des fabricants.
dd copie des blocs inutilisés
Ouais, mais comme le disque est chiffré on ne peut pas savoir quels blocs sont utilisés.
est-ce que cette commande est correcte pour cloner le SSD1 vers SSD2 ?
Non, évidemment. Le disque ne contient pas un système de fichiers ext* mais une table de partition.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
remarque: Je ne sais pas quoi mettre en taille à "bs=XXXMo", je ne comprends pas cette partie avec les blocs
Est-ce que les options mises sont correct (conv=notrunc,noerror status=progress && sync) ? toujours en rapport avec les blocs que je ne comprends pas.
2. Quelle serait la bonne commande pour cloner, un disque chiffré, avec partclone ?
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Démarrage à une vitesse de 513 MB/s. Puis c'est descendu petit à petit
460 MB/s à 50GB
440 MB/s à 80GB
430 MB/s à 97GB
420 MB/s à 130GB
410 MB/s à 230GB
Puis ça a commencé à remonter vers 350/380GB
420 MB/s à 429GB
430 MB/s à 490GB
440 MB/s à 571GB
450 MB/s à 673GB
460 MB/s à 808GB
Ensuite J'ai booté sur le SSD2 pour vérifier si j'arrivais à démarrer sur le clone. Et ça a fonctionné. Parfait.
Puis, j'ai rebooté sur le SSD1... et je ne m'en suis pas rendu compte tout de suite, car ils sont identiques, mais en bootant sur le SSD1 ça me montait sur le SSD2. Ahah !
Je le dis autrement pour que cela soit plus clair:
J'ai booté sur le SSD1 (Samsung) lors de la sélection dans le bios, et c'est le SSD2 (Crucial) qui s'est mis en route. Je n'ai pas compris...
Je sais qu'il y a une histoire de nom de volume à changer, ce que je m’apprêtais à faire, mais j'ai été surpris de ce qu'il se passait.
J'ai donc dù le débrancher pour pouvoir booter sur mon SSD1 !
Comment cela se fait que c'est le SSD2 qui démarre alors que c'est le SSD1 qui a été choisie ?
Est-ce qu'il y a un changement à faire en plus, du nom des volumes ?
Dernière modification par totoZero7 (09-03-2022 20:32:44)
Hors ligne
Cela a mis 35minutes pour cloner le disque de 1To. qui était seulement utilisé sur (230Go... ). Je n'ai pas compris pourquoi il a écrit sur 1To.
Soupir...
en bootant sur le SSD1 ça me montait sur le SSD2.
Prévisible. Ne jamais brancher des clones simultanément sur la même machine.
Comment cela se fait que c'est le SSD2 qui démarre alors que c'est le SSD1 qui a été choisie ?
Ce n'est pas le cas. Comme tu l'écris justement un peu avant; c'est le SSD 2 qui est monté, pas qui démarre.
Le montage est basé sur les UUID, et les deux disques ont les mêmes UUID, donc GRUB puis l'initramfs peuvent monter n'importe lequel des deux disques quel que soit le disque de boot.
Si tu changes les UUID, ce ne seront plus des clones. Il faut les changer partout, dans les partitions, dans les fichiers de configuration (fstab, crypttab, grub.cfg) et dans l'initramfs.
Il vaut mieux montrer que raconter.
Hors ligne
totoZero7 a écrit :
Cela a mis 35minutes pour cloner le disque de 1To. qui était seulement utilisé sur (230Go... ). Je n'ai pas compris pourquoi il a écrit sur 1To.
Soupir...
Pourquoi soupir ? j'ai dit une betise ?
Avant d'avoir ton retour, j'avais essayé d'obtenir l'UUID (groupe de volume) de SSD2 pour modifier les noms de volumes (comme sur le tuto de ce post de "Comment monter un système chiffré") . Mais il avait les mêmes UUID (de disque ?) que SSD1.
Et en effet, tout est identique !
Du coup, ça change mes plans.
Car je pensais, en effet, créer un clone pour pouvoir, en cas de problème faire une permutation rapide de système, mais aussi, je pensais pouvoir y accéder avec l'autre système (le 1er), que ce soit pour faire des modif direct dedans ou pour apporter du contenu.
Donc, il faut changer tous les identifiants de SSD2. Et là, il y en des nouveaux que je découvre (identifiants).
Voici donc la nouvelle question:
Comment procède-t'on, dans l'ordre, pour modifier les identifiants de ce SSD2 ? Et est-ce que je peux le faire de l'ancien système (SSD1) ou ai-je besoin d'un Live ?
ps: à chaque fois que je poste une question, je me dis que ça va aller vite parce-que yaka appuyer sur un bouton c'est facile. Et puis en fait, à chaque fois ça rebondit et je me prends dans un engrenage de geekerie qui me fait halluciner. Sans aide, ça serait juste impossible de faire la moindre manœuvre parce-ce que c'est quand même foutrement lourd en savoir pour faire tout ça. Juste pour dire, merci à ce forum et tout ceux qui aident.
Hors ligne
Pourquoi soupir ? j'ai dit une betise ?
Je pensais que ce point, déjà expliqué dans les messages précédents, était acquis. dd ne sait pas quels blocs sont utilisées ou inutilisés et copie tous les blocs. C'est le prix à payer pour le chiffrement.
Comment procède-t'on, dans l'ordre, pour modifier les identifiants de ce SSD2 ? Et est-ce que je peux le faire de l'ancien système (SSD1) ou ai-je besoin d'un Live ?
Il y a plusieurs couches d'UUID/labels/identifiants empilées dans ta configuration :
- les PARTUUID et les PARTLABEL de la table de partition ; les doublons ne sont pas gênants si on ne les utilise pas
- l'UUID et le LABEL du contenu de la partition /boot, référencé dans grub.cfg et /etc/fstab, peuvent être hangés avec tune2fs et e2label (pour ext2/3/4)
- l'UUID LUKS de la partition chiffrée, référencé dans /etc/crypttab et l'initramfs, peut être changé avec cryptsetup
- l'UUID du volume physique LVM, peut être changé avec pvchange
- l'UUID du groupe de volume LVM, peut être changé avec vgchange
- les UUID des volumes logiques LVM, peuvent être changés avec lvchange
- les UUID et LABEL du contenu des volumes logiques, peuvent être changés avec tune2fs et e2label (pour ext2/3/4), swaplabel (pour le swap) ; mais ils ne sont normalement pas utilisés donc les doublons ne sont pas trop gênants
A mon avis la plus grosse difficulté, ce sont les UUID LVM des PV et du VG. Je n'ai jamais essayé mais je ne suis pas sûr qu'on puisse les modifier dans le cas où il y a des doublons, donc il vaudrait mieux le faire avec le seul SSD à modifier présent (ou du moins déchiffré). Pas forcément besoin de système live pour ça.
Si tu avais dit dès le début que tu voulais que les deux SSD puissent être présents en même temps, j'aurais suggéré une autre méthode consistant à dupliquer l'installation plutôt qu'à la cloner. Du coup tu aurais pu utiliser partclone sur chaque volume logique pour ne copier que les blocs utilisés.
Dernière modification par raleur (20-03-2022 10:55:14)
Il vaut mieux montrer que raconter.
Hors ligne
Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent
Hors ligne
Dernière modification par raleur (10-03-2022 11:46:35)
Il vaut mieux montrer que raconter.
Hors ligne
Je pensais que ce point, déjà expliqué dans les messages précédents, était acquis. dd ne sait pas quels blocs sont utilisées ou inutilisés et copie tous les blocs. C'est le prix à payer pour le chiffrement.
En fait c'est acquis dans la mesure où je comprends ce qu'est un bloc or cette notion de bloc n'est pas comprise. Combien il y a de bloc dans un SSD, il y a des sous-bloc ? un fichier va s'écrire sur un bloc ou sur des blocs ? Comment se comporte un fichier en fait. Est-ce que le SSD, bourré de technologie, capte des "choses" et optimise des actions, dans le but de faire durer plus longtemps son utilisation. Sans connaitre ce qu'est un SSD, ce qu'il fait, ce qu'un système est... cela me plonge dans le flou.
Et c'est pareil pour le chiffrement, je ne sais pas si LVM chiffre le disque entier, ou si c'est une partie à la fois, qui grossit.
Avec ce qu'il sait passé, j'en déduis que c'est tout le disque qui est chiffré ; qui inclus du coup tous les blocs. Cela dit, je ne comprends toujours pas la notion de bloc (si par exemple le disque n'était pas chiffré)
Sinon, il y a un sacré chantier en perspective pour effectuer les changements des differents UUID et LABEL.
Je vais y aller tout doux hein. #TotoPartDeZéro.
- les PARTUUID et les PARTLABEL de la table de partition ; les doublons ne sont pas gênants si on ne les utilise pas.
Je commence par le 1er.
"...si on ne les utilise pas" j'avoue que je ne sais pas trop si j'en utilise au quotidien XD
Aller je formule la question:
- Dans quelle circonstance aurais-je besoin d'utiliser ces deux éléments ? ou dans quelle circonstance elles pourraient être gênante en cas de doublons ?
- Comment peut-on les reconnaître ? les distinguer ?
Dernière modification par totoZero7 (10-03-2022 19:27:06)
Hors ligne
un fichier va s'écrire sur un bloc ou sur des blocs ? Comment se comporte un fichier en fait
Aucune importance. Tout ce qu'il faut savoir est que certains blocs sont utilisés et d'autres pas.
Est-ce que le SSD, bourré de technologie, capte des "choses" et optimise des actions, dans le but de faire durer plus longtemps son utilisation.
Oui, mais ce n'est pas ça qui détermine ni permet de savoir si un bloc est utilisé ou pas. C'est plutôt dans l'autre sens : le système dit au SSD quels blocs sont utilisés (implicitement en écrivant dedans), ou non utilisés (avec TRIM si activé), mais il n'y a à ma connaissance pas moyen de demander au SSD quels blocs sont utilisés ou pas.
je ne sais pas si LVM chiffre le disque entier, ou si c'est une partie à la fois, qui grossit.
LVM ne s'occupe pas du chiffrement. C'est la couche en-dessous (dm-crypt) qui s'en occupe mais qui ne marque pas les blocs comme occupés ou pas. Même LVM ne sait pas si un bloc est réellement occupé. Seul le système de fichiers dans un volume logique le sait. Donc si tu fais une copie à un niveau plus bas que le système de fichier/volume logique, tu ne peux pas savoir si un bloc est utilisé ou pas.
Et non, LVM ne grossit pas. Les blocs sont alloués à un volume logique en fonction de sa taille et le système de fichiers se sert dedans.
Tout le disque n'est pas chiffré : le secteur d'amorçage, la table de partition et la partition /boot ne le sont pas. Mais la partition qui contient LVM l'est.
j'avoue que je ne sais pas trop si j'en utilise au quotidien
Regarde dans /etc/fstab et /etc/crypttab.
Il vaut mieux montrer que raconter.
Hors ligne
Étape 1 - l'UUID et le LABEL du contenu de la partition [/boot] - ok
Étape 2 - l'UUID [LUKS] de la partition chiffrée - ok
Étape 3 - l'UUID du [volume physique LVM] - là ça coince, je ne sais pas quoi faire.
(j'ai déchiffré le volume)
sdd1 et sdd5 ont un nouveau UUID sur ce tableau. Je dois m'attaquer aux autres mais c'est là que je rencontre des problèmes.
Étape 4 - l'UUID du [groupe de volume LVM] - ça coince comme l'étape 3 et je ne sais pas quel chemin lui donner
Étape 5 - les UUID des [volumes logiques LVM] - Problèmes. l'option --uuid n'est pas reconnue. Pas sûr du chemin à donner
(il y a le swap_1 à faire aussi, que je n'ai pas testé vu que ça coince déjà ici )
Étape 06 A - changement des uuid du [contenu des volumes logiques avec tune2fs pour root] - Ok
La ligne modifiée est "debM11SSD2-root ext4 1.0 0c670bab-560f-4b24-8854-5f6026f8e1d7"
Étape 06 B - changement des uuid du [contenu des volumes logiques avec tune2fs pour swap_1] - Problème ici - "Bad magic number"
J'ai testé la commande e2fsck pour voir ce qu'elle dit mais ça n'aide pas.
En voulant éteindre le PC, je n'ai pas réussi à verrouillé le chiffrement de ce SSD2. ça me disait que c'était occupé. J'ai éteint sans le verrouiller.
J'ai bien cherché et là je suis à sec pour me sortir de tout ça.
help
Hors ligne
Volume group containing /dev/mapper/luks-e6858ed2-17ee-41fa-b3bb-7cc7438221cf has active logical volume
Volume group has active logical volumes
Visiblement on ne peut pas changer l'UUID d'un PV ou d'un LV si des LV sont actifs. Ils faut donc les désactiver avec
Étape 5 - les UUID des [volumes logiques LVM] - Problèmes. l'option --uuid n'est pas reconnue.
En effet. Pas besoin de changer les UUID des LV, ils sont internes au VG.
Étape 06 B - changement des uuid du [contenu des volumes logiques avec tune2fs pour swap_1] - Problème ici - "Bad magic number"
tune2fs ne s'applique qu'aux systèmes de fichiers ext2/3/4. L'UUID du swap doit être changé avec swaplabel.
(à faire avant de désactiver les volumes logiques pour changer l'UUID du PV et du VG)
En voulant éteindre le PC, je n'ai pas réussi à verrouillé le chiffrement de ce SSD2. ça me disait que c'était occupé.
Tu veux dire fermer le volume chiffré ? En effet il faut désactiver les volumes logiques LVM avant (voir plus haut).
Pour que ce SSD soit utilisable en même temps que l'autre, il faudra aussi changer le nom du VG avec vgrename.
Pour que le système de ce SSD soit fonctionnel, il faudra en plus
- modifier l'UUID LUKS dans /etc/crypttab
- modifier l'UUID de la partition /boot et le nom du VG dans /etc/fstab.
- reconstruire l'initramfs avec update-initramfs en chroot (note : il se peut qu'il soit nécessaire que le volume chiffré LUKS soit ouvert sous le même nom que dans /crypttab, à faire avec cryptsetup)
- regénérer grub.cfg avec update-grub en chroot pour prendre en compte les nouveaux UUID de /boot et nom du VG
Il ne devrait pas être nécessaire de réinstaller GRUB, dans cette configuration la partition /boot est identifiée dans la core image par son numéro de partition et non par son UUID.
Il vaut mieux montrer que raconter.
Hors ligne
- reconstruire l'initramfs avec update-initramfs en chroot (note : il se peut qu'il soit nécessaire que le volume chiffré LUKS soit ouvert sous le même nom que dans /crypttab, à faire avec cryptsetup)
C'est quoi chroot ? je m'en sers comment ? (j'ai utilisé root plus bas)
- reconstruire l'initramfs avec update-initramfs en chroot (note : il se peut qu'il soit nécessaire que le volume chiffré LUKS soit ouvert sous le même nom que dans /crypttab, à faire avec cryptsetup)
Comment j'utilise cryptsetup dans cette situation ?
De quel "nom" parle-t'on ?
il faut qu'il soit ouvert ou non ouvert ? je n'ai pas compris le sens de la phrase
J'ai cette ligne dans /etc/crypttab
J'ai mis cette commande sans savoir si c'est du chroot et j'ai effectivement un message qui parle de cryptsetup mais je ne sais pas quoi faire
- regénérer grub.cfg avec update-grub en chroot pour prendre en compte les nouveaux UUID de /boot et nom du VG
J'ai trouvé ces 2 commandes. Sont-elles bonnes et suffisent pour le régénérer ? (pas encore essayé car j'attends que l'action d'avant soit terminée)
Hors ligne
C'est quoi chroot ? je m'en sers comment ?
man chroot
https://debian-facile.org/doc:systeme:chroot
(j'ai utilisé root plus bas)
C'est-à-dire ? Si tu veux dire que tu as exécuté les commandes en root, ça ne suffit pas.
Comment j'utilise cryptsetup dans cette situation ?
man cryptsetup
De quel "nom" parle-t'on ?
Comme j'ai dit, de celui qui est dans /etc/crypttab : sda5_crypt (même si la partition chiffrée ne s'appelle plus sda5). Ça peut être une bonne idée de changer ce nom aussi, mais ce n'est pas indispensable.
J'ai trouvé ces 2 commandes.
Qu'est-ce qui n'est pas clair dans "regénérer grub.cfg avec update-grub" ?
Il vaut mieux montrer que raconter.
Hors ligne
Si je fais la commande du tuto, j'obtiens une erreur
Si je déverrouile le volume, ça donne ceci
Si je refais la commande pour monter la partition, j’obtiens encore l'erreur
Si j’expérimente avec debM11SSDclo-root, ça ne marche pas non plus
Je ne sais pas où regarder pour expliquer ce qui ne va pas. Je suis perdu.
Comment on fait pour être chroot avec ce disque chiffré ?
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
J'en déduis qu'il faut un périphérique. Sauf que quand j'ouvre tout, je n'ai aucun sda5_crypt qui apparaît.
Comment on modifie le nom ?
Hors ligne
Dernière modification par raleur (25-03-2022 20:05:08)
Il vaut mieux montrer que raconter.
Hors ligne
Comment désactiver spécifiquement le SSD2 sans faire de mal au SSD1 ?
Autre chose
Je n'arrive pas à débrancher proprement le SSD2 connecté en USB une fois que tout est démonté
je fais cela avec l'utilitaire 'Disques' (du paquet gnome-disk-utility)
Quand je clique sur "éteindre le disque"; ça s'éteint mais ça se rallume instantanément.
Comment faire, par le terminal, pour éteindre et éjecter le disque sans problème ?
Hors ligne
Comment désactiver spécifiquement le SSD2 sans faire de mal au SSD1 ?
Il faut spécifier le nom du VG dans la commande vgchange. Mais a priori ce n'est pas indispensable, la commande a désactivé les volumes qui pouvaient l'être car non utilisés.
Quand le volume chiffré est ouvert avec le bon nom, les volumes logiques activés, le volume logique root monté sur /X, le fichier /X/etc/crypttab mis à jour avec le nom du volume chiffré, tu peux lancer le chroot sur /X (avec /dev /proc et /sys, cf. wiki) et exécuter update-initramfs -u et update-grub.
Comment faire, par le terminal, pour éteindre et éjecter le disque sans problème ?
Démonter les systèmes de fichiers avec umount.
Désactiver les swaps avec swapoff.
Désactiver le groupe de volumes LVM avec vgchange
Fermer le volume chiffré avec cryptsetup close.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne