Improving the Manjaro installer for dual-booting with Windows 10 and UEFI

[Delgan]

Hi.

I'm encountering difficulties on dual-booting Manjaro with Windows 10 on my computer.

I'm not specifically asking for help. I'm quite confident I will eventually manage to install and enjoy Manjaro by keeping reading, learning and testing stuff (I'm aware of the dual-boot guide).

Rather, I'm asking: what can be done to improve the installer and hopefully fix this for everyone?

My problem is easily reproducible, and as my computer is new, I can investigate and break stuff without fearing entirely messing up my system. So, I think this is probably a good opportunity to understand what's going wrong with the installation process.
Basically, any Manjaro developer can ask me system information or to run commands if this can help him investigate the issue to fix it upstream.
I can fix my system installation by myself, but I can't fix the Manjaro installer. I will update this thread once the solution found, but newbies like me may still struggle with dual-boot in the future if this is not fixed within the installer itself.

---

Context and system information:

• Laptop Acer Swift 1 (SF114-32)
• 64 GB eMMC where Windows 10 is natively installed
• I extended the computer with a 128 GB SSD where I wish to install a Linux distrib
• Acer BIOS driver: v1.07

The bug:
After creating a Live USB with Manjaro and installed it to my SSD, I can no longer access to the BIOS / UEFI. While starting the computer, I usually press F2 to access BIOS and configure computer or select booting device. Once Manjaro is installed, pressing F2 fails to load the BIOS, instead, a static (non-blinking) white underscore (dash) is displayed in the upper-left corner of a black screen. Nothing else can be done, I have to hard-reboot the computer. So I can't select my SSD where Manjaro is installed as the booting disk. If I don't try to enter the BIOS, Windows is starting normally. I can fix it by following this guide and erasing the data on my SSD. In Windows cmd, I type diskpart, sel disk 0 and clean. While rebooting, the BIOS is fixed.
I think I tried every options about partitions during Manjaro installation. I usually select "erase disk" which adds Manjaro and another EFI partition on the second disk. I also tried the option "install alongside", which install Manjaro on my SSD but also add a new entry to the EFI Windows partition. As a result, the BIOS was still not accessible, but it failed even after erasing the SSD. The solution was to assign a letter to the EFI partition (using diskpart), cd to the EFI partition just named, cd to EFI directory, remove the "Manjaro" folder, reboot.
That makes sens. Something in this folder is conflicting with Windows Boot, no matter if it belongs to another EFI partition in another disk.

I disabled fast and secure boot, I created bootable usb using Rufus v3.4.1430 and I selected "GPT + UEFI only" options, also I createed the usb with "dd" mode.

I tried the installation with 4 different distributions, this explains why I came to the conclusion that there is some issue in the Manjaro installer.

• manjaro-i3-18.0-stable-x86_64 -> Broke the BIOS
• manjaro-xfce-18.0.3-stable-x86_64 -> Broke the BIOS
• lubuntu-18.10-desktop-amd64 -> Works fine (use the Calamares installer like Manjaro)
• ubuntu-18.04.2-desktop-amd64 -> Works fine (this does not use the Calamares installer)

Please, ask me if there is anything I can do to help fixing this issue, and make Manjaro even easier for future beginners willing to dual-boot with Windows on two disks.

[SGS]

Post output
$ inxi -Fxxxz

use search function, forum is full of dual boot problems.

How to provide good information in your posts

When asking questions in the forum, it would be most helpful to all members if you provide some basic information. When you provide info from the terminal, usually from your logs, you have to format it so the content is easy to read. First copy and paste your text/terminal/code into the post Then select the text/code and click the post edit toolbar button </> . Another handy way is to use 3 backticks ` at the start and 3 more at the end of the text like this: ``` Paste text or code here …

[Delgan]

Please, don't assume I did not search the forum already.

If as you said "forum is full of dual boot problems", this is symptomatic that something could probably be improved in the Manjaro installer. As I said, I did not encounter any problem with other distributions.

[jonathon]

@Delgan

As a result, the BIOS was still not accessible, but it failed even after erasing the SSD. The solution was to assign a letter to the EFI partition (using diskpart), cd to the EFI partition just named, cd to EFI directory, remove the “Manjaro” folder, reboot.

This suggests there's something broken in Manjaro's GRUB UEFI setup.

One thing to try would be to install/use Arch's GRUB package instead which should narrow down whether it's the newer GRUB than that in Ubuntu or the Manjaro-specific patches.

[linux-aarhus]

If you experience issues you should report them upstream.

calamares/calamares

[jonathon]

We need to know whether this is an issue with Calamares first. OP says Lubuntu (which uses Calamares) is fine.

[linux-aarhus]

But they sure do have their share of problems

https://www.google.dk/search?q=lubuntu+calamares+installer

I don't think Calamares breaks the bios - there must be something else going on - to break the bios requires some fairly low level access - and the writing of an EFI boot entry using Python does not count - in my opinion - as Calamares works on every system I tried it on.

Agreed - I have not thousands of systems but the first twenty different system I do have tried.

[Delgan]

@jonathon

One thing to try would be to install/use Arch’s GRUB package instead which should narrow down whether it’s the newer GRUB than that in Ubuntu or the Manjaro-specific patches.

Well, I'm afraid not being skilled enough to properly install a bare Arch Linux. Do you know any other Arch based distribution with an automatic installer I could use to test this?

I'm having hard time understanding:

• Is this a problem with two UEFI partitions on two disks?
• Is this a problem with Acer BIOS (related issue)?
• Is this a problem with Manjora installer?
• Is this a problem with Arch grub?

While trying to fix it, I somehow managed to make it work by first installing Ubuntu (or Lubuntu?), and then replacing the partition with Manjora while not erasing the disk first, and adding new entry to Windows UEFI partition. The BIOS was accessible and I could boot Manjora. I can't remember exactly what I did so I'm not able to reproduce it (and my BIOS is broken again).

One thing for sure is that each time I'm in trouble with pressing F2 to access BIOS, I have to remove the EFI/Manjora directory (whether it's located in SSD or eMMC UEFI partition), and it works again (but no grub). Also, no problem with Lubuntu, wheter it's installed with a new UEFI partition on the SSD or if the entry is added to the existing Windows UEFI.

