Un disque tellement plein qu’il était impossible à restaurer

• Le volume de démarrage d’un MacBook Pro M2 s’est rempli au point de ne laisser que 41 Ko libres pendant le téléchargement de jeux Steam, mettant macOS dans un état où il ne pouvait même plus supprimer de fichiers
• Vider la corbeille dans le Finder, utiliser rm et find -exec rm dans le Terminal, jusqu’à la suppression des instantanés Time Machine dans Utilitaire de disque : tout a échoué avec des erreurs du type « No space left on device »
• Après redémarrage, le boot s’est lui aussi bloqué à mi-parcours, et même en montant le disque sur un autre Mac via recoveryOS et Share Disk sur Apple silicon, il a été impossible de forcer la suppression
• Après effacement du disque et réinstallation de macOS, une restauration Time Machine a été tentée, mais l’opération s’est enchaînée avec un abandon sous Ventura, un décalage de version entre Sonoma 14.4 et l’ancienne 14.3.1, puis un échec des montages réseau SMB/Samba
• Au final, la dernière image disque Time Machine a été copiée sur un SSD externe de 1 To pour restaurer manuellement les fichiers du dossier personnel et les apps ; quand l’épuisement du stockage et l’échec de la restauration de sauvegarde se cumulent, même un utilisateur expérimenté peut difficilement s’en sortir

---

Un Mac où le manque d’espace empêche même de supprimer

• Le stockage d’un MacBook Pro M2 s’est rempli pendant le téléchargement sur Steam de jeux achetés légalement
• macOS n’a pas interrompu ce gros téléchargement Steam alors que le disque arrivait à un niveau critique, et il ne restait plus que 41 Ko sur le volume de démarrage
• La plupart des fichiers importants étaient dans le cloud, et il n’y avait pas de gros fichiers locaux absolument indispensables à préserver
• Le problème n’était pas un simple manque d’espace, mais le fait que le système d’exploitation n’était plus capable de supprimer des fichiers par aucun moyen

Cause suspectée : téléchargement Steam et instantanés Time Machine locaux

• Avec une connexion Internet gigabit et de très gros fichiers Steam, il est possible que macOS n’ait pas réussi à contrôler la hausse de l’occupation du disque
• Le fait que macOS créait en même temps des instantanés Time Machine locaux est aussi suspecté
• macOS conserve des instantanés afin de fournir des sauvegardes locales des dernières 24 heures, même lors de sauvegardes vers une destination Time Machine externe ou réseau
• Les fichiers Steam semblaient n’être qu’un seul énorme fichier, mais il est possible qu’ils aient été traités différemment du point de vue de Time Machine
• Il a pu y avoir un conflit entre les fichiers locaux réels et des instantanés créés d’une manière particulière, sans qu’une cause exacte puisse être établie

Toutes les tentatives de suppression ont échoué

• Vider la corbeille dans le Finder a échoué via File > Empty Trash
  • Le message d’erreur était : « The operation can’t be completed because the disk is full »
• Le Terminal s’ouvrait, mais la commande Unix standard rm ne fonctionnait pas
  • Le message d’erreur était : « No space left on device »
  • Une alternative basée sur find, qui recherchait les gros fichiers puis exécutait rm avec l’option -exec, a elle aussi échoué
• Dans Utilitaire de disque, la tentative de supprimer les instantanés Time Machine du volume de démarrage APFS s’est heurtée à la même limite
  • En général, les instantanés n’occupent que l’espace nécessaire aux différences avec l’instantané précédent
  • Mais ici aussi, une erreur « no space left » est apparue

Redémarrage, recoveryOS et Share Disk n’ont rien résolu

• Un redémarrage a été tenté dans l’espoir de purger les caches, mais le Mac ne démarrait plus normalement
• L’échec se répétait après que la barre de progression atteignait environ la moitié
• Depuis recoveryOS, des opérations de réparation dans Utilitaire de disque et de réinstallation ont été tentées alors que le volume de démarrage n’était pas monté, mais les commandes du Terminal renvoyaient les mêmes erreurs
• La fonction Share Disk d’Apple silicon a été utilisée pour monter le disque sur un autre Mac
  • Une suppression forcée a été tentée via un partage de disque basé sur Samba, sans succès

Problèmes en chaîne pendant la restauration Time Machine

