manjaro-kde-18.1.5-minimal-191229-linux54 fails MBR installation

I recently bought an old HP Elitebook 820 G1 with a Windows 10 installed with uefi and secure boot. Massaged the BIOS until I could use Easy2Boot from an USB stick to boot a Linux ISO.

I booted manjaro-kde-18.1.5-minimal-191229-linux54.iso into the live desktop and ran the installer. Installed using the entire disk for Manjaro and chose to install GRUB in the Master Boot Record. Boot after installation: no bootable disk found! After several attempts with changing settings in the BIOS and new installations, still no luck. Checked the ISO checksum, file was perfect.

Installed Debian 10.2.0, it booted and ran perfectly. So the problem was not the hardware!

Booted manjaro-kde-18.1.5-191229-linux54.iso into the live desktop and ran the installer. After installation it booted and ran perfecty. Oh sweet joy! :sweat_smile: :smiling_face_with_three_hearts:

My conclusion: manjaro-kde-18.1.5-minimal-191229-linux54.iso does not install GRUB properly in the MBR.

Not true.

Whether you use the minimal or the full ISO - Calamares is the same - the instructions the same - so the only thing different is your changes in BIOS maybe the way you booted the system.

Why would you choose a BIOS/MBR installation over EFI? (Just a rethorical question)

Did you use MBR partition or GPT partition?

If you used GPT partition and want BIOS boot you need a 1MB bios boot partition to hold the boot code.

If you booted the system in EFI mode then installing as MBR - Calamares get's confused and needs to know where you want the loader installed.

In either way you have chosen a mixed approach and you can't expect a software to know what you are trying to achieve.

Computers are very different than humans - they do exactly what they are programmed to. In this case Calamares - you have failed to supply needed info because Calamares usually works with either installation type.

dav Frede
Godt at se at der er Manjaro-fans overalt i Verden :denmark:

I use BIOS/MBR because I like it. I know how it works, and it has never failed me. I fail to see the advantage of UEFI, and thus I have not bothered to learn about it.

As far as I recall, I did not change any BIOS settings after my last attemp with manjaro-kde-18.1.5-minimal-191229-linux54. Pardon me for not testing a new fresh installation, I have used the PC for a month and tweaked settings to my liking.

Hey, I have an old SSD lying somewhere, I might give manjaro-kde-18.1.5-minimal-191229-linux54 another go. I'll be back.


That's OK - no need to redo all the hard work :slight_smile:

dav igen

I am sorry to say that my troubles with manjaro-kde-18.1.5-minimal-191229-linux54 persist. :persevere:

I made a fresh boot-USB with Easy2Boot and manjaro-kde-18.1.5-minimal-191229-linux54.iso, put a different SSD in the Elitebook, booted manjaro-kde-18.1.5-minimal-191229-linux54.iso into the live desktop and ran the installer. I chose "Erase disk" for Manjaro and chose to install GRUB in the Master Boot Record. On the last screen before launching the installation proces, the installer said using /dev/sda and installing boot loader in MBR. Boot after installation: no bootable disk found!

Now I will try the same with a manjaro-kde-18.1.5-191229-linux54.iso.

Thank you for taking the time to verify it :slight_smile: :+1:


I have found the problem :sweat_smile:

I made a fresh boot-USB with Easy2Boot and manjaro-kde-18.1.5-191229-linux54.iso and booted it into the live desktop. I looked at the harddisk with the previously installed manjaro-kde-18.1.5-minimal-191229-linux54 with sudo fdisk -l /dev/sda, and it did not show an asterisk for the boot flag!?!

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1          2048  1187839  1185792  579M 83 Linux

So I used fdisk to set the boot flag, shut down and removed the boot-USB. Turned PC on, and YES!! it booted Manjaro KDE Minimal :smile: :hugs: and there was much rejoicing.

That is IT for you, miss one tiny detail and you can search for the problem for days :thinking:


I wonder if this is why I couldn't boot my desktop yesterday after manually transferring the installation to a lvm raid0. I thought it had something to do with the setup, but now I'm starting to think this might be simpler than it looks.

I installed manjaro-kde-18.1.5-191229-linux54 just to test it, but this time I chose manual partitioning type DOS and made a partition for Manjaro and a small swap partition, and chose to put GRUB in MBR.

Boot after installation: no bootable disk found! WTF? I cannot remember what I did at the installation a month ago that worked, but WTF now?

Boot the live Manjaro on boot-USB and open terminal.

sudo fdisk -l /dev/sda
[sudo] password for freddy: 
Disk /dev/sda: 232,91 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 840 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5785148b

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1            2048 485378047 485376000 231,5G 83 Linux
/dev/sda2       485378048 488396909   3018862   1,5G 82 Linux swap / Solaris

Ach du lieber, missing boot flag again! Same procedure as before with manjaro-kde-18.1.5-minimal-191229-linux54 : set the boot flag with fdisk, shut down and remove the boot-USB. Turn PC on, and it boots Manjaro KDE from the harddisk.

It seems that on some combinations of installation on DOS-partitioned disk and GRUB in MBR, the installer fails to set the bootable flag on the Manjaro partition. Problem is reproducable with both manjaro-kde-18.1.5-191229-linux54.iso and manjaro-kde-18.1.5-minimal-191229-linux54.iso

I have mentioned a few times elsewhere in this forum. (As well as installing uefi to a msdos disk and...)
A disk needed to have its 'partition table' set before installation.
At gparted, device tab --> Create Partition Table --> gpt or msdos.

Do not use 'erase disk' method at calamares installer. That will erase the partition table.
Even if using 'manual partitioning', if the partition table is not set up, this problem will arise.

A new disk bought form the store is 'raw' and will not have the partition table set.
If using a disk with an existing windows OS, the table has been set and we must use the same scheme as existing window. If we erase the disk to install fresh, create partition table after erasing disk.

Anyway, setting a boot flag after an installation will fix it. And perhaps the reason why this wasn't fixed.

Calamares offers the 'erase disk' option, and when I used it in my first attempt, the installation went well except for the missing boot flag. Calamares created a new msdos partition table with one primary partition using the entire disk. There was no trace of the previous partition table with the Windows 10 installation, which was set up with UEFI and secure boot.

Not being able to handle a raw disk is IMHO a severe weakness for an installer. My installations seem to disprove your hypothesis that the partition table must be present before installation. To test your hypothesis, you can try using sgdisk --zap-all /dev/sdz to erase all partition tables on the sdz device and then run the installation (replace sdz with your actual disk). If you want to make absolutely sure that the disk is raw, use dd if=/dev/zero of=/dev/sdz to wipe it.

I did not say that.
What I said was that installation will proceed but a boot flag will not be generated and will have problems booting.

Some examples, there's more

Forum kindly sponsored by