[jonathon]

I meant install this package:

https://www.archlinux.org/packages/core/x86_64/grub/

in Manjaro and then run a grub-install.

That should mean you get the Arch GRUB instead of the Manjaro GRUB.

However - I have no idea what will happen.

[AgentS]

@Delgan

I can fix it by following this guide and erasing the data on my SSD

I think you have an issue with your UEFI firmware or hardware which potentially remove/alter the Manjaro entry, or something Manjaro installation (grub or graphics).
Deleting Manjaro UEFI folder is just a way it looks like a solution, but actually is not. As it is said

@linux-aarhus

to break the bios requires some fairly low level access - and the writing of an EFI boot entry using Python does not count

Manjaro installers may need some improvement, but you have to discover what really happens.

@Delgan

the BIOS was still not accessible

Don't you have two shortcuts, one for the Main Menu and one for Quick select boot?

Have you tried the known solution for recovering Manjaro UEFI entry from Windows?

[Delgan]

@jonathon

I meant install this package:

https://www.archlinux.org/packages/core/x86_64/grub/

in Manjaro and then run a grub-install .

That should mean you get the Arch GRUB instead of the Manjaro GRUB.

However - I have no idea what will happen.

Thank you for the details.
What happened is that the BIOS was still not accessible, but instead of automatically booting Windows, grub failed to find an appropriate entry point and entered in the grub terminal instead.
So I had to deal with initrd and vmlinuz stuff to successfully start my system, before later realising I could just have typed exit to access some boot loader.

@AgentS

Manjaro installers may need some improvement, but you have to discover what really happens.

I would love to discover that, but for the moment I miss a lot of knowledge to understand what is happening.

@AgentS

Don’t you have two shortcuts, one for the Main Menu and one for Quick select boot?

Indeed, by typing F12 I can access the Windows boot loader. It's not broken. Thus, this allows me booting Manjora manually.

@AgentS

Have you tried the known solution for recovering Manjaro UEFI entry from Windows?

Thanks for the link. Using this workaround successfully load the Manjaro grub at startup (instead of automatically booting to Windows)!
However, the BIOS is still broken while trying to access it with F2...

I think there is maybe problem in both Manjaro installer and Acer UEFI implementation. This looks like an edge case hard to investigate.