• Des sauvegardes Time Machine existaient, y compris celle de la veille au soir, et comme l’essentiel des données importantes était dans le cloud, une restauration parfaitement complète n’était pas indispensable
• Le disque a d’abord été effacé, puis Ventura, le système d’origine du MacBook Pro, a été réinstallé via macOS Recovery
• Au démarrage de macOS, l’accès à la sauvegarde Time Machine réseau s’est fait via l’Assistant migration, en décochant certains éléments de restauration pour conserver assez d’espace libre
• En cours de restauration, Ventura s’est bloqué à mi-chemin et n’a ensuite jamais repris
• Le Mac a ensuite été mis à niveau vers Sonoma, la version de macOS utilisée auparavant
  • La mise à niveau a réussi, mais la version installée était la 14.4
  • L’ancien Mac utilisait la 14.3.1
  • En essayant de restaurer directement au démarrage, l’opération a été refusée à cause de cette différence de version

Problème de montage réseau Time Machine sous Sonoma 14.4

• Un compte utilisateur Sonoma par défaut a été créé, puis l’Assistant migration a été lancé
• L’Assistant migration trouvait et reconnaissait bien le Mac réseau qui gérait la sauvegarde Time Machine
• En revanche, il ne parvenait pas à monter le volume de sauvegarde de l’enfant, affichant à répétition « Mount failed »
• D’après les recherches sur les forums, la procédure de montage réseau SMB/Samba pour la restauration Time Machine est cassée sous Sonoma, sans solution identifiée
• Ce problème semblait toujours exister avec macOS 14.4

Récupération finale : copier la sauvegarde sur un SSD externe et migrer à la main

• L’idée d’une restauration complète via l’Assistant migration a été abandonnée, au profit d’une récupération manuelle des seules apps et fichiers nécessaires
• Sur le Mac qui gérait la sauvegarde réseau, l’image disque de cet ordinateur a été ouverte par double-clic puis le mot de passe du volume Time Machine a été saisi
  • Un mot de passe distinct était toujours défini pour le volume Time Machine réseau
• L’icône disque portant l’horodatage le plus récent a été trouvée puis copiée sur un SSD externe de 1 To vide
• Le SSD externe a été branché sur le compte temporaire du MacBook Pro afin de transférer les fichiers nécessaires
  • Il contenait l’essentiel des dossiers du répertoire personnel
  • Certains gros fichiers téléchargés et quelques vidéos inutiles ont été exclus
• Le SSD externe sera conservé quelque temps afin de pouvoir récupérer d’autres fichiers en cas d’oubli

Alternatives qui n’ont pas pu être testées

• Il aurait été possible de démonter le disque Time Machine réseau depuis le Mac qui gérait la sauvegarde, puis de le connecter directement au Mac de l’enfant
  • Dans ce cas, il aurait peut-être été proposé comme point de départ dans l’Assistant migration
• Il aurait aussi été possible de copier le disque virtuel depuis l’image disque Time Machine montée, de façon à ce que le SSD externe de 1 To apparaisse comme le volume source du Mac
  • Il n’a pas été vérifié si cette méthode aurait réellement fonctionné
  • En cas de succès, une restauration directe via l’Assistant migration aurait pu être envisageable
• Comme plusieurs heures de travail et plus d’une journée d’essais s’étaient déjà accumulées, et que l’utilisateur ne tenait pas particulièrement à une récupération parfaite à l’échelle de l’arborescence complète, aucune expérience supplémentaire n’a été tentée

[GN⁺]

Avis sur Hacker News

• L’auteur aurait peut-être mieux fait de démarrer le Mac depuis un périphérique de stockage externe, puis de supprimer les fichiers inutiles du disque interne : Use an external storage device as a Mac startup disk
  J’ai été surpris d’apprendre que, sur les Mac à Apple Silicon, tous les ports ne se valent pas pour le démarrage externe
  Lors de l’installation de macOS sur un périphérique de stockage, les Mac portables doivent éviter le port USB-C le plus à gauche parmi les ports de gauche, et les iMac/Mac mini/Mac Studio/Mac Pro ont eux aussi, selon le modèle, un port USB-C particulier à éviter
  Une fois l’installation terminée, il paraît qu’on peut le brancher sur n’importe quel port

  • Il a déjà essayé quelque chose d’en pratique équivalent à ce qui est proposé
    L’auteur a démarré sur recoveryOS, une partition séparée, puis a tenté de supprimer des fichiers de la partition système principale, mais rm a échoué avec la même erreur No space left on device
    Du coup, comme d’autres l’ont dit, tronquer le fichier avec echo -n >file aurait peut-être fonctionné
  • Si le système de fichiers lui-même est dans une situation de blocage, supprimer des fichiers via le pilote du système de fichiers ne marchera pas, peu importe d’où l’on démarre
  • Ça n’a pas marché avec recoveryOS ni avec le mode Mac Share Disk/Target Disk ; je me demande donc pourquoi cette méthode fonctionnerait
  • Ce genre de commentaire fera vraiment plaisir, dans 8 ans, à quelqu’un qui cherchera à résoudre un problème sur un Mac alors déjà ancien
  • Je me demande si quelqu’un sait pourquoi il ne faut pas utiliser le premier port USB-C quand on crée un OS démarrable sur un Mac portable

• En extrapolant à partir de quelques connaissances sur la structure des disques HFS+, le fichier journal était peut-être lui aussi plein, et comme une suppression nécessite d’écrire dans le journal, voire de l’étendre, on se retrouve dans une situation étrange où supprimer demande, même temporairement, davantage d’espace
  macOS a continué à écrire des fichiers jusqu’à ce qu’il ne reste plus que 41 Ko sur le disque
  Il m’est déjà arrivé de remplir par erreur des volumes NTFS et FAT32 jusqu’à 0 octet, et même là, supprimer quelque chose restait possible
  En fouillant les forums, il semble que Sonoma ait cassé la procédure de montage réseau basée sur SMB/Samba pour la restauration Time Machine, et qu’il n’y ait toujours pas de solution en 14.4
  D’après mon expérience, SMB est devenu peu fiable et beaucoup trop bogué depuis environ 10.12–10.13, et Apple semble désormais ne même plus se soucier de savoir si ça fonctionne
  Je n’ose pas imaginer ce que feraient des personnes sans des décennies d’expérience sur Mac face à une telle cascade de défaillances système
  Je n’ai pas des décennies d’expérience sur Mac, mais dans une situation comme celle-ci j’aurais d’abord essayé fsck, et je trouve étrange que ce ne soit pas mentionné
  S’il était impossible de copier le contenu du disque vers un autre disque, de formater puis de restaurer, je consulterais la documentation APFS (https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf) et j’essaierais de voir, avec dd et un éditeur hexadécimal, quoi corriger pour libérer de l’espace

  • Ça vaut pour un système de fichiers journalisé ; dans un système de fichiers à copie à l’écriture (CoW), toute modification crée une nouvelle arborescence de fichiers, puis la racine est mise à jour pour pointer vers cette nouvelle arborescence
    Ensuite, le ramasse-miettes repère les fichiers qui n’appartiennent plus à l’arborescence active et restitue l’espace de stockage
    En général, les modifications sont regroupées afin de réduire le volume de changements dans l’arborescence à un niveau gérable, et grâce à cette conception, un instantané du système de fichiers devient simplement une autre référence vers une arborescence donnée
    Ce processus a besoin d’espace, mais les systèmes de fichiers CoW réservent généralement de l’espace de secours précisément pour cette raison
  • Apple est passée depuis longtemps à sa propre implémentation après l’adoption de la GPLv3 par Samba : https://lists.samba.org/archive/samba-announce/2007/000122.html, https://www.engadget.com/2011-03-24-apple-to-drop-samba-networking-tools-from-lion.html
  • Comme souvent avec Apple, les performances de SMB étaient atrocement lentes il y a quelques années et, même récemment, elles sont tout juste acceptables ; elles restent bien plus lentes que NFS sur le même matériel ou, ironiquement, qu’Appleshare
    Il y a quelques années, sur un Hackintosh connecté en 10GbE à un gros NAS, BlackMagic Disk Speed Test donnait 900 Mo/s avec SMB sous Windows, 200 Mo/s avec SMB sous macOS, et 1000 Mo/s avec NFS comme avec AFP sous macOS
    Les fonctionnalités macOS liées au travail professionnel sont malheureusement d’un niveau ridicule
    On dit qu’AFP est mort, mais sur mon Mac Pro il fonctionne encore très bien comme client, et ses performances sont tellement meilleures que SMB que ça en devient presque comique
  • Ce n’est pas drôle quand ça vous arrive, mais la même chose peut se produire aussi avec BTRFS et ZFS
    Si on les remplit jusqu’au bout, des problèmes peuvent survenir
    BTRFS essaie de passer en lecture seule tant qu’il reste encore de l’espace pour les métadonnées, ce qui permet de le remonter en mode sans échec et de supprimer quelque chose, mais ce n’est pas une protection parfaite
    À ma connaissance, NTFS et FAT32 ne sont pas des systèmes de fichiers journalisés
  • Jusqu’ici, c’est la seule explication technique qui me semble vraiment correcte

