How could Windows NOT corrupt the Linux file-system when messing up partition schemes

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












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?







share|improve this question
























    up vote
    2
    down vote

    favorite












    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?







    share|improve this question






















      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      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?







      share|improve this question












      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?









      share|improve this question











      share|improve this question




      share|improve this question










      asked Dec 25 '17 at 17:29









      AF7

      439313




      439313




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          3
          down vote













          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.






          share|improve this answer




















          • 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
            Dec 25 '17 at 19:18







          • 1




            I'd say that yes, it's likely. But check filesystem size on the ext4 partition just in case.
            – LSerni
            Dec 27 '17 at 11:37










          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );








           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f412990%2fhow-could-windows-not-corrupt-the-linux-file-system-when-messing-up-partition-sc%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          3
          down vote













          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.






          share|improve this answer




















          • 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
            Dec 25 '17 at 19:18







          • 1




            I'd say that yes, it's likely. But check filesystem size on the ext4 partition just in case.
            – LSerni
            Dec 27 '17 at 11:37














          up vote
          3
          down vote













          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.






          share|improve this answer




















          • 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
            Dec 25 '17 at 19:18







          • 1




            I'd say that yes, it's likely. But check filesystem size on the ext4 partition just in case.
            – LSerni
            Dec 27 '17 at 11:37












          up vote
          3
          down vote










          up vote
          3
          down vote









          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.






          share|improve this answer












          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Dec 25 '17 at 18:31









          LSerni

          2,326615




          2,326615











          • 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
            Dec 25 '17 at 19:18







          • 1




            I'd say that yes, it's likely. But check filesystem size on the ext4 partition just in case.
            – LSerni
            Dec 27 '17 at 11:37
















          • 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
            Dec 25 '17 at 19:18







          • 1




            I'd say that yes, it's likely. But check filesystem size on the ext4 partition just in case.
            – LSerni
            Dec 27 '17 at 11:37















          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
          Dec 25 '17 at 19:18





          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
          Dec 25 '17 at 19:18





          1




          1




          I'd say that yes, it's likely. But check filesystem size on the ext4 partition just in case.
          – LSerni
          Dec 27 '17 at 11:37




          I'd say that yes, it's likely. But check filesystem size on the ext4 partition just in case.
          – LSerni
          Dec 27 '17 at 11:37












           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f412990%2fhow-could-windows-not-corrupt-the-linux-file-system-when-messing-up-partition-sc%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          Peggy Mitchell

          Palaiologos

          The Forum (Inglewood, California)