[AgentS]

@Delgan

Using this workaround successfully load the Manjaro grub at startup (instead of automatically booting to Windows)!

Great! That's an improvement.
Now, do me a favor, please.
Disable grub auto-hide temporarily and reboot a couple of times, to see if there is any change in the behavior of your hardware.
Post your observations, if any and re-enable auto-hide, if you like it.
I am thinking of the possibility, the combination of hidden-grub with some vendor "modification" on the UEFI implementation could have something to do with your issue.

It is known that vendors implement custom implementations of UEFI on several cases. Linux tries to follow the published standards, so it is impossible to say that Manjaro installation process is directly responsible for UEFI menu disabling, maybe in-directly .

Anyway, a bug discovery is always welcomed!

[linux-aarhus]

It is known that some vendors creates a pinhole button for booting the system to the firmware e.g. some Lenovo systems.

I have been doing some thinking and it occurred to me that at some point when the development of the silent grub was ongoing - the grub menu contained an entry for booting into the firmware. Some research point to an argument to the reboot command of systemctl

systemctl reboot --firmware-setup

The fact that the bios access go missing when installing a non-secure boot OS like Manjaro but not when using Ubuntu might be due to Ubuntu having payed Microsoft to sign their bootloader.

It is purely guesswork but I would not be surprised if the Secure Boot and TPM is somehow connected to the keypress for BIOS access gone AWOL.

A punch in the dark-guess would be that since the bootloader is no longer signed and Secure Boot is disabled the BIOS access is removed by e.g. TPM - I have no factual knowledge on this matter - so I am guessing.

This question/answer gives a little more insight.

[AgentS]