• J’ai vécu ça dans mon premier job
  J’avais rempli par erreur le cluster avec des fichiers de jobs, et l’administrateur système a commencé à m’envoyer des e-mails pour que je corrige ça vite, mais rm ne fonctionnait pas
  C’est là que j’ai appris que même quand la suppression ne marche pas, tronquer un fichier fonctionne généralement ; donc quand rm foo échoue, cat /dev/null > foo suffit souvent

  • Dans un shell, :>filepath marche souvent
    Cela dit, certains systèmes de fichiers peuvent même refuser ça
    Dans ce cas, il faut espérer que le système de fichiers prenne en charge l’extension, la réduction, ou l’ajout temporaire d’espace de stockage, ou que le sous-système permette d’ajouter/retirer du stockage de backing
    Comme avec btrfs, il peut aussi falloir une commande distincte pour revenir à une structure destinée à un seul périphérique bloc
  • Il y a quelques années, on avait une situation où une infrastructure critique, qui devait absolument pouvoir écrire dans le système de fichiers, pouvait se retrouver en interblocage et irrécupérable
    On a donc fait en sorte que le processus de sauvegarde envoie périodiquement des données bidon directement vers /dev/null, et ce bidouillage assez sale tourne probablement encore
    /dev/null est magique, ça vaut le coup de le lire au moins une fois
  • En fait, un simple >file suffit
  • Mais comme plusieurs commentaires ici le disent, il existe aussi des situations où même la troncature échoue
    Les formats de systèmes de fichiers du XXIe siècle sont bien plus complexes qu’UFS, et des fonctions comme les snapshots et la journalisation introduisent de nouvelles façons pour un système de fichiers de se mettre lui-même en interblocage
  • Il m’est arrivé de régler le niveau de logs de Samba beaucoup trop haut pour du débogage et d’oublier de le remettre, remplissant le SSD racine ZFS avec un énorme fichier de log
    J’ai fini par devoir récupérer la situation avec truncate
    Je savais que ZFS s’en sort mieux dans ce genre de situation, mais ça n’empêche pas cette sensation de naufrage, ce “ah… merde”, quand on a vraiment l’impression d’avoir tout cassé

• Time Machine semble se dégrader constamment
  Je ne comprends pas pourquoi ils n’ont aucune motivation à le rendre stable et vraiment fonctionnel
  À force d’avoir des sparse bundles corrompus qui obligent à repartir sur une nouvelle sauvegarde, ou des fonctions qui échouent, j’ai maintenant l’impression que configurer Time Machine n’en vaut plus vraiment la peine
  C’est tout l’inverse des sauvegardes iOS/iPadOS, qui ont toujours bien fonctionné

  • C’est parce qu’ils ne vendent plus de Time Capsule
    Apple veut que les gens sauvegardent tout sur iCloud pour augmenter ses revenus de services
  • Vu de quelqu’un qui n’utilise pas de Mac, ça ressemble à un bug catastrophique et inexcusable qui aurait déclenché une énorme vague de critiques si c’était un système d’exploitation desktop avec une mascotte pingouin ou un siège dans l’État de Washington
  • Time Machine a décidé soudainement de ne plus vouloir travailler, m’obligeant à effacer la sauvegarde et à repartir de zéro, beaucoup trop souvent
  • Le contrôle qualité de macOS décline depuis le licenciement de Scott Forstall, et, à vrai dire, ce n’était déjà pas extraordinaire à son époque
  • Mon expérience est différente
    J’utilise Time Machine sur des partages Samba avec plusieurs Mac depuis des années, et je n’ai vu que des améliorations
    Avant, les sparse bundles Time Machine se corrompaient souvent et il fallait les recréer, ou restaurer un snapshot ZFS antérieur pour continuer
    À l’époque, je crois que c’était AFP plutôt que SMB
    Récemment, je n’ai eu ce problème sur aucun appareil, même si j’ai bien activé dans smb.conf certains flags recommandés pour les sauvegardes Time Machine

