Make Manjaro installer images work with Rufus


Thread title changed from "Fix Manjaro's GRUB" to "Make Manjaro installer images work with Rufus"

Continuing the discussion from So, what the heck happened to the bug tracker?:

GRUB works to spec on all other distros, so something is broken in Manjaro's GRUB.

I've looked through the GRUB packaging files on GitLab and can't find anything relating to FAT (or modules in general).

A number of thoughts:

  • We've deviated a lot from Arch's PKGBUILD
  • Arch's PKGBUILD has enabled 32-bit EFI for 64-bit GRUB
  • We're carrying a lot of patches
  • We appear to be distributing an unreleased/development GRUB version (2.03)

So it seems to me there are a couple of things to do.

  1. Re-align with upstream Arch's PKGBUILD to minimise potential for introducing untested changes
  2. Build a "plain" GRUB 2.02 (or 2.04rc) and see if that fixes the above issue; for example, has the development version introduced a regression or defaults change
I can't get a working iso
Kein Weg führt an grub rescue bei der Installation vorbei.
So, what the heck happened to the bug tracker?

Question: how do you find out which modules are enabled?


Exactly - I have been trying to figure it out - on/off - for months now.

By dissecting the image after running buildiso -x I find two /etc/default/grub

  • rootfs/etc/default/grub
  • desktopfs/etc/default/grub

None of these has any impact on the resulting ISO. This is verified by mounting the ISO and then checking the /boot/grub/grub.cfg for

  • insmod fat
  • insmod ntfs

I have been looking through the initcpio folder in the manjaro-tools source and I am sure I have missed it somehow.

Looking at the file initcpio/install/miso in the manjaro-tools folder.

It is calling an add_module function

Do not work
These files are installed to /etc/initcpio/ and I am testing the impact on editing the install/miso adding the lines

add_module "fat"
add_module "ntfs"

I believe all the mod are available under /usr/lib/grub in the i386-pc and x86_64-efi directories. They both have a fat.mod file, so I'm not sure if there is somewhere else to enable/disable the modules.

My read says that command.lst is the file that bridges the commands available to the modules. Also there is as fs.lst that appears to list all the file systems.


Please be mindful that in order for GRUB to read the content of these directories, it needs to embed fat and part_msdos or part_gpt in the bootloader (not as external modules), as, obvioulsy, it won't be able to load fat.mod off a FAT system unless it already has that module...


Grub on the install media already import part_msdos and part_gpt.

What we are trying to achieve is not documented - so kind of trial and error.

Manjaro's truck factor - as I see it - is one, maybe two if we count @oberon in. If @philm was to be run over by a truck - Manjaro would have a hard time surviving.


In the case of overlay packages we'd just revert to Arch packages. However, this is OT. Let's stay focussed on GRUB.


I personally don't think anything needs fixing, Rufus is a windows application and does a average job with installing windows.
It does less than a average job with Linux unless its Ubuntu so we don't need to go down that road just for windows apps.

We have good tools in Linux like etcher, imagewriter, and many others only unebootin does not use dd, lets keep it that way.


OK, so this may be an issue with the image rather than GRUB...


@mandog, then you will alienate not only Rufus users but users who (because they can do this for other distros) choose to simply extract the whole ISO content on a FAT32 drive to boot their UEFI system.

Or do you also want to tell those users that they should not attempt to use a method that works for Debian, Ubuntu, Arch, and that doesn't require the use of third party tools (which you should actually be more than happy with since you seem to have reservations about some of these utilities).


Just my 2 cents. I have created more manjaro iso's than I care to count using balena etcher. I have done so via windows, linux, and OSX. I have never had one not boot. I cannot honestly in good conscience say the same of Rufus and it used to be my go-to image burner.


Nothing is wrong with our Grub. All functions are enabled. However on how we use the build of the layout in its current state we simply don't support unetbootin. Currently dd is the way to go.

We also use a development version of Grub with extra patches for our needs. Therefore a stock release won't work.

If there are any changes needed to be made then it will be the way we create the ISO.


So it is missing fat then, hence the issue. And yes I understand that this is not documented (and may even result in further requests down the line depending on how well the init script or equivalent can handle something else than ISO9660 for the installation media). But I still fail to see why you would refuse to add fat if you can confirm that it is indeed missing, as this is what other distros do.


You are talking bull, dd just works all you are doing is trying to justify you own software failings.


@Elloquin, the reason for that is precisely what we are trying to address here!

BalenaEtcher limits itself to a single mode (DD) so it doesn't have this issue. But, for the reasons I explained in the gitlab bug, Windows users tend to prefer ISO mode over DD.

If you want to push for Manjaro to limit itself to only one mode, fine, but it may contribute to people using other distributions, regardless of whether they use Rufus to create their installation media or not.


Again, there is nothing wrong with our Grub. It is the way we currently create the ISO within our tools. Several things need to be changed if we want to support something else than dd.



This is a development thread. Please stick to the topic. Opinions or posts unrelated to the specific topic at hand will be culled from this point onwards.


Personally I am not rufus'ing anything.

You maybe right about the standards but it is more your problem than Manjaro's.

You're trying to meet your end-users requirements - using a Windows only application - which is perfectly capable of writing the Manjaro ISO using dd mode and thus you are trying to make Manjaro adhere to something completely irrelevant for the Manjaro distribution.

The problem is your end-users. Educate them - when they download your software - tell them - Hey, are you writing a Manjaro ISO - remember to use DD mode."

Make it a sticky on your web site or what ever you need to make your users aware of the issue.

I do not have enough knowledge to know why the tools write the ISO as it does so I cannot contribute - but the way I see it - it is your problem and you are trying to make it Manjaro's problem.

I would love the tools to build the ISO in a way that makes it possible to use the remaining space on any USB stick but it is not an issue to me.


This isn't a helpful approach. If Manjaro and only Manjaro is doing something differently for no good reason then this isn't an issue with Rufus.

How many threads do we see where people can't boot Manjaro? Why not fix this ourselves rather than making it an issue with every other piece of software?


Well, it's your decision, so if you want to force everyone to use dd mode, again, as opposed to what most other distros seem to do, so be it.

It will continue to create frictions for new Manjaro users however. If possible, and if you're not doing so already, I would strongly suggest that you try to spend some time looking for Manjaro boot issues, as maybe it will help you decide whether this is an important enough issue to want to address in the future or not.

PS: As the reporter, I hope that statement does not count as opinion and will not be deleted.

Oh, and to address @linux-aarhus's last point, I'm already displaying a prominent message, in my application, advising people that, if they find that ISO mode doesn't work, they should retry in DD mode. I'll see if I can add even more advices about Manjaro, but I fear that all it will do is possibly make people think twice about deciding to use Manjaro...