Manjaro dual-booted with Win10 on separate drives - Manjaro's EFI partition type lists as BitLocker. Will not...












0















system:



Manjaro running on an m.2 nvme drive, Windows 10 running on a separate HDD



Problem:



Over the holidays I seem to have messed up my system pretty badly. I have had a stable system for several months, but I wanted the security features of SecureBoot, so I enabled it in the bios. Ever since my system has been unable to boot into Manjaro, and will only load Win10. I reset the secure boot settings, but the problem remains.



Currently I am able to boot into a live Manjaro disk made using Rufus in dd mode. I have used mhwd-chroot to access my existing install on nvme0n1p2, and can therefore backup my files. I attempted to run grub-install /dev/nvme0n1, and got:



grub-install: error: cannot fine EFI directory.


after poking around, I found that my EFI directory for Manjaro appears to be in nvme0n1p1. So I tried mounting it:



# mount /dev/nvme0n1p1 /boot/efi
mount: /boot/efi: unknown filesystem type 'BitLocker'


Looking at lsblk -f, I can see that that partition is indeed listed as BitLocker (as is /dev/sda3, the windows file system partition). Am I correct in assuming that this looks like Win10 encrypted my EFI partition? What would my next steps for recovery be? Could I use GParted to re-format that partition, then mount it to /boot/efi, then run grub-install?



for additional info, I did try to use a boot recovery tool, but aparently it only does well with Ubuntu distros. regardless, here is a pastebin of its analysis, which may or may not be helpful: http://paste.ubuntu.com/p/PkmfdtxHjq/










