Windows – Wie konnte Windows das Linux-Dateisystem nicht beschädigen, wenn Partitionsschemata durcheinander gebracht werden?

Ein Freund hat ein System, auf dem ich kürzlich Manjaro Linux im Dual-Boot mit Windows 10 installiert habe, wobei ich das standardmäßige Dual-Boot-Partitionierungsschema des Installationsprogramms verwendet habe.
Gestern hat Windows beschlossen, sich selbst zu aktualisieren (das berüchtigte Creator's Update, schätze ich ), und Manjaro bootete nicht.
Ich habe den Freund angewiesen, sich von einem Live-USB-Gerät anzumelden, und das ist sudo fdisk -l Ausgabe:

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.

Beachten Sie, dass die Partition table entries are not in disk order.
:Anscheinend gibt es jetzt eine Partition (/dev/nvme0n1p4 ), die physisch hinter der Linux-Hauptdatei liegt (/dev/nvme0n1p5 ), aber numerisch vor. Da dies ziemlich ungewöhnlich aussieht, schätze ich, dass Windows die Partitionstabelle vermasselt hat.

Nach dem Ausführen von:

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

Das System startet neu und scheint normal zu funktionieren.

Die Frage ist:

wie könnte Windows mit der Partitionstabelle herumspielen, ohne etwas zu beschädigen, da es kein ext4 hat Wissen, von dem ich weiß? Hat es nur die „numerische“ Partitionsreihenfolge geändert? Was genau hat es getan?

Akzeptierte Antwort:

Die Chancen stehen gut, dass es nichts mit den Partitionen gemacht hat, aber es hat einfach den EFI-Boot neu geschrieben, um sich selbst zum einzigen / Standard-Betriebssystem zu machen (zu versuchen). Denn natürlich wissen Sie, warum Sie noch etwas brauchen, wenn Sie Windows 10 auf der Festplatte haben?

Ihre Probleme sind mir auch zwei- oder dreimal passiert, auf verschiedenen Rechnern, nach Updates, und sie sind immer mit einem einfachen Update oder einer Neuinstallation von GRUB2 verschwunden.

Ich glaube nicht, dass die Neunummerierung der Partitionen etwas wirklich Schlimmes bewirken kann; Wenn sie sich nicht mit Windows anlegen, bin ich mir ziemlich sicher, dass sie sich nicht mit GRUB/GRUB2 anlegen werden.

Stellen Sie jedoch sicher, dass Sie ein e2fsck auf der Linux-Partition ausführen, um sicherzustellen, dass es nicht um ein Gigabyte gekürzt wurde. Wenn das darin enthaltene FS als größer gekennzeichnet ist als die Partition, in der es enthalten sein sollte, weil die Größe der letzteren blind geändert wurde (Windows hat genug Wissen über Partitionen, um das zu tun ), könnten Sie in Schwierigkeiten geraten, wenn entweder Linux die Wiederherstellungsdaten überschreibt oder Windows sie „aktualisiert“ und überschreibt, was Linux ext4 dort abgelegt hat. Möglicherweise müssen Sie:

• Sichern Sie die 1-GB-Daten in einer Linux-Datei,
• entfernen Sie die Partition und setzen Sie die Linux-Partition auf volle Größe zurück,
• Verkleinern Sie das Dateisystem, um 1 GB frei zu lassen,
• Partition neu erstellen
• Sicherung wiederherstellen

Verwandte:Linux – Wie verwende ich den Passwortschutz mit dem Linux-Tar-Befehl?

um beide Betriebssysteme unterzubringen und auf freundschaftlichen Bedingungen zu halten.