• À l’inverse, ZFS dispose de slop space pour éviter qu’un système de fichiers ne se bloque parce qu’il manque d’espace au milieu d’une grosse opération
  Par défaut, il réserve 3,2 % de l’espace du volume, jusqu’à 128 Go
  Donc, sous Linux, en modifiant le paramètre noyau spa_slop_shift pour réduire le slop space, on peut récupérer jusqu’à 128 Go d’espace bonus afin de réussir une suppression de fichiers : https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

  • Exact
    C’est pour ce genre de raison que la réservation d’un pourcentage de l’espace disque était une fonctionnalité courante des “vrais” systèmes de fichiers des décennies avant l’existence de ZFS ou de Linux
    C’est un peu comme le fait que la plupart des programmes de terminal shareware MS-DOS des années 1980 téléchargeaient très bien des fichiers sur des connexions à bande passante limitée, alors qu’aujourd’hui MS Windows gère très mal cette tâche qui devrait être triviale
  • ext4 a la même fonctionnalité, mais l’appelle reserved blocks
    Pour les détails, voir man tune2fs
    La plupart des autres systèmes de fichiers modernes, ou même pas si modernes, font pareil
    De mémoire, UFS sous SunOS dans les années 1980 faisait déjà ça : https://en.wikipedia.org/wiki/SunOS

• Les gens ont du mal à comprendre l’idée que supprimer quelque chose puisse en réalité nécessiter davantage d’espace, temporairement ou définitivement
  D’autres commentaires ont détaillé pourquoi des systèmes de fichiers modernes, avec snapshots, journalisation, etc., peuvent devoir allouer de l’espace libre pour effectuer une suppression
  On retrouve des cas similaires ailleurs : pendant les dix premières années de Wikipedia, il fallait souvent expliquer qu’essayer d’économiser de l’espace serveur en supprimant des pages produisait en fait l’effet inverse
  Au moins depuis autour de 2004, une suppression ajoutait en effet un enregistrement dans la base de données interne
  Dans le format d’archive ZOO de Rahul Dhesi, supprimer une entrée consistait simplement à poser un flag dans un enregistrement d’en-tête, et il y avait aussi la gestion des versions de fichiers à la VMS, où l’ajout d’une nouvelle version n’écrase pas l’ancienne
  À l’époque de MS/DR/PC-DOS et de FAT, si un utilitaire de récupération après suppression était installé, supprimer un fichier pouvait nécessiter plus d’espace, car il fallait enregistrer une nouvelle entrée dans une base de données contenant les informations de restauration
  Certains anciens utilitaires de compression de disque compressaient même les métadonnées ; il était donc possible, dans de rares cas, qu’une modification de métadonnées change le taux de compression et augmente réellement la taille du volume visible de l’extérieur
  L’idée selon laquelle supprimer libère de l’espace est très répandue, mais strictement parlant, elle n’est pas toujours vraie

• J’ai rencontré le même problème en octobre 2018, et je l’avais laissé dans la question Stack Overflow ci-dessous.
  Par chance, j’avais une partition APFS supplémentaire que je pouvais supprimer, ce qui m’a permis de libérer de l’espace disque.
  Il m’a fallu pas mal de temps pour le comprendre, et pendant ce temps j’étais vraiment en panique.
  https://apple.stackexchange.com/questions/338721/disk-full-terminal-in-recovery-mode-won-t-delete-files-boot-kernel-panics
  Juste après avoir mis à jour macOS Mojave, je créais un .dmg, j’ai rempli le disque et le système s’est figé.
  Au redémarrage, j’ai eu un kernel panic ; j’ai démarré en mode récupération, monté le disque, puis exécuté rm /path/to/large/file dans le terminal, mais j’ai obtenu No space left on device.
  C’était essentiellement le même problème que dans ce fil Unix de 2008 : https://www.unix.com/linux/69889-unable-remove-file-using-rm-disk-space-full.html
  echo x > /path/to/large/file n’a pas aidé non plus, et il me fallait une autre suggestion que « effacer le disque et restaurer depuis une sauvegarde ».

  • Créer une petite partition supplémentaire d’environ 1 Go peut être une bonne assurance.
    C’est un peu comme les anciens systèmes de fichiers Unix qui réservaient 5 % à root.
  • Depuis, d’autres solutions potentielles ont aussi été ajoutées à ce message StackExchange.
    Supprimer la partition de mémoire virtuelle peut, à condition qu’elle soit assez grande, rendre suffisamment d’espace pour permettre de supprimer des fichiers.
  • Avec APFS, ce n’est pas aussi simple.
    Les conteneurs ne sont alloués que lorsqu’ils sont effectivement utilisés.

