Manjaro breaks the MBR of disks - is that ever gonna be fixed?

A few years ago (2019 or so) I decided to try Manjaro and if it wasn’t for the major problem I discovered, I probably would have stayed with. Back then I only had one SSD where I could install any OS to try it and then install back Mint, in case I didn’t like what I’ve tried. That’s how I discovered that Manjaro’s installer had broken my SSD’s MBR and I had to run Live Mint with boot-repair to repair the damage.
Earlier this year I tried Manjaro again, just to see if that problem was fixed but it wasn’t - my SSD’s MBR was broken again.
So, is that ever gonna be fixed?

I suspect you are trying to mix MBR and EFI and that is not possible.

You either use BIOS/MBR or you use EFI/GPT.

It is possible to use BIOS/GPT but then you have create a separate unformatted partition size 1MB partitition type 0xEF02 to store the bootloader.

So - no Manjaro does not break MBR - the installer does what it is instructed to by the user.


I’m not mixing anything, I know exactly what I’m doing, cuz I’m not doing that for the first time in my life. My BIOS is UEFI/BIOS but my system has always been legacy. That’s the way I’ve set it in BIOS as well. Everything is legacy, meaning using MBR, not EFI files. I’ve always installed Linux (and Windows, when I used to use it) in legacy mode with MBR. Even nowadays when I install Linux, I always do it in legacy mode bc I dislike EFI a lot for several reasons.

This is how I install all distros, Manjaro included: whenever GParted tells me I have to chhose a partition table, I always choose msdos, which is the legacy mode with MBR. Create partition and format it as ext4. In the drop-down menu where you have to select where the bootloader must be written to, I choose the device itself (not a separate partition, but the whole device itself) which in my case is Corsair 120LE (120GB) and then proceed to the actual installation. In the past 7 years since I started using Linux, I tried many distros. I was distrohopping a lot before I chose Mint back then. Not then and certainly not now, no other distro has ever had a problem with the way I’ve installed it and no other distro has ever broken my SSD’s MBR, only Manjaro did. When Manjaro breaks the MBR, any attempt to boot from that partition shows “grub rescue”. Even if I install another distro, it still won’t boot because MBR is broken and the only solution is boot-repair.

loaded question
… nothing to fix because nothing is broken :man_shrugging:

1 Like

Does the OP see anyone else complaining about this? I have Manjaro on two PC’s and one laptop, all with SSD, and no ‘MBR’ problem on any of them.

but even if that was the case, it would be just as anecdotal as OP’s report

… no room for unnoticed mistakes there, I guess :wink:

1 Like

For as long as you use only Majaro on that device, you won’t see it. The problem becomes visible when you install anything else in place of Manjaro. Then you’ll see “grub rescue” screen - right after the fresh installation of that “anything else”. You’ll reboot to load the newly installed distro, but it won’t boot and it will show you “grub rescue” instead. That means that the master boot record of the disk has been broken.

… that’s not what it means …

1 Like

So your problem is not really Manjaro - but the anything else - you just installed … right?

No - that is not what it means.

When you get dumped to the rescue prompt it is because the pointer to the location of the remaining part of the loading process is invalid.

That has nothing to do with Manjaro … It is caused by your newly installed distro …

You may find it interesting to peek the grub documentation to get a deeper understanding of the process


series haswell generation was juste before launch EFI skylake
if you have the latest UEFI on your motherboard

in your UEFI

  • disable secure boot
  • disable fastboot
  • all disks on AHCI
  • no legacy
  • no CSM
  • UEFI only or others ( not windows )

check on boot USB live manjaro
you will see
< USB vendor name > → this one boot in MBR install ( not UEFI[Legacy])
UEFI < USB vendor name > <partition 1 > this one boot in UEFI ( NOT UEFI[Legacy] )

launch terminal and recheck before installing

inxi  -Mxa ( check for UEFI only , not UEFI[legacy] or Bios )
test -d /sys/firmware/efi && echo efi || echo bios

launch gparted to see partittions type ( GPT or MBR ) and all options flags

if UEFI , then

sudo efibootmgr -v

you have to choose GPT , and create /boot/efi as vfat (fat32) with flag boot & esp
you can use gparted before to create all partitions

Is the installation media booted in Legacy mode? Since your motherboard supports UEFI, it can also boot it in EFI mode, which then will want to install Manjaro in EFI mode.

Have you tried letting the Manjaro installer do the partitioning (option Erase all disk)?

That’s weird. AFAIK installing a new distribution in Legacy and putting the MBR at drive level should override the one previously there, “fixing” it instantly (considering the fault comes from the code at MBR)… :thinking:

Also, have you checked your drive’s health?
S.M.A.R.T. - ArchWiki.

1 Like

When the MBR is broken you will never reach grub rescue !

  • when bios starts, it will start code from the mbr.
    (This is the place where some viruses liked to nest many years ago)
  • This code will load the partition-table, and select what to do now
  • if mbr is OK, this may locate and start grub
  • There you can get into rescue-mode, if grub does not find a valid configuration

There you are


The system is expecting 0x1337 at 0xBEEF instead of 0x4008. You work around it by replacing the keyboard extension at 0x40. pun intended :slight_smile:

That is what you want. Forget the MBR crap. As for a single partition yes it can be done, but it is not recommended. I used Mint to have the look and feel of Windows while I learned more about Linux, and I went more than a few rounds with the devs over the OS installing to one partition insatead of having a boot partition and a OS partition. It was enough to make me finally drop Mint all together.

1 Like