[SOLVED] Dual Booting with GRUB doesn't work

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

I was wondering if this problem is solved in the new version of archlabs or do I have to edit the installer again to have dual boot with Windows. Does anybody know?

This issue has been resolved.