There is also a GRUB parameter for timeout-button.
A search in grub manual will show you (I'm out)..

Edit: (Smartphones are.. smart)
‘GRUB_DEFAULT_BUTTON’
‘GRUB_TIMEOUT_BUTTON’
‘GRUB_TIMEOUT_STYLE_BUTTON’
‘GRUB_BUTTON_CMOS_ADDRESS’

Variants of the corresponding variables without the ‘_BUTTON’ suffix, used to support vendor-specific power buttons. See Vendor power-on keys.

https://www.gnu.org/software/grub/manual/grub/grub.html#Vendor-power_002don-keys

[Delgan]

Thanks for your investment about my problem.

@AgentS

Disable grub auto-hide temporarily and reboot a couple of times, to see if there is any change in the behavior of your hardware

I'm not sure to understand. Isn't the auto-hide grub supposed to be disabled as a dual-boot system is detected? Actually, I had to enable it manually, by setting GRUB_TIMEOUT_STYLE=hidden. This didn't lead to any significant changes in booting behavior, except for the "Acer" logo being displayed thrice, without grub, before starting Manjaro.

@AgentS

It is known that vendors implement custom implementations of UEFI on several cases. Linux tries to follow the published standards, so it is impossible to say that Manjaro installation process is directly responsible for UEFI menu disabling, maybe in-directly .

Sorry to have "accused" the Manjaro installer. This may indeed be caused by defects in the UEFI of some manufacturers which Ubuntu managed to fix / workaround.

@linux-aarhus

Some research point to an argument to the reboot command of systemctl

systemctl reboot --firmware-setup

This indeed try to load the BIOS as like typing F2 at startup, but it fails with the white underscore screen as usual.

@linux-aarhus

The fact that the bios access go missing when installing a non-secure boot OS like Manjaro but not when using Ubuntu might be due to Ubuntu having payed Microsoft to sign their bootloader.

I'm probably not the first one to dual-boot Windows and Manjaro, yet while many have met problems, I read few issues about BIOS not loading properly. I am more suspicious of Acer than Microsoft. Maybe I could with another distribution.

[Delgan]

Ok, so I finally succeeded to have my dual-boot working with bootloader and BIOS.

Here are some thoughts about issues I struggled with, some useful links, some commands that helped me. I will try to explain what I understood, but there is a lot of darkness left. This post should help me in the future if I have to do a new installation, maybe it will help other people too.

So, I tried to install Arch Linux with Anarchy and it worked fine. Then I tried to install Arch Linux "from scratch" with this helpful script and using rEFInd as a bootloader and it failed. Why?
I figured out that removing EFI/refind/refind_x64.efi make the BIOS work again (but of course no bootloader), removing EFI/refind/drivers_x64/ext4_x64.efi (= Arch) changes nothing (except bootloader can't launch Arch of course). No need to touch the EFI folder of Windows.
Actually, the answer to my issue was stated in the Acer forum and is a very common problem: Can't access UEFI after installing linux dual boot
As you stated, @linux-aarhus, this is related to UEFI Secure Boot of some modern computer.
And it seems Ubuntu may indeed have paid Microsoft so their bootloader is signed, see: The rEFInd Boot Manager: Managing Secure Boot
I don't know why it worked with Anarchy, though. I don't know why it failed with Manjaro. It may be related to the bootloader used (grubx64.efi vs refind_x64.efi).
So, if an untrusted .efi file was present in some ESP partition (whether it's on Windows or Linux drive), the BIOS refused to start, just black screen. Is it a bug in Acer UEFI? A bug in bootloader? A bug in Arch .efi? A boot security? I don't know.

So my solution: disable secure boot, start Archiso bootable USB, install Arch, restart -> BIOS should fail, so boot on USB, mount ESP partition, rename /boot/efi/EFI to /boot/efi/EFI_BACKUP, reboot, go to BIOS (should work now), enable secure boot, add /boot/efi/EFI_BACKUP/refind/drivers_x64/ext4_x64.efi and /boot/efi/EFI_BACKUP/refind/refind_x64.efi as trusted source, disable secure boot, reboot on USB, move EFI_BACKUP back to EFI. It should work. If not (I think copying EFI_BACKUP back to EFI didn't worked well the first time), continue tweaking the installation by disabling and enabling secure boot, restarting refind-install, etc.

Edit: Not so sure this solution is workink very well. I could not make it work when I tried to to re-install Arch from scratch. What happens when Arch is installed, or when refind-install is executed: a new EFI folder containing "refind" boot files is created in the ESP partition, and a new entry pointing to refind_x64.efi is added to the boot loader (see efibootmgr -v output). This entry is not secure, so the BIOS access is broken, by moving EFI to EFI_BACKUP, it seems the boot loader entry is no longer valid and the system (or Windows ?) remove it from the boot entries (NVRAM probably being re-written), and fixing the BIOS. When moving EFI_BACKUP back to EFI, the BIOS still work, but the refind bios entry does not re-appear. This is at this time that the refind_x64.efi should be added as a trusted entry, since we got access to the BIOS, and refind is at the correct path. Then it should work (but need to tweek redinf.conf so Arch starts properly).

So, the main issue was: I needed to add Arch .efi as a trusted source, but to do so I needed to access the BIOS which was broken once Arch was installed...

I probably could have fixed the Manjaro installation the same way. There is probably also a more straightforward way to do it for someone who better understand what is going one. I don't think Manjaro devs and installer can do anything about that anyway.

Also worth reading: UEFI boot: how does that actually work, then?

Unrelated: notes to myself about installing Arch

• start with loadkeys fr for azerty, run sudo wifi-menu to access Internet, if troubles with netctl (systemctl status netctl) make sure ip link set <interface> down
• Make partitions using cfdisk (EFI 550 MiB + swap + root)
• If reFINd fails to start Arch, read the wiki, particularly, add an entry to refind.conf with volume=<partuuid>, then launch Arch and run refind-install so it populates bootloader properly, finally remove the added entry
• To fix reFINd not displayed in boot entries, from the bootable Archiso USB, run arch-chroot <mounted_root> /bin/bash -c "refind-install" (see aui script source)

[AgentS]

Having stated that

@Delgan

don’t assume I did not search the forum already

I thought you should have definitely read the Ultimate Grub Tutorial, which includes in Special cases an Acer solution and link.
Have you checked this and does it apply to your issue?

[Delgan]

I had searched the forum for BIOS, dual-booting and Acer issues.

I was not aware of this tutorial, probably because:

• Searching for "grub" would have been too generic and not specific enough to my problem
• It didn't come to my mind that my poblem was related to grub, all I saw was a broken BIOS

Now that I've read it, I think it would probably have helped me understand and find a workaound. The suggested solution would not have been sufficient, though, since it requires access to the BIOS that was broken.