Un ami a un système sur lequel j'ai récemment installé Manjaro Linux en double amorçage avec Windows 10, en utilisant le schéma de partitionnement à double amorçage par défaut du programme d'installation.
Hier, Windows a décidé de se mettre à jour (la tristement célèbre Creator's Update, je suppose ), et Manjaro ne démarrerait pas.
J'ai demandé à l'ami de se connecter à partir d'un liveUSB et c'est le sudo fdisk -l sortie :
Disk /dev/nvme0n1: 238,5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: DBCB2883-9E10-40F3-8007-B1B409A79DF5
Dispositivo Start Fine Settori Size Tipo
/dev/nvme0n1p1 2048 206847 204800 100M EFI System
/dev/nvme0n1p2 206848 239615 32768 16M Microsoft reserved
/dev/nvme0n1p3 239616 123472110 123232495 58,8G Microsoft basic data
/dev/nvme0n1p4 497999872 500097023 2097152 1G Windows recovery environment
/dev/nvme0n1p5 123472112 497999871 374527760 178,6G Linux filesystem
Partition table entries are not in disk order.
Notez que les Partition table entries are not in disk order. :apparemment, il y a maintenant une partition (/dev/nvme0n1p4 ) qui est physiquement après le Linux principal (/dev/nvme0n1p5 ), mais numériquement avant. Comme cela semble assez non standard, je suppose que Windows a foiré avec la table de partition.
Après avoir fait un :
sudo mount /dev/nvme0n1p5 /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
sudo grub-install --target=x86_64-efi --efi-directory=/mnt/boot/efi --bootloader-id=manjaro --boot-directory=/mnt/boot --recheck --debug
Le système redémarre et semble fonctionner normalement.
La question est :
comment Windows pourrait-il jouer avec la table de partition, mais sans rien corrompre, étant donné qu'il n'a pas de ext4 connaissance que je connaisse ? A-t-il simplement modifié l'ordre de partition "numérique" ? Qu'a-t-il fait exactement ?
Réponse acceptée :
Il y a de fortes chances qu'il n'ait rien fait aux partitions, mais il a simplement réécrit le démarrage EFI pour (essayer de) se faire le seul système d'exploitation/par défaut. Puisque bien sûr, vous savez, une fois que vous avez Windows 10 sur le disque, pourquoi auriez-vous besoin d'autre chose ?
Vos problèmes me sont également arrivés deux ou trois fois, sur des machines différentes, après des mises à jour, et ils ont toujours disparu avec une simple mise à jour ou réinstallation de GRUB2.
Je ne pense pas que renuméroter les partitions puisse faire quelque chose de vraiment mauvais; s'ils ne gâchent pas Windows, je suis sûr qu'ils ne gâcheront pas GRUB/GRUB2.
Cependant, assurez-vous d'exécuter un e2fsck sur la partition Linux pour vous assurer qu'elle n'a pas été raccourcie d'un gigaoctet. Si le FS à l'intérieur est étiqueté comme plus grand que la partition où il devrait être contenu, car cette dernière a été redimensionnée aveuglément (Windows a une connaissance suffisante des partitions pour faire cela ), vous pourriez rencontrer des problèmes lorsque Linux écrase les données de récupération ou que Windows les "met à jour" et écrase tout ce que Linux ext4 a décidé d'y mettre. Vous devrez peut-être :
- sauvegarder les données de 1 Go dans un fichier Linux,
- supprimez la partition et réinitialisez la partition Linux à sa taille maximale,
- réduire le système de fichiers pour laisser 1 Go libre,
- recréer la partition,
- restaurer la sauvegarde
pour s'adapter aux deux systèmes d'exploitation et les maintenir en bons termes.