Vous n'êtes pas identifié(e).
Pages : 1
Dernière modification par jarek (07-06-2020 10:22:53)
Dernière modification par MicP (19-05-2020 03:08:46)
Hors ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
En ligne
Et encore une commande que je ne connaissais pas . . . merci !
Sous buster 10.4 tout frais
C'est-à-dire ?
Nouvelle installation avec ou sans repartitionnement, mise à niveau depuis une version précédente ?
La seule hypothèse qui me vient serait que la table de partition GPT ne couvrait pas tout le disque (elle indique les premier et dernier secteurs utilisable entre la table principale située au début et la table de secours située à la fin), et l'action "réparer" dans Gparted a étendu la plage couverte par la table à tout le disque en déplaçant la table de partition de secours.
Les seules hypothèses qui me viennent pour expliquer que la table de partition ne prenait pas en compte tout le disque sont
- clonage depuis un disque de capacité inférieure
- présence d'une zone protégée (HPA = host protected area, cf. hdparm -N) qui masquait la fin du disque et qui a depuis été désactivée.
En tout cas ça ne semble pas venir du noyau qui aurait désactivé la HPA (libata.ignore_hpa=1) comme le font les noyaux d'openSUSE la dernière fois que j'ai regardé. Avec le dernier noyau 4.19.0-9 de Debian 10.4, le paramètre est toujours à 0 par défaut.
Il vaut mieux montrer que raconter.
Hors ligne
- clonage depuis un disque de capacité inférieure
Gagné !!!
Si tu n'en avais pas parlé . . .
La debian 10.3 qui a été clonée sur ce disque 256 G venait du ssd M2 250 G installé à l'origine.
Ce ssd M2 a été ensuite installé sur une autre machine.
Le mystère est résolu, mais est-ce que je peux appliquer la procédure décrite #1 ?
Il vaut mieux montrer que raconter.
Hors ligne
Pages : 1