Artix grub and multiboot with arch and non-arch based systems

Did you just upgrade Manjaro and now your Artix will not boot, or vice-versa?

This is a peculiarity of grub in relation to Artix, and Manjaro, and I suspect all Arch based distros.  When Artix or Manjaro make grub entries for all other installations found on the system (other than those from the same family) they use the universal entry template for generic linux distros.  The entry they make for themselves is different and if it is not done this way they will throw the installation into “kernel panic” and this would be the last thing written on the screen before you pull the plug as no input will be recognized.  It is all on the format of the commandline that grub uses to start up the kernel.  [note: in the early days of Manjaro-OpenRC when I still had Manjaro-systemd still installed, they both made correct entries for each other.]

Now listen to this!  Artix (to both Manjaro-OpenRC or Arch-OpenRC) is a substitute for those two discontinued projects.  Let’s say you are hard headed enough to keep a copy of the obsolete discontinued distribution and have installed the new one beside it, among other installations.  When Manjaro finds Artix it treats it as any other linux distribution, and formulates the grub entry just if it was Debian or Void or Devuan.  For itself it makes a custom entry so it can boot again.  This is semi-excusable for Manjaro not knowing Artix very well, being the new kid in the block.  So now, your Artix will not boot.

When Artix builds its grub menu for multiboot, it does the same exact thing for Manjaro.  So Manjaro will not boot from the Artix grub menu, and Artix will not boot from the Manjaro menu.  Guess what?  The format they both use for themselves is EXACTLY THE SAME!!!  Everything else works with either one of them, but neither will work with the other’s grub entries.  It used to be simple to have one of those weirdo grub-booters handle grub for the whole system as what they configure works for all other non-Arch based systems.  But now, if one has two of those weirdo grubers on, either one will mess the boot sequence for the other.

So what is there to do?  Decide which one of those idiosyncratic distros you want to handle all grub, then “update-grub” on the other when necessary, maybe due to kernel changes/updates, and then edit “/boot/grub/grub.cfg” search for the first menuentry, copy till the } bracket ends below the last submenu entry of that installation, and paste it in the main grub handling other weirdo.  It is best to have grub on the most active installation of the two or more, and copy the entry from the least frequently updated system.  Then make a backup for the menuentry of each one of those weirdos so you can cut and paste without partition hopping (ie make a menuentry stub and call manjaro.cfg stored on both artix and manjaro, and the same for the other).  If grub, or grub-pc, get updated, the “pacman” will go and reinstall itself on the disk as “it” being the manager to start all other installations.  So you never know when you will need that patch.

To install grub by any linux ditribution that has grub, use sudo grub-instal /dev/sda (or sdb or whatever your system’s disk name is).  If you want to transfer control to another go to it and it will boot based on that system’s /boot/grub/grub.cfg.  If you know of a better way around this “bug” that none of the developers will accept as a bug, please let us ALL know.  The developer will tell you that it is not a problem or an issue if you let their distribution handle grub.  But Devuan can say the same thing or Ubuntu or practically any of the 1500 distros out there, and then your Artix, or Manjaro, or possibly Arch, will not boot.  In all my research I have found NO EVIDENCE of the advantages of the alternative routine for booting those distributions.  Now, if only Grub team would listen and create a script to identify the peculiar weirdo distributions and use their alternative template the problem will be solved.


4 thoughts on “Artix grub and multiboot with arch and non-arch based systems

  1. The solution I use is to disable the OS prober by adding or changing the line


    in /etc/default/grub, and then copy the correct grub menu entries to /etc/grub.d/40_custom so that they are copied to /boot/grub/grub.cfg when it is generated. So I let the distribution I run grub on generate its own entries, and copy the remaining entries from 40_custom. I let each distribution generate its correct entries but running update-grub on it but skipping the grub-install step.


  2. I’ve never tried this 40_custom trick. It sounds good, as all the cutting and pasting would only have to be done once, but how would it get updated when the other systems change their entry. Wouldn’t you have to copy their primary entry and transfer it to 40_custom of the main grub handler?
    Lets say you have Artix and Lubuntu. When Lubuntu would get a new kernel its updated entry would have to transfer to Artix’s grub.cfg.
    Which is what the osprober is meant to do for you but doesn’t do it right for others.


  3. Yes, it is correct, you have to generate entries on the right system and then copy them to the 40_custom file of the other distribution every time. Maybe this can be made easier if only the name of the Linux kernel file changes. Then maybe you can use a symbol link to it and after an upgrade you only need to change the link.

    Probably the best solution would be to extend the prober to handle the foreign OSs properly. After all, the prober is a grub module and the proper entries are generated by the same grub running on a different distribution, I cannot imagine that this can be so difficult.


  4. You are very correct. It is not and shouldn’t be difficult if grub was to do it. The rest just write scripts for their own system to boot and couldn’t care less if it makes other cohabitating systems unbootable. Between the Debian variants (Mint ubuntu, etc) and Manjaro/Arch, we are talking about 90% of the users, and if they like to use different distros for different things (work, play, entertainment) they are affected by this.

    It seems that GNU ideals to corporate distributions is what the Hypocratic oath is to private health physicians. It means nothing!


If your comment is considered off-topic a new topic will be created with your comment to continue a different discussion. This community is based on open and free communication, meaning we must all respect all in minimizing the exercise of freedom to disrupt such communication. Feel free to post what you think but keep in mind the subject matter discussed. It is just as easy to start a new topic as it is to dilute the content of an existing discussion.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.