• Impressionnant.
  Je n’ai jamais connu une situation où même rm échoue, mais j’ai bien connu le désagrément d’utiliser et d’administrer des Mac modernes avec 256 Go de stockage interne ou moins.
  C’est pour ça que j’ai tendance à créer un fichier placeholder d’environ 16 Go.
  De toute façon, si l’espace se remplit au point de bloquer une mise à jour ou une autre opération, il suffit de supprimer ce fichier, sans avoir à faire de la chirurgie au scalpel avec ncdu.

  • J’ai vu CockroachDB faire la même chose au démarrage d’un nœud : https://www.cockroachlabs.com/docs/v23.2/cluster-setup-troubleshooting#automatic-ballast-files
  • Le grand avantage d’un fichier placeholder est qu’en libérant cet espace au moment voulu, il donne le temps de mettre en œuvre une solution de long terme.
    Par exemple acheter un nouveau disque quatre fois plus grand, pour le coût d’une heure de travail d’un employé ou d’utilisation du matériel.

• J’ai vécu quelque chose de similaire sur iPhone.
  Le disque était tellement plein que supprimer quelque chose semblait ne rien produire en pratique.
  Après un redémarrage, je ne pouvais plus me connecter ; après un nouveau redémarrage, il est parti en boucle de démarrage.
  Après un redémarrage de plus, il a démarré dans un état incohérent : les icônes des apps étaient encore sur l’écran d’accueil, mais les apps elles-mêmes avaient disparu, avec des icônes vides impossibles à lancer.
  Inquiet pour l’intégrité des données, j’ai fini par restaurer depuis une sauvegarde.
  Je suis convaincu que c’est une conséquence du fait qu’APFS fonctionne en copy-on-write et prend en charge les snapshots.
  Si les modifications ne sont pas rendues permanentes immédiatement et que les anciennes versions des fichiers restent dans des snapshots, cela devient problématique quand il n’y a même plus de place pour les métadonnées des snapshots.
  Quand l’espace disque manque, on pourrait sauter les snapshots, mais le problème des métadonnées CoW demeure.

  • J’ai vécu exactement la même chose.
    Même en 2024, avec toutes les fonctions intelligentes de gestion des volumes APFS, je trouve étonnant qu’il suffise de remplir l’espace de stockage utilisateur pour mettre un appareil « scellé » comme un iPhone dans un état nécessitant une restauration DFU.
    À l’inverse, quand j’ai accidentellement saturé l’espace sur un ordinateur portable professionnel Windows 11 utilisant un volume unique pour les données et le démarrage, il a quand même pu démarrer et me permettre de régler le problème.

• J’ai récemment rencontré une situation similaire sur la partition système d’une installation Linux.
  La partition était trop petite dès le départ, et avec l’accumulation des mises à jour, il ne restait presque plus assez d’espace pour commencer à supprimer quoi que ce soit.
  Il m’a fallu environ 30 minutes pour trouver un sous-répertoire où je pouvais supprimer ne serait-ce qu’un tout petit peu.
  J’avais l’impression d’être coincé dans une pièce tellement remplie de bric-à-brac qu’il était impossible d’ouvrir une porte qui s’ouvre vers l’intérieur.
  À partir de ce minuscule point de départ, j’ai pu supprimer des espaces de plus en plus gros, et une fois le nettoyage terminé, j’ai agrandi la partition pour que cela ne se reproduise plus.

  • Je me demande pourquoi tu n’as pas étendu la partition dès le début.
    Pour un utilisateur expérimenté, la leçon devrait peut-être être de toujours laisser un peu d’espace libre derrière une partition.