[Résolu] Problème après copie partition : DD vers SSD

phlinux · 22-05-2022 11:22:57

Bonjour,
Est-ce que le même identifiant, /dev/disk/by-id/ata-ST380215A_9QZ2MLS2, sur 2 partitions, l'une étant la copie de l'autre (DD= original, SSD=copie), peut être la source de problèmes, par exemple lors d'un lancement d'une appli graphique dans un chroot ?

[12:08]phDD:~$ debconf-show grub-pc

grub-pc/install_devices_empty: false

  grub-pc/kopt_extracted: false

  grub-pc/chainload_from_menu.lst: true

  grub-pc/install_devices_failed_upgrade: true

  grub-pc/mixed_legacy_and_grub2: true

  grub2/update_nvram: true

  grub2/kfreebsd_cmdline:

  grub2/device_map_regenerated:

* grub-pc/install_devices: /dev/disk/by-id/ata-ST380215A_9QZ2MLS2

  grub-pc/install_devices_disks_changed:

  grub-pc/postrm_purge_boot_grub: false

  grub2/kfreebsd_cmdline_default: quiet

  grub2/force_efi_extra_removable: false

  grub-pc/install_devices_failed: false

* grub2/linux_cmdline_default: quiet

  grub-pc/disk_description:

  grub-pc/hidden_timeout: false

  grub-pc/timeout: 5

  grub-pc/partition_description:

* grub2/linux_cmdline:

(phssd)ph@phlinux:~$ debconf-show grub-pc

grub-pc/mixed_legacy_and_grub2: true

  grub-pc/disk_description:

* grub2/linux_cmdline_default: quiet

  grub-pc/install_devices_failed: false

  grub2/kfreebsd_cmdline_default: quiet

* grub2/linux_cmdline:

  grub-pc/install_devices_failed_upgrade: true

  grub-pc/timeout: 5

* grub-pc/install_devices: /dev/disk/by-id/ata-ST380215A_9QZ2MLS2

  grub2/force_efi_extra_removable: false

  grub2/device_map_regenerated:

  grub-pc/install_devices_empty: false

  grub-pc/kopt_extracted: false

  grub-pc/partition_description:

  grub2/update_nvram: true

  grub2/kfreebsd_cmdline:

  grub-pc/chainload_from_menu.lst: true

  grub-pc/postrm_purge_boot_grub: false

  grub-pc/install_devices_disks_changed:

  grub-pc/hidden_timeout: false

Merci d'avance

Dernière modification par phlinux (23-05-2022 10:16:30)

raleur · 22-05-2022 11:47:19

Suspicion de problème XY.

Les paramètres debconf de grub-pc ne servent qu'à l'installation et la configuration du chargeur d'amorçage GRUB. Il serait bon de reconfigurer le paquet sur la copie pour spécifier le bon disque et éviter de casser l'amorçage de l'un ou l'autre disque.

dpkg-reconfigure grub-pc

phlinux · 22-05-2022 12:51:59

Après avoir passé cette commande pas de changement; le /dev/disk/by-id/ reste le même sur les 2 partitions et toujours le même problème de lancement d'une appli graphique dans le chroot.
Pour préciser ce problème, en lançant "rox" (mon filer de prédilection) il affiche non pas le contenu du répertoire (/home/ph/) du chroot mais celui de l'hôte; dans ce cas inutile de booter sur la partition du ssd je sais qu'il y aura d'autres soucis.

Bref, peut être plutôt réinstaller grub dans le chroot ?

raleur · 22-05-2022 13:31:08

Bon, je vais me montrer incisif parce que ça commence à bien faire ; quel raisonnement délirant te fait penser que le périphérique de boot défini dans la configuration de GRUB a quoi que soit à voir avec le fonctionnement d'un gestionnaire de fichiers (problème XY) ?

As-tu essayé de lancer rox avec l'option --new ?

phlinux · 22-05-2022 14:33:08

