[Testing] Manjaro Gnome 18.1.0 Juhraya pre2 ISO


As promised a pre release for Gnome edition is ready for testing.
Since Adapta theme not work well with Gnome 3.32 release i have switched into Matcha-sea theme, other little improvment as usual but the major notable news is the implement of the changes made by the author of Rufus tool @Akeo ; so this mean the ability to use Rufus and other tools present in Windows OS to write a Manjaro ISO.
Please test as usual ..

Stefano Capitani

Installer stuck at 22% for an hour
Drag and drop to desktop in gnome?
Manjaro-specific packages which need an update
Very slow response of brightness controls in gnome

Matcha package outdated on unstable branch, latest pkg 25 april

Fixes various issues with Nautilus css style / gnome shell 3.32

PD: Thanks for maintaning the "diabolic DE" of Red Hat :wink:


Thank you updated matcha in ubstable :smile:


Copied with Rufus 3.4 using all default settings, ISO mode. Got Grub 2.03.5 missing error message (but could not download from Internet so had to use 2.02).

In my BIOS boot menu, I get 2 options, UEFI and legacy (actually just USB name without UEFI in front).

UEFI boots fine.

Legacy boot results in Grub recovery prompt. This is the common problem as before.
error: symbol 'grub_file_filters' not found

Is this expected behaviour? Or not expected? It seems the Rufus problem is still not solved if the user intends to install to MBR partition.

As for Gnome 3.32... well I don't use Gnome. But I noticed desktop icons can be enabled in extensions now. :partying_face:

Make Manjaro installer images work with Rufus

Interesting, thank you for report @Akeo can look into this .. or ask to check somewhere..

Yep, is not shipped via official Gnome extensions but shipped via World repo and made by Gnome developers so why not include in our edition :shushing_face:

1 Like

Similar oddities while creating the USB via etcher. Two bios entries to boot. Both UEFI no legacy and the second had additional information partition 2. Partition 2 boots into grub rescue. Second installed as normal.


I think it is expected


If that is how other distro iso's work, I guess that is fine then. If the assumption is that the majority of the Rufus complaints are coming from Windows 10 users trying to create dual-boot UEFI systems. But I think creating a proper iso in dd mode that can boot in both UEFI and legacy mode is preferable.


Thanks for applying the grub-mkimage patches I requested and publishing a new image.

I too can confirm that pre2 seems to boot just fine on UEFI systems when created in ISO mode with either FAT32 or NTFS as the underlying file system (NB: The reason I asked to add NTFS is so that users can create persistence files that aren't limited to the 4 GB limit of FAT32, though the next version of Rufus will also add persistent partition support).

Also you should now be able to get BIOS/legacy boot working (including DUAL BIOS + UEFI boot from FAT32 media, which is what Rufus 3.5 will create by default if you don't change any options) as I have uploaded the relevant GRUB download on the Rufus server.

For those who already tested with Rufus 3.5, before trying again, you should first remove the rufus_files\ directory that will have been created on Windows and that contains the GRUB core.img, that Rufus downloaded as a fallback. Or you can press Alt-D in Rufus to do the same.

Once you have done that, you should find that Rufus will download a GRUB 2.03.5 core.img, that sorts the GRUB prompt issues in BIOS/Legacy mode.

Now, about these:

  1. error: symbol 'grub_file_filters' not found comes from using a core.img GRUB that is missing one of the patches that was applied to GRUB mainline between 2.02 and 2.04-rc1
  2. Still, if you try to use the core.img we provide for 2.04-rc1, you'll find that you are then treated error: symbol 'grub_key_is_interrupt' not found, which is due to a Fedora patch (grub-accept-esc-f8-and-holding-shift-as-user-interrupt-key.patch) that has not yet been integrated to GRUB mainline, and therefore requires a specific patched built of core.img (hence the reason I had to upload such a custom version on the server).

I can only hope that these custom patches, that every other distro seems to use, will find their way into GRUB mainline, because it's going to become a bit of a headache to maintain otherwise...

Still, thanks for following up on the original issue and applying the requested changes. This should help make Manjaro a much friendlier distro for Windows users to try.

Make Manjaro installer images work with Rufus

@Akeo no problem. We always try to fix it properly. Manjaro is currently on 2.04-rc1 but has custom patches like fedora has. Speaking of fedora, they got a different way with grub.cfg. Let us see what the best way is to support Rufus and Rufus us.


Well, as long as you apply custom non-mainline patches, I can sort things out transparently for Legacy boot in Rufus, if you set a custom version string for the GRUB used for ISO boot, such as what is currently the case with grub-2.03.5 (since there is no such thing as mainline grub-2.03.5 or even a grub-2.03, though I would advise to perhaps use a more specific suffix to indicate that it's a Manjaro version, such as grub-2.04-manjaro, in case other distros produce a custom version and decide to add a .5 too).

That's actually the whole point of the lookup+fallback mechanism used by Rufus to deal with Legacy GRUB core.img (since that's one critical component we need for GRUB installation, and that we can't derive it from the files on the ISO), as, if we find a custom version string, we check if there exists a repository for that custom version on the Rufus server and use the core.img from that folder if that is the case. If not, then we try to fall back to the nearest version from the server or use the core.img embedded in Rufus (currently 2.02 since there is no official 2.03 and the next version is going to be 2.04).

Therefore, if you apply patches that are not yet in mainline, then as long as you also apply a custom-enough suffix to your version, I can sort things out through the GRUB lookup mechanism in Rufus, which is designed precisely for this kind of thing.

Of course, nothing beats using mainline wherever possible. As a matter of fact, I asked Fedora's Hans de Goede, who is the person behind the grub-accept-esc-f8-and-holding-shift-as-user-interrupt-key.patch and other Fedora stuff, and who I worked with on libusb in the past, to see if he could re-submit that patchset to mainline, as it appears the set was submitted last year, but didn't get applied due to a v2 being requested by the GRUB maintainers. At the time, Hans said he would carry out that work and resubmit but, from what I can see, never got around to do so.


When can we expect to upgrade to the final release of Juhraya 18.1.0?


As soon as it's done!


No, I Meant The Date. And Is There Any Official Repository For Matcha Sea Theme? If Yes Can I Get The Link For That Please.


You don't ask for "dates" on development. Specially on non-payed projects. Quoting 3DRealms when asked about "Duke Nukem Forever "release date: "When it's done". It only took like 16 years...

As for matcha, search for matcha-gtk-theme on your package manager of choice.

1 Like

Ubuntu And Fedora have a whole release schedule for every next semester. And does the matcha-gtk-theme contain the matcha-sea-theme?


this is not ubuntu and fedora its rolling so it will roll.
so no schedule.


So I noticed the pre3 was released yesterday but I can't find a separate thread for it.
From my stick it runs flawlessly and is actually about as snappy as 18.04 was installed. I am tempted to actually install it as is.


Please fix Very slow response of brightness controls in gnome before the release, because backlight control is almost useless since months in Manjaro Gnome Edition. On the contrary, it works fine in Ubuntu 19.04, Fedora 30 and up-to-date Arch. Months ago I hinted in the direction of pkexec, which I believe is the culprit, but it's clearly something Manjaro is adding that makes pkexec run that slow and I'm clueless about what Manjaro adds.


Here is another report of the same issue GNOME brightness control issue