3

A friend has a system on which I recently installed Manjaro Linux in dual boot with Windows 10, using the default dual-boot partitioning scheme from the installer. Yesterday, Windows decided to update itself (the infamous Creator's Update, I guess), and Manjaro would not boot. I instructed the friend to login from a liveUSB and this is the sudo fdisk -l output:

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.

Note the Partition table entries are not in disk order. : apparently, there is now a partition (/dev/nvme0n1p4) which is physically after the main Linux one (/dev/nvme0n1p5), but numerically before. Since this looks pretty non-standard, I guess Windows messed up with the partition table.

After doing a:

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

The system starts again and seems to be functioning normally.

The question is:

how could Windows mess with the partition table, however without corrupting anything, given that it does not have any ext4 knowledge that I know of? Did it just alter the "numerical" partition order? What exactly did it do?

Improve this question

1 Answer 1

Reset to default
4

Chances are that it did nothing to the partitions, but it simply rewrote the EFI boot to (try to) make itself the only/default OS. Since of course, you know, once you've Windows 10 on the disk, why would you need anything else?

Your problems happened to me too two or three times, on different machines, after updates, and they always went away with a simple update or reinstall of GRUB2.

I do not think that renumbering the partitions can do anything really bad; if they don't mess up with Windows, I'm pretty solid that they won't mess with GRUB/GRUB2.

However, be sure to run a e2fsck on the Linux partition to ensure it hasn't been shortened by one gigabyte. If the FS inside is tagged as larger that the partition where it should be contained, because the latter has been resized blindly (Windows has enough knowledge of partitions to do that), you might run into trouble when either Linux overwrites the recovery data, or Windows "updates" it and writes over whatever Linux ext4 decided to put there. You might need to:

  • backup the 1GB data into a Linux file,
  • remove the partition and reset the Linux partition to full size,
  • shrink the filesystem to leave 1GB free,
  • recreate the partition,
  • restore the backup

to accommodate both OSes and keep them on friendly terms.

Improve this answer
2
  • So it is likely that Windows, other than messing with the bootloader, just re-numbered the partitions to something that it liked more? Maybe it just defaults to #(WINRE) = #(WIN) + 1, and renumbered the partitions accordingly?
    – AF7
    Commented Dec 25, 2017 at 19:18
  • 1
    I'd say that yes, it's likely. But check filesystem size on the ext4 partition just in case.
    – LSerni
    Commented Dec 27, 2017 at 11:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .