Réparer une erreur: partition efi en lecture seule

Encore une fois trébucher d'un problème à l'autre. J'ai récemment installé OpenSuse13.2 en parallèle sur win10. A travaillé bien. Puis j'ai décidé de réintégrer, mais Suse Leap, en supprimant l'ancienne installation de Suse. À la fin de l'installation, l'ordinateur vient de redémarrer et aucune option de démarrage pour Leap n'a été affichée. opensuse reste cependant une option. J'ai eu un problème similaire avec Ubuntu jusqu'à ce que je monte manuellement la partition Efi et que je supprime le dossier Ubuntu. Maintenant, j'ai essayé la même chose, mais je ne peux pas supprimer car la partition est toujours en lecture seule, même si j'essaie. sudo mount -o remount,rw /media/efi. En utilisant mount | grep /media me montre que ça commence comme rw mais est remonté à ro en raison d'erreurs.

Je suppose que ce ReadOnly est également la raison pour laquelle l'installation de Leap a échoué. Est-ce aux erreurs de système de fichiers? J'ai lu que certaines personnes utilisaient chkdsk sur la partition EFI, mais n'expliquaient pas comment. Comment je ferais ça? Ou mieux encore, existe-t-il un moyen de le faire à partir d’un linux liveCD?

Ordinateur portable: MSI 16GF (uniquement fourni avec une partition de récupération, sans support d'installation)
EFI sur disque dur standard
Linux était sur SSD supplémentaire

MODIFIER

J'en ai fatigué fsck avec le -n option de ne pas aggraver encore.

sudo fsck -n /dev/sda2
fsck from util-linux 2.26.2
fsck.fat 3.0.28 (2015-05-16)
0x41 Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
FATs differ but appear to be intact. Using first FAT.
/EFI/opensuse/MokManager.efi
 Contains a free cluster (19138). Assuming EOF.
/EFI/opensuse/MokManager.efi
 File size is 1276328 bytes, cluster chain length is 0 bytes.
 Truncating file to 0 bytes.
/EFI/opensuse/grub.efi
 Contains a free cluster (19450). Assuming EOF.
/EFI/opensuse/grub.efi
 File size is 918392 bytes, cluster chain length is 0 bytes.
 Truncating file to 0 bytes.
Reclaimed 793 unused clusters (3248128 bytes)
Free cluster summary wrong (62265 vs, really 63058)
 Auto-correcting
Leaving filessystem unchanged.
/dev/sda2: 430 files, 12718/75776 clusters

Donc, quelque chose s'est mal passé lors du démontage. Que ce soit moi ou l'installation Leap, cela ne change rien au fait que quelque chose ne va pas.

Dois-je corriger ces erreurs automatiquement?

— mikuszefski
source

Voici la source ultime du problème:

0x41 Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

Il est fort probable que votre installation Windows soit configurée pour utiliser «Démarrage rapide», comme c'est le cas par défaut pour Windows 8 et versions ultérieures. (Notez que ceci est un les fenêtres fonctionnalité. De nombreux EFI ont une fonctionnalité avec un nom similaire, mais elle n’a aucun rapport.) Pour désactiver cette fonctionnalité, vous devez le désactiver, ainsi que la fonctionnalité Hibernate. Beaucoup de pages Web couvrent ces sujets, mais voyez ici pour un couple:

Une fois cette fonctionnalité désactivée et redémarrée plusieurs fois, l'ESP devrait devenir utilisable. Sinon, je vous recommande de le sauvegarder (il est plutôt petit), créez un nouveau système de fichiers FAT dessus (en utilisant mkdosfs sous Linux, par exemple) et restaurez vos fichiers. Ne pas supprimer et recréer la partition entière, cependant; cela modifiera sa valeur GUID, ce qui rendra les entrées de NVRAM pointant vers vos chargeurs de démarrage non valides. Notez également que la recréation du système de fichiers est simplement une solution de contournement pour les dommages causés au système de fichiers. Si les paramètres Windows ne "prennent" pas, le problème se reproduira, et la recréation du système de fichiers ne changera pas cela.

Comme arrière-plan, sachez que le démarrage rapide transforme une opération d'arrêt en une opération de suspension sur disque. Cela convient si le seul système d'exploitation utilisé est Windows, mais si vous effectuez un double amorçage, toutes les partitions partagées, y compris l'ESP, resteront dans un état dangereusement incohérent lors de l'arrêt ou du redémarrage à partir de Windows. La désactivation de cette fonctionnalité ralentit le processus de démarrage, mais sécurise l'accès aux partitions partagées à partir des deux systèmes d'exploitation.

— Rod Smith
source

Bonjour Rod, merci pour les informations détaillées. Je suis au courant du "Fast Startup", qui est déjà désactivé, mais pas du "Hibernate". Je vais éteindre celui-là aussi. Je pensais que c'était gênant au cas où je monterais la partition Windows à partir de Linux. Je ne pensais pas que cela affectait aussi la partition efi.

— mikuszefski

Bonjour Rod, je suis en train de faire plusieurs redémarrages. Dans tous les cas, j'aime bien l'approche proactive de mkdosfs, bien que ce soit plutôt inquiétant. Pour la sauvegarde, est-ce que je copie simplement les fichiers sur la partition ou y at-il quelque chose de spécial à prendre en charge? Après le démontage, serait-il simplement mkfs.vfat -v / dev / sda2? Dans quelle mesure la partition efi est-elle "amorçable" en tant qu'états mkdosfs "mkdosfs ne peut pas créer de systèmes de fichiers amorçables"? (PS: je laisse fsck le réparer. Il ne montre plus les erreurs, mais monte toujours en erreur = remount-ro)

— mikuszefski

Ok .... il est toujours écrit `error = remount-ro` mais je peux supprimer le opensusefolder maintenant. Comme je le disais, je laisse fsck corriger les erreurs, désactiver la veille prolongée et effectuer environ 10 redémarrages. L'un (inclus) ou l'autre l'a fait. Je vais donc marquer la réponse comme correcte. Notez que je me suis toujours demandé pourquoi c'était toujours sda même si le démarrage à partir d'usb? Maintenant, le port USB est sdaet le disque est sdb. Dans tous les cas, j'apprécierais cependant quelques informations concernant mon commentaire ci-dessus. Serait-il bon de faire un dd if=/dev/sda2 of=usbStick/efi.img le remettre tel quel, juste au cas où? À votre santé.

— mikuszefski

Très drôle, chaque fois que j'essaie de comprendre la question mkfs.vfat et "bootable", je ne trouve que des questions auxquelles répond Rod Smith.

— mikuszefski

Le terme "bootable", en référence à FAT, fait presque toujours référence au démarrage en mode BIOS. (Personne n'a pris la peine de préciser cela car les partitions FAT étaient presque toujours amorcées à partir d'ordinateurs basés sur le BIOS jusqu'à la mi-2011, date à laquelle EFI est devenue courante.) EFI démarre différemment et ne nécessite rien de spécial dans le système de fichiers en soi, bien qu'il existe de nombreux décalages EFI. . Une sauvegarde au niveau fichier de l'ESP est adéquate, bien que vous deviez peut-être modifier /etc/fstab après avoir créé un nouveau système de fichiers, faire référence à un nouveau numéro de série ( UUID= dans /etc/fstab ). UNE dd La sauvegarde répliquera les problèmes existants.

— Rod Smith