[SOLVED] Dual Booting with GRUB doesn't work

GRUB will never overwrite anything on the EFI system partition and certainly not the Microsoft folder.

The ESP must have been formatted at some stage.

Does the ArchLabs installer keep a log? (I’ve never used it.)

EDIT: you should be backing up the contents of the ESP anyway, then you wouldn’t have to keep reinstalling.

1 Like

Create an additional EFI partition the usual way and instead of selecting the EFI partition created by Windows, use this one. After installing run the usual grub command to write its config, windows should be found at this point.

The installer can be run with -d/--debug to have pretty much everything logged to /tmp/debug-log by default output of stderr is logged to /tmp/errlog

If there is a Microsoft folder present on the partition then its obvious it was never formatted. To the best of my knowledge windows doesn’t even store the actual bootloader on the partition though this may have changed.

1 Like

It is likely that this is being overwritten.

To stop this from happening open the installer located at /installer/installer navigate to line 1946 and comment the line containing grub_uefi_fallback

Ah yes, of course, I missed that bit.

The Windows UEFI loader is stored on the ESP at EFI/Microsoft/Boot/bootmgfw.efi

This is confusing to me. In theory I agree with what you say, @anon42040838, but how is it that OP and me both had the same issue - which is a missing bootmgfw.efi without actually formatting the efi partition? If what you say is correct and grub never overwrites anything… then… how?

My mistake, I could’ve sworn I’ve read it somewhere but probably just got some wires crossed

From what I can gather it seems that Windows is using EFI/Boot/bootx64.efi as a catch all of sorts, this wasn’t the case before and I may still be wrong.

During install this file is being overwritten with grub’s efi stub (by us), without it many computers will simply say “No bootable device”. I’ve outlined a solution in a previous post above.

Will get this fixed, but need to find a decent solution first.

Yes that is correct @natemaia EFI/Boot/bootx64.efi in most cases. But on some machines it may have a different directory setup:

