Boot incompatibility issue

Support
1

Hello, Not sure where to ask this question but the question is there a conflict between Manjaro and Open Suse Tumbleweed. I have had them both installed and running on the same system (different devices sda, sdc) for years and now I can’t boot Manjaro if tumbleweed is at the top of the grub menu. I was told to try Ventoy because they may not be compatible. that turned out to be more bother than necessary, any thoughts?

2

What do you call boot menu? The firmware menu or the grub menu? If it is the grub menu, if Tumbleweed is on top than it is the tumbleweed grub - it might just not be able to chainload the manjaro grub. Because the manjaro grub is different version and modified.

Just boot through the firmware menu, or install some third party bootloader like Refind. Mixing grub-s will not work in the long term (it might until some update breaks it as you now discovered).

3

Firstly, there is not much information provided that might help others diagnose your issue. Please provide your System Information in accordance with forum guidelines. :point_down:

[Mini-HowTo] Provide System Information

Basic details provided by *-fetch type apps might give enough information for someone wishing to buy a computer, however, for Support purposes it’s best to ask your system directly.

Output of the inxi command will generate more useful and detailed information for those who may wish to help:

Suggested inxi command (use either):
inxi -zv8 (short-form)
inxi --filter --verbosity=8 (long-form)

Command output should be presented as pre-formatted text in accordance with forum guidelines. :eyes:

Running inxi within a chroot environment

  • Add --color=0 to the long-form command, or…
  • Change the short-form command to inxi -zv8c0

Your privacy is respected

[Mini-HowTo] Present code or command output

Note: Grave accent (or, backtick) characters are used. :eyes:

For inline code or to show a single command:

  • please follow this simple example: code here.