Je suis d'accord, il n'y a apparemment pas de rapport. C'est juste qu'à force de chercher d'où vient le problème, j'explore les pistes que je trouve.
Lancer "rox" n'a aucune importance, ça montre juste que quelque chose est mal configuré; il y a d'autres partitions sur le même ssd, en lvm ou en primaire, et le problème de ne se pose pas.
Il y un lien entre l'original du dd et sa copie sur le ssd; ce n'est ni une UUID clonée, ni quoique soit dans initramfs. Pour le moment le seul rapport est l'identifiant similaire dans grub.

raleur · 22-05-2022 14:49:30

phlinux a écrit :

Je suis d'accord, il n'y a apparemment pas de rapport.

"Apparemment" est en trop. Il n'y a pas de rapport possible ni en apparence, ni en réalité.

phlinux a écrit :

Lancer "rox" n'a aucune importance

Alors pourquoi en parles-tu comme étant le problème ?

phlinux a écrit :

ça montre juste que quelque chose est mal configuré

Non, pas forcément.

phlinux a écrit :

l y a d'autres partitions sur le même ssd, en lvm ou en primaire, et le problème de ne se pose pas.

Qu'est ce que les autres partitions viennent faire ici ? Qu'entends-tu par "le problème ne se pose pas" ?

phlinux a écrit :

Il y un lien entre l'original du dd et sa copie sur le ssd

Oui : le chroot.

Dernière modification par raleur (22-05-2022 14:50:01)

phlinux · 22-05-2022 15:32:44

Non, le chroot n'est pas le lien entre l'original du dd et sa copie sur le ssd.
Si je boote sur la partition phssd tout semble fonctionner correctement, comme sur l'original, sauf les applis microsoft office que je lance à travers wine/crossover. Par exemple si je lance une base *.mdb, msaccess se lance seul; si j'indique le chemin de la base depuis access, il ne se passe rien, access ne trouve pas la base. Pour un classeur *.xls, excel ne trouve pas la macrolib EUROTOOL.XLA, ni le classeur lancé. Pour word c'est encore autre chose. Sur certains essais j'ai un message comme quoi le fichier, ou la base, sont déjà ouverts par un autre utilisateur.
Donc du coup tu dois comprendre la corrélation entre le mauvais affichage renvoyé par rox dans le chroot et les chemins inconnus des applis vers les fichiers. D'ailleurs si je lance ces mêmes applis depuis le chroot il y a le même comportement.

raleur · 22-05-2022 15:50:22

phlinux a écrit :

Si je boote sur la partition phssd tout semble fonctionner correctement

Donc le chroot était bien en cause.

phlinux a écrit :

sauf les applis microsoft office que je lance à travers wine/crossover.

C'était donc bien un problème XY, comme je le soupçonnais depuis le début.
Tu aurais gagné du temps en parlant de ça dès le départ plutôt que de te perdre dans des histoires de rox et de GRUB.
La suite sans moi en tout cas, je ne connais rien à wine.

phlinux · 22-05-2022 16:12:09

Merci tout de même, bien que wine ne soit, à mon avis, pas en cause. Il suffit de copier les 2 répertoires cxoffice et .cxoffice et ça fonctionne sur plusieurs partitions de dd autres que celles du ssd en cause.
C'est soit lvm, soit le ssd, soit un problème de copie de la partition.
Pareil pour Rox-filer jamais je n'ai rencontré une telle erreur, c'est pourquoi j'ai commencé par ça.

Debian-facile

#1 22-05-2022 11:22:57

[Résolu] Problème après copie partition : DD vers SSD

#2 22-05-2022 11:47:19

Re : [Résolu] Problème après copie partition : DD vers SSD

#3 22-05-2022 12:51:59

Re : [Résolu] Problème après copie partition : DD vers SSD

#4 22-05-2022 13:31:08

Re : [Résolu] Problème après copie partition : DD vers SSD

#5 22-05-2022 14:33:08

Re : [Résolu] Problème après copie partition : DD vers SSD

#6 22-05-2022 14:49:30

Re : [Résolu] Problème après copie partition : DD vers SSD

#7 22-05-2022 15:32:44

Re : [Résolu] Problème après copie partition : DD vers SSD

#8 22-05-2022 15:50:22

Re : [Résolu] Problème après copie partition : DD vers SSD

#9 22-05-2022 16:12:09

Re : [Résolu] Problème après copie partition : DD vers SSD

Pied de page des forums