G:\EFI\Microsoft\Boot
G:\Boot\ or
G:\ESD\Windows\EFI\Microsoft\Boot`

Mine happens to be G:\EFI\Microsoft\Boot\

This is something I am hoping that will give @MuradTroll would look at to help him:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=2ahUKEwipmezf5e3cAhVQ71QKHaijAfUQFjACegQIBhAK&url=http%3A%2F%2Ftech.memoryimprintstudio.com%2Fdual-boot-installation-of-arch-linux-with-preinstalled-windows-10-with-encryption%2F&usg=AOvVaw1CngRvDVCEsslrAG19hfP-

1 Like

Ok good to know that about the boot setup

The link is a dead redirect

Redirect Notice

The page you were on is trying to send you to an invalid URL.

If you do not want to visit that page, you can return to the previous page.

To shorten links using markdown the format is

[Label](Link)

eg. [Google](http://google.com)

How it looks outside of a code block: Google

This way people can just click the highlighted text rather than needing to copy/paste massive links :slight_smile:

1 Like

Finally the message restriction is gone. I would like to thank you al for helping me out and giving active support. Furthermore I would like to announce, that I managed to solve the problem. In this post, I will deeply explain what I did and tried to fix it. I did try to install archlabs yet again, and in the live environment I did the following things

  • I ran sudo os-prober and it indeed found the Windows Bootloader on sda2
  • I mounted and explored the EFI partition (sda2) and found all files clear, as they were supposed to be. The folder structure looked similar to this

_EFI
__Microsoft
___Boot
___Recovery
__Boot

  • I tried to comment out the line that executes grub_uefi_fallback()

#[[ $SYS == “UEFI” && $BOOTLOADER == “grub” ]] && grub_uefi_fallback

  • I opened filemanager to see with my own eyes what is happening to the EFI partition
  • last but not least, I inspected the install script yet again just for myself to get a grasp of what is happening before running the installer

Then I ran the installer and everything went fine, up to the point where grub was installed, I noticed my filemanager refreshed immediately and the bootloader was gone. But then I realized something very important: the new files structure was specific

_EFI
__Microsoft
___Recovery
__archlabs

When you comapre that with the filestructure before, you will realize that 2 folders are missing, specifically those called Boot. Because I inspected the installer script beforehand, I immediately knew what the problem was. This line:

find $MNT/boot/efi/EFI/ -name '[Bb][oO][oO][tT]' \
-type d -exec rm -rf '{}' \; 2>/dev/null

is actively deleting all folders in the partition called ‘Boot’ (and with all I mean all, even in the Microsoft folder). Now I installed Windows yet again, booted into arch-live again, commented both lines out (this one and the one that calls grub_uefi_fallback()) and ran the installer again. No bootloader was deleted, and I had both OSes ready to run.

So in the end all of us were right, neither I, nor GRUB were deleting any of the entries in the EFI partition, but archlabs installer was.

The problem is that this command is trying to delete preexisting (old) boot entries in the EFI partition (probably created by older versions of archlabs), but with ‘find’, it does a full search for a directory called ‘Boot’ in all subdirectories (-> it touched the Microsoft folder). I don’t know if the first ‘Boot’ folder (the one that is not in the Microsoft folder) can be touched/deleted. But for sure, the Microsoft folder (and specifically the Boot folder inside it) should NOT be touched at all. I would suggest adding something like

-mindepth 1 -maxdepth 1

to prevent this from happening in future installs.
At this point I am also not sure if commenting out the grub_uefi_fallback() was really necessary, but it seems like this function is trying to delete some files too, so I commented it out just to be sure.

At the end I want to thank you all yet again and point out, that this is literally my

  • first bug that I fixed in an open source project
  • first time I had real code experience with a linux environment (talking about shell code)

and it was really a valuable experience.

4 Likes

@MuradTroll , thx for the great explanations there mate , will be great for other future uses.

2 Likes

@MuradTroll Great stuff.

Big mistake there on my part not using a -maxdepth 1 flag with the find, very dense of me to miss this as a probable cause so I apologize.

Cheers

Top notch sir.

I actually wanna thank you and say I’m thoroughly impressed with the excellent breakdown, understanding of Unix cli tools, and willingness to get you hands dirty understanding the installer.

More often than not people are unwilling to help themselves (whether right or not) so this was a breath of fresh air.

Cheers

1 Like

Excellent, and hopefully solved for others with the same issue. :grin:

1 Like

One thing that still bugs me, just out of sheer curiosity, is it valid if the first ‘Boot’ folder gets deleted (obviously not the one inside the Microsoft folder, but the one next to it)? Or will this likely cause the same problem? Same thing for grub_uefi_fallback(): will it break if called during install? Many questions still unanswered but for now I think I have experimented enough :joy:

Really depends on your bios and motherboard manufacturer whether having a generic EFI/Boot/Bootx64.efi is really needed. The problem was indeed the boot folder within Microsoft’s efi folder being deleted, I don’t think the others will cause any issues.

It would also depend on which OS’s bootloader you want as the dominant

I would not mess with any folders in your EFI partition ie. your boot folders unless you know what you’re doing. But I would suggest that you make a copy of that partition and save somewhere safe in case you have problems with your installations and you wouldn’t have to keep reinstalling your OSs again and again and again…:grin:

Just as a sidenote: you do NOT have to do that, recovery medium and one simple command is enough to restore win bootloader. Not a single reinstall neccessary.

That being said, @MuradTroll, congratulations on actually solving the issue!

That’s true, but it doesn’t work for the linux side. But, still a good call. Pease

1 Like

Sorry @xsme, somehow I edited your post event hough I had hit reply. but my reply was:
That’s true, but it doesn’t work for the linux side. But, still a good call. Pease
I’ll let you fix your post, don’t want to try and mess it up more.:open_mouth:

Thanks man i’ll give it a try for this solution … since my problem quite the same as yours.
*Updated
Confirmed its worked on me too. Latest iso ( 2018.07.28 ) on my asus laptop with uefi system, dual boot with windows 10.
Before that i desperately frustated :slight_smile: with this grub2 problem. I even had to reinstall windows twice along with archlabs.
And in my case, after successfull archlabs setup ( of course with those tricks you have been wrote ) i had to reboot but still no windows on grub so i enter newly created archlabs then manualy ran os-prober and grub-mkconfig. I was trully happy with the end result, grub finally see my windows efi partition.
Excelent job … Very much appreciated :+1:

1 Like