For multi-line command output:

  • place text beween two rows of three (```) backtick characters to form a scrollable text box, or …
  • use the </> button in the Compose window to achieve the same result.

The empty row between these rows of backtick characters is where to paste any multi-line command output (such as inxi).

An example of a pre-formatted text enclosure:

What is a Quark?

A. In Physics, an elementary particle and fundamental constituent of matter. 
B. A character from the Star Trek: "Deep Space Nine" television series.
C. A soft, creamy, usually unsalted cheese traditional to central Europe.

So-called Multi-boot is not a supported configuration – meaning, that multiple Linux OS instances are not designed to co-exist on the same machine – and Manjaro does not officially support it.

That said, multi-boot scenarios are indeed becoming popular (I personally multi-boot several OS) and issues are very likely to raise their ugly heads.

Some rely on (one instance) of GRUB2 to boot all OS (one bootloader to rule them all) but the potential for breakage remains.

Others (myself included) use another bootloader (rEFInd) to chain-load the GRUB2 instance of each OS – if set up properly, this has an advantage of allowing each OS to manage its own GRUB2, while boot selection is handled by the intermediary (rEFInd, in my case) – potential for problems remain, but they are minimised.

If you are trying to work with GRUB2 alone, it’s important to know that Manjaro requires its own GRUB2 to control booting for all other OS present. GRUB2 is designed to automatically detect another OS via its configuration – everything in GRUB2 is configurable, but may not necessarily be configured by default – one needs to do some reading to achieve the results desired.

GRUB2 and rEFInd can each be set to “boot the last booted OS”, which is the behaviour that most seem to prefer.

An issue often faced is that each OS will update its own GRUB2, possibly changing configuration, but the other OS know nothing about it – this in essence is the case for having one bootloader control them all.

Using an intermediary to chain-load the others is straightforward (install it, configure it, forget it) but using one designated GRUB2 to control the others can be problematic – some overcome this by physically uninstalling all but the active GRUB2 (the Manjaro instance). This can work; provided that other OS don’t reinstall their own GRUB2 unexpectedly (a rare occurrence).

Note that we don’t know how your system is configured, so you will need to help others to help you. Be aware that there are many conditions that might potentially contribute to the issue you observe.

While this doesn’t provide a direct answer – because more information is needed – hopefully it may be helpful.

Ventoy provides a convenient bootable USB method of installing an OS from an ISO file – it has nothing to do with booting your machine later.

When Ventoy is properly configured prior to creating a USB Installer (for whichever OS) it can help ensure you don’t end up with mismatched (UEFI vs Legacy) technologies being used, so that’s a wise choice. I also recommend detaching the (other) OS before installing another – relevant, as you noted each OS is installed on separate disks (the safest method).

Next steps:

  • Provide more information, starting with the inxi output previously indicated, and anything else that may be helpful; for example the output of: cat /etc/default/grub
  • Clarify concerns raised by @Teo (above) so that everybody is on the same page.
4

Caveat emptor: In the event of grub, this requires that /boot be on an ext4 filesystem, because grub cannot write to btrfs, and its support for xfs has always been a bit of a gamble. Some grub versions would support it, and then all of a sudden the next version would not support it anymore.

5

Dual booting is quite an overrated option that should be used sparingly and only after careful consideration.

Dualboot is for running Windows and Linux side by side - not for running 10 different Linux desktops.

My personal opinion is - select your os and stick with it - whether that is Manjaro, Suse or something else. There is very few reasons to run different Linux operating system in dual boot and your grub issue is one of the reasons to avoid it.

That is quite possible.

If or when the grub version installed is different between the operating systems, it is likely to create issues, this is well known.

Another point - which is also well known - and documented - is the fact you cannot reliably mix booting using MBR and EFI.

There is no one-size-fits-all solution.

And with modern UEFI based systems grub is no longer the only option for dual boot systems.

You can use rEFInd to boot any efi stub including a UKI (unified kernel image) or boot the kernel directly.

6

This suggests that OpenSUSE GRUB has replaced Manjaro GRUB

If Manjaro cannot be booted from OpenSUSE GRUB, I suggest:

To avoid similar problems in future, I also suggest uninstalling GRUB package from OpenSUSE

7

Then it’s not “dual-boot” anymore, but “multi-boot”, isn’t it? :stuck_out_tongue:

“Dual” refers to only two components. :face_with_hand_over_mouth:

Actually, grub was created as an alternative to lilo specifically for addressing the multi-boot scenario. grub is multi-boot-capable — it is also used as the default boot loader on Solaris and (I believe) NetBSD — but the problem is twofold…

  • grub goes back to a time when computers were either x86 and using legacy BIOS firmware, or RISC and Itanium-based (CISC) with EFI firmware.

    The fact that x86(-64) switched to UEFI firmware was never included in the original concept. grub does now of course support native UEFI-booting, but the ability of UEFI (on x86-64) to boot in legacy BIOS mode — due to Microsoft’s requirement for Secure Boot, whereby legacy BIOS boot was initially offered as the only alternative — is what causes a lot of problems, because one cannot mix both booting methods.

  • Manjaro uses a customized grub, which should always be the primary grub installation if more than one operating system is installed on the same computer.

Personally, I’m inclined to agree that one should install different operating systems on different computers instead of installing them all on the same computer, but there are many people who want to experiment with different operating systems — especially different GNU/Linux distributions — for a while before deciding on which one(s) to keep and which ones to drop.

Back in 1999, when I first installed Mandrake 6.0, I initially installed it in a dual-boot configuration with Windows NT 4.0, because I liked both — my NT 4.0 was heavily customized by having manually hacked the Registry, and as I’ve already mentioned elsewhere, I had paid a lot of money for the licenses for NT 4.0, MS-Office and Norton Antivirus 5 for NT.

At the time, I was still new to GNU/Linuxn, albeit not to UNIX, and I absolutely loved the fact that GNU/Linux is a UNIX — which is why I bought the shrink-wrapped Mandrake box in the first place. So at that point in time, I was still torn between both operating systems, and I would boot one and then boot the other only about an hour or so later.

Of course, the conundrum was resolved only a few weeks later, when NT refused to boot due to the Y2K bug. It was actually a blessing, really — an expensive blessing because of the money wasted on proprietary software that was now suddenly no longer usable, but a blessing nevertheless, because now I had the perfect excuse for using GNU/Linux exclusively. :stuck_out_tongue:

Indeed. But this is not really a limitation of grub. grub as a package supports both boot methods, but the version of grub that will end up installed on your system is of course going to be the one for the mode your system is running in when you install grub, given the different requirements — a BIOS boot requires grub in the MBR of the drive, while a UEFI boot requires grub to be installed as an EFI executable in a dedicated EFI system partition with a FAT-based filesystem.

Furthermore, the UEFI-capable version of grub is a completely different program to the legacy-BIOS version. The latter is just 8086 real-mode code written in assembler, which gets loaded from within the (emulated) BIOS, and which has full control of the computer.

This real-mode code then loads vmlinuz, which itself is a compressed file with two components, being a compressed 64-bit-only runtime kernel and a combined 16-bit/64-bit loader, whose job it is to set up 64-bit long mode, copy the kernel parameters and the BIOS information about the hardware to a memory location that won’t get overwritten during the switch of the processor from real mode into first 32-bit protected mode, then PAE mode (32-bit with 36-bit memory addressing and an extra pagetable) and then eventually, full 64-bit long mode, and to then unpack the runtime kernel and pass control of the machine to the kernel.

The native UEFI version of grub however is an EFI executable — i.e. an extension of the UEFI — and like the UEFI itself, it is (due to Microsoft being on the UEFI Committee) Windows executable code, which exclusively runs in 64-bit long mode.

The vmlinuz binary can detect how it was invoked, and in the event of a UEFI boot, it will bypass all of its code for copying BIOS information and initializing long mode, because this has all already been set up by the UEFI itself, and information about the hardware can thus be passed on from the UEFI to the runtime kernel without needing to be copied to a protected memory address first.

The risk of having inadvertently installed operating systems with different boot modes on the same computer stems from the way the early UEFI implementations were set up. You only had the option of either a native UEFI boot with Secure Boot enabled, or a legacy BIOS boot.

Booting in UEFI mode without Secure Boot switched on was generally not offered by brand-name computer manufacturers, because those computers all left the factory with Windows pre-installed, and even though Windows itself did not even require UEFI yet at that point — never even mind Secure Boot — the “Designed for Microsoft ® Windows®” certification demanded this configuration from the manufacturers.

Independent motherboard vendors would commonly just continue offering motherboards with a legacy BIOS at first, and it was only a while later that one could buy motherboards with a UEFI but without any Secure Boot keys and with Secure Boot switched off.

8

May this help:

Short: one system is the master, the second must be loaded via chainloader,
(similar described for windoofs elsewhere) so the updates of each system will go correct…

9

Even if he reinstalls manjaro grub as the main grub, it may remedy the situation only temporary. Better to use refind or just do not bother with the bootloaders and use the EFI, if the os-es are on different disks physically.

10

If OP removes grub package from OpenSUSE as suggested, OpenSUSE cannot replace Manjaro GRUB as primary OS