share|improve this question



























    0















    system:



    Manjaro running on an m.2 nvme drive, Windows 10 running on a separate HDD



    Problem:



    Over the holidays I seem to have messed up my system pretty badly. I have had a stable system for several months, but I wanted the security features of SecureBoot, so I enabled it in the bios. Ever since my system has been unable to boot into Manjaro, and will only load Win10. I reset the secure boot settings, but the problem remains.



    Currently I am able to boot into a live Manjaro disk made using Rufus in dd mode. I have used mhwd-chroot to access my existing install on nvme0n1p2, and can therefore backup my files. I attempted to run grub-install /dev/nvme0n1, and got:



    grub-install: error: cannot fine EFI directory.


    after poking around, I found that my EFI directory for Manjaro appears to be in nvme0n1p1. So I tried mounting it:



    # mount /dev/nvme0n1p1 /boot/efi
    mount: /boot/efi: unknown filesystem type 'BitLocker'


    Looking at lsblk -f, I can see that that partition is indeed listed as BitLocker (as is /dev/sda3, the windows file system partition). Am I correct in assuming that this looks like Win10 encrypted my EFI partition? What would my next steps for recovery be? Could I use GParted to re-format that partition, then mount it to /boot/efi, then run grub-install?



    for additional info, I did try to use a boot recovery tool, but aparently it only does well with Ubuntu distros. regardless, here is a pastebin of its analysis, which may or may not be helpful: http://paste.ubuntu.com/p/PkmfdtxHjq/










    share|improve this question

























      0












      0








      0








      system:



      Manjaro running on an m.2 nvme drive, Windows 10 running on a separate HDD



      Problem:



      Over the holidays I seem to have messed up my system pretty badly. I have had a stable system for several months, but I wanted the security features of SecureBoot, so I enabled it in the bios. Ever since my system has been unable to boot into Manjaro, and will only load Win10. I reset the secure boot settings, but the problem remains.



      Currently I am able to boot into a live Manjaro disk made using Rufus in dd mode. I have used mhwd-chroot to access my existing install on nvme0n1p2, and can therefore backup my files. I attempted to run grub-install /dev/nvme0n1, and got:



      grub-install: error: cannot fine EFI directory.


      after poking around, I found that my EFI directory for Manjaro appears to be in nvme0n1p1. So I tried mounting it:



      # mount /dev/nvme0n1p1 /boot/efi
      mount: /boot/efi: unknown filesystem type 'BitLocker'


      Looking at lsblk -f, I can see that that partition is indeed listed as BitLocker (as is /dev/sda3, the windows file system partition). Am I correct in assuming that this looks like Win10 encrypted my EFI partition? What would my next steps for recovery be? Could I use GParted to re-format that partition, then mount it to /boot/efi, then run grub-install?



      for additional info, I did try to use a boot recovery tool, but aparently it only does well with Ubuntu distros. regardless, here is a pastebin of its analysis, which may or may not be helpful: http://paste.ubuntu.com/p/PkmfdtxHjq/










      share|improve this question














      system:



      Manjaro running on an m.2 nvme drive, Windows 10 running on a separate HDD



      Problem:



      Over the holidays I seem to have messed up my system pretty badly. I have had a stable system for several months, but I wanted the security features of SecureBoot, so I enabled it in the bios. Ever since my system has been unable to boot into Manjaro, and will only load Win10. I reset the secure boot settings, but the problem remains.



      Currently I am able to boot into a live Manjaro disk made using Rufus in dd mode. I have used mhwd-chroot to access my existing install on nvme0n1p2, and can therefore backup my files. I attempted to run grub-install /dev/nvme0n1, and got:



      grub-install: error: cannot fine EFI directory.


      after poking around, I found that my EFI directory for Manjaro appears to be in nvme0n1p1. So I tried mounting it:



      # mount /dev/nvme0n1p1 /boot/efi
      mount: /boot/efi: unknown filesystem type 'BitLocker'


      Looking at lsblk -f, I can see that that partition is indeed listed as BitLocker (as is /dev/sda3, the windows file system partition). Am I correct in assuming that this looks like Win10 encrypted my EFI partition? What would my next steps for recovery be? Could I use GParted to re-format that partition, then mount it to /boot/efi, then run grub-install?



      for additional info, I did try to use a boot recovery tool, but aparently it only does well with Ubuntu distros. regardless, here is a pastebin of its analysis, which may or may not be helpful: http://paste.ubuntu.com/p/PkmfdtxHjq/







      linux multi-boot grub bitlocker manjaro






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 6 at 20:17









      jumanjicostcojumanjicostco

      1




      1






















          1 Answer
          1






          active

          oldest

          votes


















          0














          So after much pain and suffering, I have resolved my issues. I think my instincts before were correct - somehow the action of turning on secure boot and then booting into windows encrypted my linux EFI partition nvme0n1p1. I would likely have been fine going with my instincts and wiping that partition, but since it was only 300MiB, it wasn't worth the space, so just in case I created a new partition. Here's the steps I took to resolve this issue:




          1. Boot into a Manjaro live usb

          2. Run GParted

          3. Create a new 300MiB partition between the BitLocker'd nvme0n1p1 and my filesystem running on nvme0n1p2 by shrinking nvme0n1p2 from the left. New partition should be fat32

          4. Apply changes in GParted

          5. Apply the boot and esp flags to the new partition (nvme0n1p4) via GParted

          6. Us mhwd-chroot-shell to chroot into your system (nvme0n1p2)

          7. Change /etc/fstab to use the new partition instead of the old one.

          8. Update GRUB


          updating grub:



          $ sudo su
          # grub-install /dev/nvme0n1
          # update-grub


          fstab changes:



          - UUID=319a7d84-9d20-4f5f87f3-10948da50d73  /boot/efi   /dev/nvme0n1p4: PARTUUID=   defaults    0   1
          + UUID=C410-9DC8 /boot/efi vfat defaults 0 2


          I'm not sure why the original line there had a different format. Originally my new line followed the same format, but that would not boot either. After some more reading I seemed clear that it should have a 2, not a 1 at the end, and the extra details didn't belong.



          At this point in the process I restarted my machine without the live usb plugged in, thinking I had figured it out, but the same issue was still present. So a few more steps were needed:




          1. Reboot with live usb plugged in until you get to the Live Usb's boot loader menu. Towards the bottom there is an option to 'Detect EFI Bootloader'.

          2. Select the bootloader for your device. In my case, (hd1,4)

          3. At this point my original GRUB loaded, and I was able to log into my system. Once in, I updated grub again (same commands as before). I am now able to boot into my system as normal! No Live USB Required!


          This is all new to me, as I've never had this sort of issue before. Hopefully someone else out there can use this information.



          A final note on mhwd-chroot-shell: I ran into some trouble with it, as it would not detect the /etc/ directory in my nvme0n1p2 partition, so it did not recognize any linux systems. To get around this, I ended up tweaking the shell script. Just before it would throw the error of "No Linux Systems found!", I added a check to manually inject my partition into it if it failed to detect any:



          if [ $nbpart -eq 0 ]; then
          list[$nbpart]=/dev/nvme0n1p2
          ((nbpart++))
          fi





          share|improve this answer























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "3"
            };
            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',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1391251%2fmanjaro-dual-booted-with-win10-on-separate-drives-manjaros-efi-partition-type%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            So after much pain and suffering, I have resolved my issues. I think my instincts before were correct - somehow the action of turning on secure boot and then booting into windows encrypted my linux EFI partition nvme0n1p1. I would likely have been fine going with my instincts and wiping that partition, but since it was only 300MiB, it wasn't worth the space, so just in case I created a new partition. Here's the steps I took to resolve this issue:




            1. Boot into a Manjaro live usb

            2. Run GParted

            3. Create a new 300MiB partition between the BitLocker'd nvme0n1p1 and my filesystem running on nvme0n1p2 by shrinking nvme0n1p2 from the left. New partition should be fat32

            4. Apply changes in GParted

            5. Apply the boot and esp flags to the new partition (nvme0n1p4) via GParted

            6. Us mhwd-chroot-shell to chroot into your system (nvme0n1p2)

            7. Change /etc/fstab to use the new partition instead of the old one.

            8. Update GRUB


            updating grub:



            $ sudo su
            # grub-install /dev/nvme0n1
            # update-grub


            fstab changes:



            - UUID=319a7d84-9d20-4f5f87f3-10948da50d73  /boot/efi   /dev/nvme0n1p4: PARTUUID=   defaults    0   1
            + UUID=C410-9DC8 /boot/efi vfat defaults 0 2


            I'm not sure why the original line there had a different format. Originally my new line followed the same format, but that would not boot either. After some more reading I seemed clear that it should have a 2, not a 1 at the end, and the extra details didn't belong.



            At this point in the process I restarted my machine without the live usb plugged in, thinking I had figured it out, but the same issue was still present. So a few more steps were needed:




            1. Reboot with live usb plugged in until you get to the Live Usb's boot loader menu. Towards the bottom there is an option to 'Detect EFI Bootloader'.

            2. Select the bootloader for your device. In my case, (hd1,4)

            3. At this point my original GRUB loaded, and I was able to log into my system. Once in, I updated grub again (same commands as before). I am now able to boot into my system as normal! No Live USB Required!


            This is all new to me, as I've never had this sort of issue before. Hopefully someone else out there can use this information.



            A final note on mhwd-chroot-shell: I ran into some trouble with it, as it would not detect the /etc/ directory in my nvme0n1p2 partition, so it did not recognize any linux systems. To get around this, I ended up tweaking the shell script. Just before it would throw the error of "No Linux Systems found!", I added a check to manually inject my partition into it if it failed to detect any:



            if [ $nbpart -eq 0 ]; then
            list[$nbpart]=/dev/nvme0n1p2
            ((nbpart++))
            fi





            share|improve this answer




























              0














              So after much pain and suffering, I have resolved my issues. I think my instincts before were correct - somehow the action of turning on secure boot and then booting into windows encrypted my linux EFI partition nvme0n1p1. I would likely have been fine going with my instincts and wiping that partition, but since it was only 300MiB, it wasn't worth the space, so just in case I created a new partition. Here's the steps I took to resolve this issue:




              1. Boot into a Manjaro live usb

              2. Run GParted

              3. Create a new 300MiB partition between the BitLocker'd nvme0n1p1 and my filesystem running on nvme0n1p2 by shrinking nvme0n1p2 from the left. New partition should be fat32

              4. Apply changes in GParted

              5. Apply the boot and esp flags to the new partition (nvme0n1p4) via GParted

              6. Us mhwd-chroot-shell to chroot into your system (nvme0n1p2)

              7. Change /etc/fstab to use the new partition instead of the old one.

              8. Update GRUB


              updating grub:



              $ sudo su
              # grub-install /dev/nvme0n1
              # update-grub


              fstab changes:



              - UUID=319a7d84-9d20-4f5f87f3-10948da50d73  /boot/efi   /dev/nvme0n1p4: PARTUUID=   defaults    0   1
              + UUID=C410-9DC8 /boot/efi vfat defaults 0 2


              I'm not sure why the original line there had a different format. Originally my new line followed the same format, but that would not boot either. After some more reading I seemed clear that it should have a 2, not a 1 at the end, and the extra details didn't belong.



              At this point in the process I restarted my machine without the live usb plugged in, thinking I had figured it out, but the same issue was still present. So a few more steps were needed:




              1. Reboot with live usb plugged in until you get to the Live Usb's boot loader menu. Towards the bottom there is an option to 'Detect EFI Bootloader'.

              2. Select the bootloader for your device. In my case, (hd1,4)

              3. At this point my original GRUB loaded, and I was able to log into my system. Once in, I updated grub again (same commands as before). I am now able to boot into my system as normal! No Live USB Required!


              This is all new to me, as I've never had this sort of issue before. Hopefully someone else out there can use this information.



              A final note on mhwd-chroot-shell: I ran into some trouble with it, as it would not detect the /etc/ directory in my nvme0n1p2 partition, so it did not recognize any linux systems. To get around this, I ended up tweaking the shell script. Just before it would throw the error of "No Linux Systems found!", I added a check to manually inject my partition into it if it failed to detect any:



              if [ $nbpart -eq 0 ]; then
              list[$nbpart]=/dev/nvme0n1p2
              ((nbpart++))
              fi





              share|improve this answer


























                0












                0








                0







                So after much pain and suffering, I have resolved my issues. I think my instincts before were correct - somehow the action of turning on secure boot and then booting into windows encrypted my linux EFI partition nvme0n1p1. I would likely have been fine going with my instincts and wiping that partition, but since it was only 300MiB, it wasn't worth the space, so just in case I created a new partition. Here's the steps I took to resolve this issue:




                1. Boot into a Manjaro live usb

                2. Run GParted

                3. Create a new 300MiB partition between the BitLocker'd nvme0n1p1 and my filesystem running on nvme0n1p2 by shrinking nvme0n1p2 from the left. New partition should be fat32

                4. Apply changes in GParted

                5. Apply the boot and esp flags to the new partition (nvme0n1p4) via GParted

                6. Us mhwd-chroot-shell to chroot into your system (nvme0n1p2)

                7. Change /etc/fstab to use the new partition instead of the old one.

                8. Update GRUB


                updating grub:



                $ sudo su
                # grub-install /dev/nvme0n1
                # update-grub


                fstab changes:



                - UUID=319a7d84-9d20-4f5f87f3-10948da50d73  /boot/efi   /dev/nvme0n1p4: PARTUUID=   defaults    0   1
                + UUID=C410-9DC8 /boot/efi vfat defaults 0 2


                I'm not sure why the original line there had a different format. Originally my new line followed the same format, but that would not boot either. After some more reading I seemed clear that it should have a 2, not a 1 at the end, and the extra details didn't belong.



                At this point in the process I restarted my machine without the live usb plugged in, thinking I had figured it out, but the same issue was still present. So a few more steps were needed:




                1. Reboot with live usb plugged in until you get to the Live Usb's boot loader menu. Towards the bottom there is an option to 'Detect EFI Bootloader'.

                2. Select the bootloader for your device. In my case, (hd1,4)

                3. At this point my original GRUB loaded, and I was able to log into my system. Once in, I updated grub again (same commands as before). I am now able to boot into my system as normal! No Live USB Required!


                This is all new to me, as I've never had this sort of issue before. Hopefully someone else out there can use this information.



                A final note on mhwd-chroot-shell: I ran into some trouble with it, as it would not detect the /etc/ directory in my nvme0n1p2 partition, so it did not recognize any linux systems. To get around this, I ended up tweaking the shell script. Just before it would throw the error of "No Linux Systems found!", I added a check to manually inject my partition into it if it failed to detect any:



                if [ $nbpart -eq 0 ]; then
                list[$nbpart]=/dev/nvme0n1p2
                ((nbpart++))
                fi





                share|improve this answer













                So after much pain and suffering, I have resolved my issues. I think my instincts before were correct - somehow the action of turning on secure boot and then booting into windows encrypted my linux EFI partition nvme0n1p1. I would likely have been fine going with my instincts and wiping that partition, but since it was only 300MiB, it wasn't worth the space, so just in case I created a new partition. Here's the steps I took to resolve this issue:




                1. Boot into a Manjaro live usb

                2. Run GParted

                3. Create a new 300MiB partition between the BitLocker'd nvme0n1p1 and my filesystem running on nvme0n1p2 by shrinking nvme0n1p2 from the left. New partition should be fat32

                4. Apply changes in GParted

                5. Apply the boot and esp flags to the new partition (nvme0n1p4) via GParted

                6. Us mhwd-chroot-shell to chroot into your system (nvme0n1p2)

                7. Change /etc/fstab to use the new partition instead of the old one.

                8. Update GRUB


                updating grub:



                $ sudo su
                # grub-install /dev/nvme0n1
                # update-grub


                fstab changes:



                - UUID=319a7d84-9d20-4f5f87f3-10948da50d73  /boot/efi   /dev/nvme0n1p4: PARTUUID=   defaults    0   1
                + UUID=C410-9DC8 /boot/efi vfat defaults 0 2


                I'm not sure why the original line there had a different format. Originally my new line followed the same format, but that would not boot either. After some more reading I seemed clear that it should have a 2, not a 1 at the end, and the extra details didn't belong.



                At this point in the process I restarted my machine without the live usb plugged in, thinking I had figured it out, but the same issue was still present. So a few more steps were needed:




                1. Reboot with live usb plugged in until you get to the Live Usb's boot loader menu. Towards the bottom there is an option to 'Detect EFI Bootloader'.

                2. Select the bootloader for your device. In my case, (hd1,4)

                3. At this point my original GRUB loaded, and I was able to log into my system. Once in, I updated grub again (same commands as before). I am now able to boot into my system as normal! No Live USB Required!


                This is all new to me, as I've never had this sort of issue before. Hopefully someone else out there can use this information.



                A final note on mhwd-chroot-shell: I ran into some trouble with it, as it would not detect the /etc/ directory in my nvme0n1p2 partition, so it did not recognize any linux systems. To get around this, I ended up tweaking the shell script. Just before it would throw the error of "No Linux Systems found!", I added a check to manually inject my partition into it if it failed to detect any:



                if [ $nbpart -eq 0 ]; then
                list[$nbpart]=/dev/nvme0n1p2
                ((nbpart++))
                fi






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jan 7 at 2:35









                jumanjicostcojumanjicostco

                1




                1






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Super User!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1391251%2fmanjaro-dual-booted-with-win10-on-separate-drives-manjaros-efi-partition-type%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                    Mangá

                    Eduardo VII do Reino Unido