Debian-facile

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

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

#1 01-01-2019 00:41:01

statis
Membre
Distrib. : Debian-9 64 bits stretch
Noyau : Linux deb64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1
(G)UI : Mate 1.16.2
Inscription : 19-12-2018

Disque Debian 9 cloné pas lisible par son original [résolu]

Salut tout le monde,

J'ai cloné mon Debian 9 avec clonezilla.
Aucune erreur n'a été remontée lors de l'opération.
J'ai testé le clone sur un autre PC sur lequel il n'était pas nécessaire de tout démonter pour faire un essai le clone fonctionne bien.
Si je met le clone sur mon dock USB, Gparted le voit mais il n'apparaît pas dans l'explorateur de fichier.
Le dock est bien fonctionnel et avec j'arrive à lire aussi bien des disques linux que du windows (si ce dernier a été installé en mode Bios, pour ceux installer en UEFI c'est une autre histoire).
Le clone a une partition principale ext4 et une étendue en swap comme sa source en vision sur Gparted donc rien de différent.

La commande

fdisk -l



le fait bien apparaître en sdj en copie conforme de sda


[Disque /dev/sda : 149,1 GiB, 160041885696 octets, 312581808 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xccc234f9

Périphérique Amorçage     Début       Fin  Secteurs Taille Id Type
/dev/sda1    *             2048 269514751 269512704 128,5G 83 Linux
/dev/sda2             269514752 312580095  43065344  20,5G  5 Étendue
/dev/sda5             269516800 312580095  43063296  20,5G 82 partition d'échang


Disque /dev/sdj : 149,1 GiB, 160041885696 octets, 312581808 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xccc234f9

Périphérique Amorçage     Début       Fin  Secteurs Taille Id Type
/dev/sdj1    *             2048 269514751 269512704 128,5G 83 Linux
/dev/sdj2             269514752 312580095  43065344  20,5G  5 Étendue
/dev/sdj5             269516800 312580095  43063296  20,5G 82 partition d'échange
 



Dans le poste de travail l’icône du disque apparaît bien mais en double-cliquant dessus un message d'erreur  "ne peut être monté apparaît".
En cliquant du droit dessus pour accéder à propriétés/permissions il y a une note "les permissions ne peuvent être déterminées.

Plus ennuyeux en raccordant le dock sur mon PC Fedora 29, le clone est visible dans l'explorateur de fichier ce qui indiquerait un problème avec mon Debian 9 ou alors un clone ne peut être lu par sa source génétique...
Cela ne me plaît pas que Fedora 29 arrive à faire des choses alors que mon préféré Debian 9 échoue (c'est le 2ème truc avec le soft Kisslicer qui est en fil non résolu) :'(
Please sauvez Debian 9 wink

Dernière modification par statis (02-01-2019 11:44:38)


J'ai un QI de surimi et je peux faire de grosses bêtises...

Peux-tu combattre ta propre nature ? Si oui, cela fait partie de ta nature… Mépriser ceux qui n’ont pas ta chance, Est une grave insulte à la providence…
Julius Korlang

Hors ligne

#2 01-01-2019 00:52:40

MicP
Membre
Inscription : 29-02-2016

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

Bonjour

Si le disque avec ses partitions et systèmes de fichiers ont été clonés,
les systèmes de fichiers clonés ont les mêmes UUID et LABEL que leur originaux,
ce qui doit sans doute empêcher le montage d'un système de fichiers clone
dans le système de fichier original ayant servit à créer ce clone.

Dernière modification par MicP (01-01-2019 00:54:28)

Hors ligne

#3 01-01-2019 01:30:44

statis
Membre
Distrib. : Debian-9 64 bits stretch
Noyau : Linux deb64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1
(G)UI : Mate 1.16.2
Inscription : 19-12-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

Merci MicP

Bonne année à toi

J'ai un QI de surimi et je peux faire de grosses bêtises...

Peux-tu combattre ta propre nature ? Si oui, cela fait partie de ta nature… Mépriser ceux qui n’ont pas ta chance, Est une grave insulte à la providence…
Julius Korlang

Hors ligne

#4 01-01-2019 10:44:07

raleur
Membre
Inscription : 03-10-2014

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

Tu peux vérifier les UUID et les LABELs des partitions avec la commande "blkid".

Un UUID ou un LABEL est supposé être unique (après tout le second U dans UUID est pour "unique"). Un disque et son clone exact ne sont donc pas destinés à être utilisés dans la même machine. Les doublons n'empêchent pas le montage à strictement parler (in fine c'est le noyau qui monte, et il se moque des UUID et LABELs), mais ils peuvent provoquer divers dysfonctionnements, et non des moindres comme le montage d'une partition du clone si celui-ci est présent au démarrage, au lieu de celle de l'original. Je n'ai pas d'expérience avec la façon dont cela impacte les gestionnaires de fichiers, mais la norme semble être de créer un point de montage nommé d'après le LABEL ou à défaut l'UUID du volume.

Tu peux tester le montage manuel en ligne de commande root :

mount /dev/sdj1 /mnt


Si cela réussit, avant de déconnecter le disque il faudra démonter la partition avant :

umount /mnt



Il est possible de modifier les UUID et LABEL des partitions d'un disque, mais s'il contient un système bootable il faut aussi modifier toutes les références à ces UUID et LABEL, notamment dans /etc/fstab, /etc/initramfs-tools/conf.d/resume, l'initramfs créé par update-initramfs -u et /boot/grub/grub.cfg créé par update-grub.

En ligne

#5 01-01-2019 12:53:42

empanada
Membre
Distrib. : Debian 9 (Stretch)
Noyau : 4.9.0-7-amd64
(G)UI : LXDE
Inscription : 19-09-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

raleur a écrit :

Un UUID ou un LABEL est supposé être unique (après tout le second U dans UUID est pour "unique"). Un disque et son clone exact ne sont donc pas destinés à être utilisés dans la même machine.


Bien pointé. Ce n'est pas un usage , disons, "normale". Cependant est possible comme tu dit dessous. Moi je le fait souvent, mais c'est por des raisons très spécifiques.

raleur a écrit :

Les doublons n'empêchent pas le montage à strictement parler (in fine c'est le noyau qui monte, et il se moque des UUID et LABELs), mais ils peuvent provoquer divers dysfonctionnements, et non des moindres comme le montage d'une partition du clone si celui-ci est présent au démarrage, au lieu de celle de l'original. Je n'ai pas d'expérience avec la façon dont cela impacte les gestionnaires de fichiers

Moi oui, j'ai experimenté un peu , et oui, il peut avoir des mauvaises surprises, surtout si les deux disques(et/ou partitions clonés) sont presentes au moment d'amorçage: par exemple, il peut démarrer une partition racine pas désirée conséquence des UUID's clonés, dont le GRUB peut "confondre", et même parfois démarrer avec une, et des autres avec l'autre. On peut contourner en décommentant la ligne #GRUB_DISABLE_LINUX_UUID=true sur /etc/default/grub (et évidemment faire après un update-grub pour actualiser) pour indiquer GRUB d'utiliser les chemins classiques /dev/sda1 , etc...mais par défaut c'est desactivé et je n'aime pas trop (pour bouger les disques comme je fait très souvent tu doit avoir soucis avec sur quel port on le branche, et même quelques firmware ou BIOS parfois changent l'ordre du disque, donc pour moi au moins beaucoup plus confiable utiliser les UUID's)
En résumé , comme norme genérale , JAMAIS BRANCHER DEUX CLONES SOUS LA MÊME MACHINE AVANT L'AMORÇAGE.

Si on le branche après l'amorçage, comme il parait le cas , parmi une dock station, pas grave pour les systèmes...mais oui, on peut avoir des ennuies pour les monter, surtout si ces UUID's sont sur /etc/fstab: il ne va pas le monter automatiquement puisque ils sont surement déjà montés (surtout dans le cas de statis: partition racine et swap). La même raison explique pourquoi le disque c'est montée automatiquement sur un autre système quelconque (Fedora dans ce cas): ces UUID's n'apparaissent pas dans son fstab, et il peut les gérer sans se tromper.
S'il ne sont pas sur /etc/fstab, le système va bien les gérer, mais attention, si par exemple on a deux partitions clonés, donc avec le même UUID et la même  étiquette (LABEL), un d'eux va être monté sous /media/nom_utilisateur/LABEL et l'autre sous /media/nom_utilisateur/LABEL1 (et s'il aurait des autres clones presentes, sur /media/nom_utilisateur/LABEL2 , etc).

statis, si on revient sur ton cas concret, tu peux monter cette partition EXT4 (je suppose que le swap tu n'a aucun intérét) comme raleur a indiqué, "à la main" et en utilisant les chemins classiques /dev/sd[a-z][0-99]:

raleur a écrit :

mais la norme semble être de créer un point de montage nommé d'après le LABEL ou à défaut l'UUID du volume.

Tu peux tester le montage manuel en ligne de commande root :

mount /dev/sdj1 /mnt


Si cela réussit, avant de déconnecter le disque il faudra démonter la partition avant :

umount /mnt


Je ferais avant le montage, comme aussi indiqué par raleur, un

blkid

pour voir tous les disques et partitions reconnus et m'assurer de quels sont les noms des tous les partitions
et aussi un

cat /etc/mtab |grep " / "

pour voir quelle est la partition monté comme root (et ça m'assure que ce disque ce "l'originale").


raleur a écrit :

Il est possible de modifier les UUID et LABEL des partitions d'un disque, mais s'il contient un système bootable il faut aussi modifier toutes les références à ces UUID et LABEL, notamment dans /etc/fstab, /etc/initramfs-tools/conf.d/resume, l'initramfs créé par update-initramfs -u et /boot/grub/grub.cfg créé par update-grub.

.
Oui, je le fait presque toujours après une restauration (puisque souvent je branche plusieurs clones sur la même machine), pour éviter ce genre des problèmes. Les pas que je suis sont (dans l'exemple, la partition racine cloné c'est /dev/sdb1). J'ai un script pour tout ça me je nl'ai pas sous la main dans ce moment-là :

fsck.ext4 /dev/sdb1 #tune2fs ait bésoin d'un système propre
tune2fs -U random /dev/sdb1 #Changer l'UUID. tune2fs crée un aléatoire avec "-U random" . Répéter avec le swap si nécessaire.
mkdir /mnt/sdb1
mount /dev/sdb1 /mnt/sdb1
mount --bind /dev /mnt/sdb1/dev
mount --bind /proc /mnt/sdb1/proc
mount --bind /sys /mnt/sdb1/sys
chroot /mnt/sdb1
blkid #pour voir le  nouveau UUID
#changer dans /etc/fstab l'ancien UUID de la partition racine par le nouveau UUID (et du swap s'il y en a)
#changer le nom de hôte sur /etc/etc/hostname
update-grub
grub-install /dev/sdb
exit
umount /mnt/sdb1/dev /mnt/sdb1/proc /mnt/sdb1/sys
umount /mnt/sdb1
 



Salut

Dernière modification par empanada (01-01-2019 12:56:15)


"blues are the roots and the other musics are the fruits" . Willie Dixon

Hors ligne

#6 01-01-2019 14:38:27

statis
Membre
Distrib. : Debian-9 64 bits stretch
Noyau : Linux deb64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1
(G)UI : Mate 1.16.2
Inscription : 19-12-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

Merci raleur,

Le clonage de l'UUID est effectivement fait

blkid



/dev/sda1: UUID="3766f605-232e-479b-a6d1-fc7abd54dbda" TYPE="ext4" PARTUUID="ccc234f9-01"
/dev/sdj1: UUID="3766f605-232e-479b-a6d1-fc7abd54dbda" TYPE="ext4" PARTUUID="ccc234f9-01"
 



La commande

mount /dev/sdj1 /mnt


ne se met pas en erreur mais ne fait rien, ce qui paraît logique vu que la partition a aussi le même "UUID".

Je retiens la possibilité de modifier les UUID/LABEL.
Dans la configuration actuelle de mon PC Debian 9 si l'OS devient inutilisable je n'aurais pas de difficultés à récupérer les données puisque je les stocke sur un autre disque interne.
Pour un PC monodisque et seule machine, cette modification du clone paraît très intéressante pour récupérer des données (si elles sont toujours accessibles) car même un live USB serait confronté au doublon d'UUID...
Mais je n'ai pas compris le rôle des commandes

update-initramfs -u

et 

update-grub



Bonne année à toi raleur


J'ai un QI de surimi et je peux faire de grosses bêtises...

Peux-tu combattre ta propre nature ? Si oui, cela fait partie de ta nature… Mépriser ceux qui n’ont pas ta chance, Est une grave insulte à la providence…
Julius Korlang

Hors ligne

#7 01-01-2019 15:29:35

empanada
Membre
Distrib. : Debian 9 (Stretch)
Noyau : 4.9.0-7-amd64
(G)UI : LXDE
Inscription : 19-09-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

statis a écrit :

Pour un PC monodisque et seule machine, cette modification du clone paraît très intéressante pour récupérer des données (si elles sont toujours accessibles) car même un live USB serait confronté au doublon d'UUID...

Un live ne devrait pas avoir problème avec les UUID et/ou les LABEL doublés. C'est expliqué dans le message antérieur.

statis a écrit :

Mais je n'ai pas compris le rôle des commandes

update-initramfs -u

et 

update-grub

.

Conserver le disque amorçable. So tu changes l'UUID de la partition racine et n'informe pas GRUB, il va chercher le vieux UUID...et il ne va pas recontrer, donc ÉCHEC. Il faut aussi actualiser le /etc/fstab. Et non seulement avec la racine mais aussi avec le swap. C'est tout indiqué dans le message antérieur aussi.

Salut

Dernière modification par empanada (01-01-2019 15:30:55)


"blues are the roots and the other musics are the fruits" . Willie Dixon

Hors ligne

#8 01-01-2019 16:32:26

statis
Membre
Distrib. : Debian-9 64 bits stretch
Noyau : Linux deb64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1
(G)UI : Mate 1.16.2
Inscription : 19-12-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

merci empanada,

Je n'ai pas vu ton message, il a du arriver en même temps que je tapais la réponse à raleur...

Comme déjà dit sur mon PC Debian 9

mount /dev/sdj1 /mnt


ne permet pas d’accéder au disque

Si j'ai bien compris, je met en place le clone en lieu et place de l'original sur le PC.
Je crée un UUID pour les partition ext4/swap avec la commande (trouvée sur https://doc.ubuntu-fr.org/uuid_et_label)

uuidgen -r # Pour une génération aléatoire
uuidgen -t # Pour une génération basée sur un peu d'aléatoire et surtout la date et l'heure.


Je modifie

/etc/fstab



/etc/initramfs-tools/conf.d/resume



/boot/grub/grub.cfg



Avec les nouveaux UUID

met à jour

update-initramfs -u



update-grub



Je change les labels avec Gparted.

Et cela devrait être bon...

Bonne année à toi empanada

Dernière modification par statis (01-01-2019 16:32:54)


J'ai un QI de surimi et je peux faire de grosses bêtises...

Peux-tu combattre ta propre nature ? Si oui, cela fait partie de ta nature… Mépriser ceux qui n’ont pas ta chance, Est une grave insulte à la providence…
Julius Korlang

Hors ligne

#9 01-01-2019 17:00:36

empanada
Membre
Distrib. : Debian 9 (Stretch)
Noyau : 4.9.0-7-amd64
(G)UI : LXDE
Inscription : 19-09-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

statis a écrit :

Comme déjà dit sur mon PC Debian 9

mount /dev/sdj1 /mnt


ne permet pas d’accéder au disque


T'es sûr? Plus haut t'as dit que

statis a écrit :

La commande
mount /dev/sdj1 /mnt
ne se met pas en erreur mais ne fait rien, ce qui paraît logique vu que la partition a aussi le même "UUID"

Pas de erreur, donc... T'as regardé sur mnt? autant avec ton explorateur des fichiers graphique que par ligne de commandes, par exemple avec

ls /mnt



statis a écrit :

Si j'ai bien compris, je met en place le clone en lieu et place de l'original sur le PC.
Je crée un UUID pour les partition ext4/swap avec la commande (trouvée sur https://doc.ubuntu-fr.org/uuid_et_label)

uuidgen -r # Pour une génération aléatoire
uuidgen -t # Pour une génération basée sur un peu d'aléatoire et surtout la date et l'heure.

uuidgen ce n'est pas nécessaire, et en plus il faut l'installer. Il ne fait que créer un UUID aléatoire, travail que peut faire tune2fs avec la commande que j'ai mis dans le message antérieur.

statis a écrit :

Je modifie

/etc/fstab

/etc/initramfs-tools/conf.d/resume

/boot/grub/grub.cfg

Avec les nouveaux UUID
met à jour

update-initramfs -u

update-grub

Oui...mais ça doit être fait dès le système même, donc il faut le faire avec un chroot....et avant il faut monter avec l'option bind /dev, /sys, et /proc. C'est indiqué dans le message antérieur aussi.

statis a écrit :

Je change les labels avec Gparted.


C'est ne pas nécessaire, et quand même ça peut être fait après,même dès le propre système en marche.

statis a écrit :

Et cela devrait être bon...

...si tout va bien, oui...mais rappelle que ce n'est pas du tout nécessaire pour que ton clone marche (tu l'as déjà vérifié). C'est seulement nécessaire si tu as besoin de démarrer avec les deux disques branchés à la fois. Je te récommends lire mon message antérieur avec un peu de calme, c'est un peu dense, mais toute l'information est là.

statis a écrit :

Bonne année à toi empanada

Bonne année!!!

Dernière modification par empanada (01-01-2019 17:14:52)


"blues are the roots and the other musics are the fruits" . Willie Dixon

Hors ligne

#10 01-01-2019 19:29:06

statis
Membre
Distrib. : Debian-9 64 bits stretch
Noyau : Linux deb64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1
(G)UI : Mate 1.16.2
Inscription : 19-12-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

Merci empanada,

J'avoue avoir du mal à suivre quand les informations sont éparpillées, je suis un surimi wink

Oui je suis sûr d'avoir lancé la commande :

mount /dev/sdj1 /mnt


sans avoir eu de retour d'erreur

La commande liste bien les fichiers présents sur le clone

ls /mnt



bin   etc   initrd.img.old  lost+found  opt   run   sys  var
boot  home    lib     media       proc  sbin  tmp  vmlinuz
dev   initrd.img  lib64     mnt       root  srv   usr  vmlinuz.old
 



et pas d'erreur au démontage

umount /mnt



C'est intéressant pour ceux qui savent travailler les fichiers en ligne de commande.
Mais avec mon D9 Mate tel qu'il est installé cela ne donne pas accès au disque avec l'explorateur de fichier.

Pour le tune2fs, il est dans ton script qui pour moi est en langage humain incompréhensible pour du surimi...

uuidgen fait partie de mon D9 Mate, je n'ai pas eu besoin de l'installer.

statis a écrit :

    Je modifie

       

/etc/fstab



       

/etc/initramfs-tools/conf.d/resume



       

/boot/grub/grub.cfg



    Avec les nouveaux UUID
    met à jour
   

update-initramfs -u



   

update-grub



Oui...mais ça doit être fait dès le système même, donc il faut le faire avec un chroot....et avant il faut monter avec l'option bind /dev, /sys, et /proc. C'est indiqué dans le message antérieur aussi.



La référence à chroot et l'option bind /dev, /sys, et /proc est au sein de ton script que je ne comprends pas.

Note, j'ai enlevé mon clone à deux reprises du dock USB et j'ai du me tromper dans les manipulations car en ouvrant Gparted une fois de plus il est pasé de la lettre J à L...

En visu Gparted mon clone à une partition principale en ext4 avec la lettre l et le chiffre 1, une étendue en extended avec la lettre l et le chiffre 2, à l'intérieur de celle-ci une partition swap avec la lettre l et le chiffre 5.

Chose que j'aurais pu voir avec :

blkid



/dev/sdc1: LABEL="BCK152" UUID="652F705340C8A8DC" TYPE="ntfs" PTTYPE="dos" PARTUUID="7df437b2-01"
/dev/sda1: UUID="3766f605-232e-479b-a6d1-fc7abd54dbda" TYPE="ext4" PARTUUID="ccc234f9-01"
/dev/sda5: UUID="54dfdb75-ac20-4b18-9ea0-4e95d0631a1f" TYPE="swap" PARTUUID="ccc234f9-05"
/dev/sdb1: LABEL="DATA148" UUID="138235FC621FCFF9" TYPE="ntfs" PTTYPE="dos" PARTUUID="a1fc7e4b-01"
/dev/sdl1: UUID="3766f605-232e-479b-a6d1-fc7abd54dbda" TYPE="ext4" PARTUUID="ccc234f9-01"
/dev/sdl5: UUID="54dfdb75-ac20-4b18-9ea0-4e95d0631a1f" TYPE="swap" PARTUUID="ccc234f9-05"
 



fsck."type" /dev/sd"lettre+chiffre" #tune2fs ait bésoin d'un système propre
tune2fs -U random /dev/sd"lettre+chiffre" #Changer l'UUID. tune2fs crée un aléatoire avec "-U random" . Répéter avec le swap si nécessaire.


donnerait donc :

fsck.ext4 /dev/sdl1 #tune2fs ait bésoin d'un système propre
tune2fs -U random /dev/sdl1 #Changer l'UUID. tune2fs crée un aléatoire avec "-U random" . Répéter avec le swap si nécessaire.


et comme il y a une swap il faudrait rajouter :

fsck.swap /dev/sdl5 #tune2fs ait bésoin d'un système propre
tune2fs -U random /dev/sdl5 #Changer l'UUID. tune2fs crée un aléatoire avec "-U random" . pour le swap si nécessaire.



pour la partition principale :

mount /dev/sd"lettre+chiffre" /mnt/sd"lettre+chiffre"
mount --bind /dev /mnt/sd"lettre+chiffre"/dev
mount --bind /proc /mnt/sd"lettre+chiffre"/proc
mount --bind /sys /mnt/sd"lettre+chiffre"/sys
chroot /mnt/sd"lettre+chiffre"



donnerait

mkdir /mnt/sdl1
mount /dev/sdl1 /mnt/sdl1
mount --bind /dev /mnt/sdl1/dev
mount --bind /proc /mnt/sdl1/proc
mount --bind /sys /mnt/sdl1/sys
chroot /mnt/sdl1



Mais que faire pour le swap ?

Pour la suite :

blkid #pour voir le  nouveau UUID
#changer dans /etc/fstab l'ancien UUID de la partition racine par le nouveau UUID (et du swap s'il y en a)
#changer le nom de hôte sur /etc/etc/hostname



On récupère le UUID principal et celui du swap avec blkid (pas d'exécution puisque je n'ai pas lancé l'opération à cause de mon ignorance pour travailler le swap présent dans mon cas)

On remplace dans /etc/fstab :
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=

3766f605-232e-479b-a6d1-fc7abd54dbda

/               

ext4

    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=

54dfdb75-ac20-4b18-9ea0-4e95d0631a1f

none           

swap

    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0



Je n'ai pas de fichier /etc/etc/hostname mais un /etc/hostname dans lequel il y a mon nom d'utilisateur.
Changer le nom d'utilisateur aura-t-il un impact sur ceux qui ont activé l'auto-login comme moi et sur le mot de passe super-utilisateur qui dans mon cas a été choisi comme étant le même à l'installation ?

je suppose que

update-grub
grub-install /dev/sd"lettre du clone"
exit



pour moi

update-grub
grub-install /dev/sdl
exit


est une opération à faire communément à un clone avec ou sans swap

avec

umount /mnt/sd"lettre+chiffre"/dev /mnt/sd"lettre+chiffre"+/proc /mnt/sd"lettre+chiffre"/sys
umount /mnt/sd"lettre+chiffre"


qui pour moi serait

umount /mnt/sdl1"/dev /mnt/sdl1/proc /mnt/sdl1"/sys
umount /mnt/sdl1



concernerait la parttion principale mais pour le swap est-ce la même opération ?

empanada, désolé d'être nul et merci pour ta patience


J'ai un QI de surimi et je peux faire de grosses bêtises...

Peux-tu combattre ta propre nature ? Si oui, cela fait partie de ta nature… Mépriser ceux qui n’ont pas ta chance, Est une grave insulte à la providence…
Julius Korlang

Hors ligne

#11 01-01-2019 19:55:32

empanada
Membre
Distrib. : Debian 9 (Stretch)
Noyau : 4.9.0-7-amd64
(G)UI : LXDE
Inscription : 19-09-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

statis a écrit :

Mais avec mon D9 Mate tel qu'il est installé cela ne donne pas accès au disque avec l'explorateur de fichier.

Met le chemin /mnt dans la barre d'adresses de thunar et/ou navigue vers /mnt avec les boutons: la partition est bien monté. Il me semble que t'en penses que s'il n'apparaît pas un icone dans le bureau ou dans les menus thunar, la partition n'est pas montée...mais ce ne pas vrai. Je ne connais en détail le fonctionnement de thunar, mais je suspect qu'il ne montre que les icones des systèmes montées avec gvfs et/ou sous /media et/ou /media/nom_utilisateur. Vérifie, la partition, si montée, tu doit la voir avec un explorateur de fichiers quelconque, ile ne faut qu'aller au répertoire ou le système de fichiers est montée.

Pour le reste, je reviens plus tard, pour expliquer en détail,  mais, sauf pour le plaisir d'apprendre, ou bien si tu avoues utiliser très fréquent ce disque, je ne conseille pas la procédure si tu n'est pas sûr. Ce n'est pas difficile, mais une fois commencé, il faut arriver au but, parce que sinon le système reste pas amorçable. Tu peut toujours reprendre quand tu veux, mais il faut arriver à la fin pour rendre le système amorçable.
Salut


"blues are the roots and the other musics are the fruits" . Willie Dixon

Hors ligne

#12 01-01-2019 20:33:44

statis
Membre
Distrib. : Debian-9 64 bits stretch
Noyau : Linux deb64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1
(G)UI : Mate 1.16.2
Inscription : 19-12-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

merci 100 fois empanada wink

Je récapitule :

Pour trouver la lettre et le chiffre du clone avec

blkid


blkid



/dev/sdc1: LABEL="BCK152" UUID="652F705340C8A8DC" TYPE="ntfs" PTTYPE="dos" PARTUUID="7df437b2-01"
/dev/sda1: UUID="3766f605-232e-479b-a6d1-fc7abd54dbda" TYPE="ext4" PARTUUID="ccc234f9-01"
/dev/sda5: UUID="54dfdb75-ac20-4b18-9ea0-4e95d0631a1f" TYPE="swap" PARTUUID="ccc234f9-05"
/dev/sdb1: LABEL="DATA148" UUID="138235FC621FCFF9" TYPE="ntfs" PTTYPE="dos" PARTUUID="a1fc7e4b-01"
/dev/sdl1: UUID="3766f605-232e-479b-a6d1-fc7abd54dbda" TYPE="ext4" PARTUUID="ccc234f9-01"
/dev/sdl5: UUID="54dfdb75-ac20-4b18-9ea0-4e95d0631a1f" TYPE="swap" PARTUUID="ccc234f9-05"



ce qui dans mon cas est sdl1 pour

mount /dev/sd"lettre+chiffre"/mnt



mount /dev/sdl1 /mnt



pour vérifier que çà c'est bien passé

ls /mnt



bin   etc   initrd.img.old  lost+found  opt   run   sys  var
boot  home    lib     media       proc  sbin  tmp  vmlinuz
dev   initrd.img  lib64     mnt       root  srv   usr  vmlinuz.old



J'accède bien aux fichiers du clone wink

Ensuite comme je n'ai pas Thunar mais Caja en implicite (je ne changerais pas car sur mon précédent OS j'avais l'implicite avec le rajout qui faisait pas trop bon ménage et caja me convient bien)
Je vais dans le menu "aller à"/emplacement pour faire apparaître le champ "chemin" dans lequel je met

/mnt

.
Et magie j'ai mes fichiers dans l'explorateur que je peux travailler en copie/suppression dans les deux sens vers un autre disque wink

note, désinstaller Caja au profit d'un autre doit déjà exister dans un fil, je regarderais et s'il n'y en a pas j'en ferais un juste pour savoir comment faire, donc pas la peine de m'expliquer ici wink

Ensuite, une fois mes opérations finies je lance

umount /mnt



Super smile smile smile smile smile

Je ne sais pas s'il vaudrait pas mieux mettre ce fil en résolu et reprendre les modifs à faire sur le clone pour pouvoir l'utiliser en même temps que l'original sur un fil dédié pour plus de clarté.
Dans ce cas je mettrait le lien dans le fil actuel et recopierais le dernier échange qui est exposé que dans le fil actuel wink

Dernière modification par statis (01-01-2019 20:38:04)


J'ai un QI de surimi et je peux faire de grosses bêtises...

Peux-tu combattre ta propre nature ? Si oui, cela fait partie de ta nature… Mépriser ceux qui n’ont pas ta chance, Est une grave insulte à la providence…
Julius Korlang

Hors ligne

#13 01-01-2019 21:32:23

empanada
Membre
Distrib. : Debian 9 (Stretch)
Noyau : 4.9.0-7-amd64
(G)UI : LXDE
Inscription : 19-09-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

statis a écrit :

Ensuite comme je n'ai pas Thunar mais Caja en implicite (je ne changerais pas car sur mon précédent OS j'avais l'implicite avec le rajout qui faisait pas trop bon ménage et caja me convient bien)
Je vais dans le menu "aller à"/emplacement pour faire apparaître le champ "chemin" dans lequel je met

/mnt

.
Et magie j'ai mes fichiers dans l'explorateur que je peux travailler en copie/suppression dans les deux sens vers un autre disque wink

J'avais dit Thunar parce que j'avais un autre fil dans la tête, je n'avais pas vu votre profil qu'indique Mate, et sur ce forum il me semble que XFCE c'est le bureau plus commun, mais tu as bien compris que je faisait référence à un explorateur de fichiers quelconque. Ce "caja" je n'avais même jamais entendu lol .

statis a écrit :

Je ne sais pas s'il vaudrait pas mieux mettre ce fil en résolu et reprendre les modifs à faire sur le clone pour pouvoir l'utiliser en même temps que l'original sur un fil dédié pour plus de clarté.
Dans ce cas je mettrait le lien dans le fil actuel et recopierais le dernier échange qui est exposé que dans le fil actuel wink

Complètement d'accord. Un fil pour un sujet concret. Le problème "Disque Debian 9 cloné pas lisible par son original" (au passage, bon titre qui permet vite savoir de quoi on parle) c'est résolu. Seulement rappeller avec des majuscules aux utilisateurs:
JAMAIS BRANCHER DEUX CLONES SOUS LA MÊME MACHINE AVANT L'AMORÇAGE

statis a écrit :

merci 100 fois empanada wink


Merci à toi. . Belle résumé que t'as fait, toujours sachant que les recettes ne peuvent appliquer jamais au pied de la lettre, mais qui peut bien servir aux prochains personnes qui tombent sur ce fil.

Salut


"blues are the roots and the other musics are the fruits" . Willie Dixon

Hors ligne

#14 02-01-2019 11:46:04

statis
Membre
Distrib. : Debian-9 64 bits stretch
Noyau : Linux deb64 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1
(G)UI : Mate 1.16.2
Inscription : 19-12-2018

Re : Disque Debian 9 cloné pas lisible par son original [résolu]

ce fil étant résolu en #12, j'en ouvre un autre pour la cohabitation des deux disques au sein d'une même machine https://debian-facile.org/viewtopic.php … 55#p288155

Merci à tous les aidants wink

J'ai un QI de surimi et je peux faire de grosses bêtises...

Peux-tu combattre ta propre nature ? Si oui, cela fait partie de ta nature… Mépriser ceux qui n’ont pas ta chance, Est une grave insulte à la providence…
Julius Korlang

Hors ligne

Pied de page des forums