Ce qui doit être dit doit être dit
Si j'effectue une rétrospection de ce fil : force m'est de constater que la brutalité des commandes claironnées par
Jeanjd63 -->
Salut
@rk44
Pardon pour cette petite interruption de l'image.
Perso je tenterai la méthode brutale :
sudo diskutil zerodisk /dev/disk5
au message
#24 et au message
#30 :
Encore plus brutal :
sudo dd if=/dev/zero of=/dev/rdisk5 count=1000 bs=1024
n'avait de brutal que le procédé parfaitement discourtois à l'égard des participants de la conversation - moi-même en particulier. Car, ne pas attendre l'issue d'une commande
gdisk qui était en cours d'exécution pour opérer une intrusion grossière : voilà certes une brutalité d'orateur consistant à couper la parole à autrui pour se propulser sur le devant de la scène publique. Il est vrai que dans l'Antiquité Romaine déjà, à qui l'on doit l'invention du Forum, il existait des "pousse-toi de là que je m'y mette" du même acabit.
Car lesdites commandes ne recelaient aucune « brutalité logique » intrinsèque dans le contexte donné > mais n'étaient que des pétards mouillés.
En effet > une commande
diskutil avec le verbe
zerodisk --> ne peut adresser un disque en tant que
device qu'à la condition stricte que la table de partition
GPT ne soit pas "
occupée" par le
montage actuel d'un volume. Comme l'erreur retournée l'a avéré :
Bloc de code:
Error: -69879: Couldn't open disk
Underlying error: 16: Resource busy
le montage du volume
apfs disk6s1 - volume impossible à
démonter - "occupait" la table de partition et proscrivait donc son effacement.
De même la commande
dd citée ne pouvait opérer sur le disque qu'à la condition stricte que la table de partition soit "désoccupée" > càd. que tous les volumes montés sur les partitions du disque aient pu être démontés. En l'absence d'un tel démontage > l'erreur était la même :
Bloc de code:
dd: /dev/rdisk5: Resource busy
Comme une commande
lsof antérieure avait avéré qu'
aucun processus n'utilisait le volume récalcitrant
Backup Os Mini > il était donc tout aussi futile et en rien logiquement "brutal" de démarrer en mode
Recovery pour -->
Sinon reste le mode Recovery pour être sûr que rien ne viendra utiliser la partition.
Et là je pense qu'un vieux dd de derrière les fagots devrait en venir à bout.
puisque manifestement ce type de démarrage ne pouvait rien changer au statut d'un volume non utilisé au départ par un processus.
Enfin > sachant qu'une commande
gpt ne peut jamais
opérer sur un disque dont au moins un volume reste
monté > il était donc vain a priori de recourir à cette commande.
La supériorité intrinsèque de la commande
gdisk par rapport à toutes ces commandes est celle-ci :
gdisk est capable d'
écrire au secteur d'amorçage d'un disque
même si les volumes de ce disque sont montés sur les partitions. Ce n'est donc pas un utilitaire qui requiert comme les exécutables plus faibles :
diskutil >
dd ou
gpt le
démontage préalable des volumes pour pouvoir opérer sur le disque.
De ce point de vue >
gdisk a fait la preuve ici de sa supériorité en étant capable d'adresser en lecture le secteur d'amorçage du disque comme montré ici :
Bloc de code:
Warning! Read error 16; strange behavior now likely!
Warning! Read error 16; strange behavior now likely!
Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present
Creating new GPT entries.
Command (? for help):
L'anomalie que décelait
gdisk était qu'
aucune table de partition ne se trouvait lisible de manière intelligible sur les blocs de tête du disque. Pour tenter de pallier cette situation >
gdisk avait donc créé en cache une
table de partition GPT virtuelle.
Malheureusement le message d'erreur lors de l'opération d'effacement des tables de partition :
Bloc de code:
Warning! GPT main header not overwritten! Error is 16
avérait l'impossibilité pour
gdisk d'écrire au
bloc portant le header de la
GPT principale -> càd. d'effacer ce bloc. Voici comment se présente l'en-tête d'un disque valide logiquement :
Bloc de code:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
On voit clairement ici que le bloc
0 ou 1er bloc du disque porte une
table alternative dite
Protective_MBR et que les blocs
1 à
33 portent les descripteurs de la
GPT principale --> ce qui se subdivise en 2 composants : le bloc
1 porte le
header ou en-tête de la
GPT > tandis que les blocs
2 à
33 portent les
descripteurs proprement dits de la table de partition.
Il se laisse reconstituer la situation suivante : sur l'en-tête du SSD --> aucune table
PMBR n'est
lisible intelligiblement sur le bloc
0 > aucune table
GPT n'est non plus
lisible intelligiblement sur les blocs
2 à
33 > mais par contre il y fixation sur le bloc
1 du
header de la
GPT impossible à effacer pour zapper la table de partition.
Bref : les tables de partition ne sont pas lisibles de façon intelligible > et elles sont encore moins effaçables par un acte d'écriture aux blocs --> l'en-tête du disque est donc logiquement verrouillé.
En résumé : l'
échec de la commande la plus forte :
gdisk -->
impliquait nécessairement l'échec des commandes plus faibles =
diskutil >
dd >
gpt. Il était donc parfaitement vain de faire intrusion dans ce fil en le bombardant de commandes a priori vouées à être inopérantes.
- les lecteurs de ce commentaire me trouveront peut-être caustique dans mes propos > mais force m'était de relever ici la « brutale » (pour reciter le mot) incivilité d'une intrusion
en cours même d'opération d'une commande (
gdisk) - ce, sans aucun fondement logique si l'on exerçait tant soit peu le raisonnement au lieu de pratiquer une technologie de commandes sans concept.
