Install two EndeavourOS on two partitions of the same hard drive

Hi,

I’m new to EndeavourOS, I come from Manjaro and I installed Gemini a couple of days ago, and I have some questions right now:

1- In Manjaro I had two partitions, one with KDE and the other with GNOME, since I like to use both graphical environments. What is the best way to install another EndeavourOS on another partition using GRUB as a boot manager? (since I understand that there is no easy way to have both graphical environments installed at the same time on the same Linux, correct?)

I had EndeavourOS with KDE on my first partition, then, booting from the USB, I created another partition and installed EndeavourOS with GNOME on the second partition. But now when I boot into the GRUB menu it only shows me a single Linux, the GNOME one that I just installed, the KDE one has disappeared. I have tried enabling the os-prober option in the GRUB configuration file (GRUB_DISABLE_OS_PROBER=false) and I have launched an update-grub, but after restarting I see that it still does not detect the other system.

Therefore, I wanted to ask you what is the best way and the steps to follow to be able to install a second EndeavourOS on another partition so that it can boot with either of them from GRUB, I don’t know if there is any guide on this.

2- Regarding the previous question, if I installed EndeavourOS with systemd instead of GRUB, would it be much easier to do so? I’m only using GRUB because, taking into account that I’m using the unstable repositories, I’m using TimeShift in case at some point the system doesn’t boot due to an update and I need to boot with a btrfs snapshot to restore it.

3- When I went to install EndeavourOS with GNOME, I selected the “install along side” option of Calamares so that it would split the partition that I already had of type Btrfs. But when doing so, the second partition that it was going to create is of type Ext4, when I want it to be the same type, Btrfs, and Calamares does not give any option to change the type of the partition that it is going to create.

What I wanted to know is, is this a native Calamares problem, which does not allow it, or is it some issue with the installer configuration in EndeavourOS, which does not have this option included in the Calamares configuration file?

Is it possible you installed one of the systems in UEFI mode and the other in legacy BIOS mode?

Which unstable repositories are you referring to? Unlike on Manjaro, the normal repos are very fast moving.

It should be pretty easy either way.

That is true, but there is a workaround. Choose “Erase Disk”, then choose “btrfs”. Don’t go to the next step. Instead, switch to “Install alongside”. It should retain the filesystem choice.

Yes, Calamares does not support switching the filesystem in “Install Alongside”

1 Like

No, I installed both in the same way without touching anything in the bios. Should EndeavorOS automatically, during the second installation, detect the first system and add it to the GRUB menu?

Sorry, I bring up that Manjaro concept. I meant that I am also using the testing repositories (core-testing, extra-testing, etc.). For this reason, I consider it appropriate to use TimeShift to be able to boot the system from a snapshot in case of failure due to an update.

I was asking this because 2 years ago I opened a petition to Calamares about this matter, I was talking to them in the forum and they agreed that they were going to implement it since, logically, it is a lack of functionality. But I see that it is still unimplemented so…

Do you have a reason for doing that? The repo concept is quite a bit different than Manjaro, the benefits aren’t really the same.

As far as I know, there is no Calamares forum. I believe adding that functionality to replace partition was done last year. Prior to that, it was only on “Erase Disk”

1 Like

Well, the only reason is obvious: to have the updates available in the shortest possible time, even if they are in the testing phase (although that entails a risk of instability, of course).

Sorry, I was referring to this (actually I see it was a year ago, I thought it had been longer):

Returning to the topic at the beginning, does anyone know how to install two EndeavorOS in two partitions of the same hard drive? As I’ve asked before, when doing the second installation, should the process automatically detect the first system and transparently add it to the GRUB menu as it did in Manjaro?

I just want to make sure you understand that unlike Manjaro, the risk is higher and the benefit much lower. Most packages arrive in testing only a or two before they hit the main repo.

Some packages will soak a bit longer depending on what they are but it is typically a really brief window.

You can use the “Install alongside” option or the “Replace Partition” option.

No, because we ship with os-prober disabled. If you enable os-prober in /etc/default/grub and then run sudo grub-mkconfig -o /boot/grub/grub.cfg it should normally show up.

1 Like

Well, it doesn’t work for me. I have it activated in the configuration file:

GRUB_DISABLE_OS_PROBER=false

And I launch sudo grub-mkconfig -o /boot/grub/grub.cfg:

Generating grub configuration file ...
Found background: /usr/share/endeavouros/splash.png
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot:  initramfs-linux-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
done

But upon reboot, it still shows only a Linux entry in the GRUB menu.The other EndevaourOS partition with KDE is still not detected by GRUB.

Hi Chema and others
I hope you have found your answer and sorry to late post but in case it’s useful…

There’s lots of ways this can / should work. I can’t imagine why os_prober shouldn’t work, I used to use it years ago no problem, but I always found it slow and messy, and it seems to be rather frowned upon now. It’s easy enough to add any entries to the scripts invoked by grub-mkconfig to get whatever you want, check out /etc/grub.d/40_custom; this should do what you want even if os_prober is borked for you.

But I’ll tell you what I do, even if it’s a bunch of depricated and not generally recommended hacks. I’m a bios booter just because I know it and it works well, and anyway grub can bios boot GPT partitions no problem. I’m big on chain booting (booters booting booters) because it keeps things clean. I actually first boot syslinux because it’s easy and slick, and this is usually the only configuration I maintain. There’s nothing magical about syslinux otherwise, grub or anything else can chain boot partition booters the same as syslinux. Then every linux partition has it’s own grub installed to it’s own partition (NOT the disk boot sectors).

As such:

(bios) grub-install --boot-directory=/tmp/mnt/sdb1/boot --force /dev/sdb1

(efi) grub-install --force --removable --no-floppy --efi-directory=/tmp/mnt/sda1 /dev/sda5

Double check and fix these for your own partitions and linux system mount points ( ! )

These install methods map the grub code into block lists, which is a bit less robust than a boot sector install, but the only caveat really is you’ll have to reinstall grub if you move a partition around, it’s generally never a problem but the installer will complain to you, hence the force flags. But the benefit is every grub config is simple and isolated, you can quick boot the later booters and you’ll never see the secondary booters.

Alright, here’s an example of how I add a custom chainboot entry to my arch grub so that if syslinux starts to boot arch, but I want it to boot my gentoo instead:

cat /tmp/mnt/sda2/etc/grub.d/40_custom
(…)
menuentry ‘Gentoo’ --class gnu-linux --class gnu --class os $menuentry_id_option ‘(MY_GENTOO_UUID)’{
search --no-floppy --fs-uuid --set=root (MY_GENTOO_UUID)
configfile /boot/grub/grub.cfg
}

and here’s syslinux boot entries that boot 2 endeavouros’:

LABEL endy1
MENU LABEL Endy 1
KERNEL /boot/syslinux/chain.c32
APPEND hd1 3
TEXT HELP
Grub Endeavour 2024
ENDTEXT

LABEL endy2
MENU LABEL EndeavourOS
KERNEL /boot/syslinux/chain.c32
APPEND hd1 2
TEXT HELP
Grub endy endy endy
ENDTEXT


I note that syslinux is bios only, and the disk numbering is 0 based with the paritions numbers are 1 based.

hope this is useful!

Some other thoughts, I’m probably talking to myself, but anyway…

There should be no problem installing gnome & kde & other desktops on a single desktop if you’re inclined, but things get a bit bloated and messy; you will have full gtk & kde libraries and generally you might well have a suite of gtk apps and kde apps, they look and work a bit differently so this is possible but not elegant. If you have multiple desktop environments installed, you can select your choice every time you login, and any environment can launch applications built with any toolkits, though integration and consistency will suffer.

and IMO you don’t really want something more bloody bleeding edge than standard arch unless you are a developer and gung ho bug tester. No real advantage to a perpetually broken system.

But of course, you do you, have fun and learn what you love!

Another option, which I use with my current (3) EOS setup, is to only install a bootloader on the 1st system. Then I copy the EOS entries from /boot/grub/grub.cfg, adjust for the other systems. The following example is my /etc/grub/40_custom setup, running (2) separate EOS systems:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

# other virtual machine hosts
menuentry 'EndeavourOS with VirtualBox (linux-lts)' --class virtualbox {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod btrfs
	search --no-floppy --fs-uuid --set=root 183c5c34-6d51-418a-b3a1-db1bda7a8f89
	echo	'Loading EndeavourOS with VirtualBox ...'
	linux	/boot/vmlinuz-linux-lts root=UUID=183c5c34-6d51-418a-b3a1-db1bda7a8f89 rw nowatchdog nvme_load=YES nvidia-drm.modeset=1 loglevel=3 iommu=pt split_lock_detect=off
	echo	'Loading initial ramdisk ...'
	initrd	/boot/intel-ucode.img /boot/initramfs-linux-lts.img
}

menuentry 'EndeavourOS with VirtualBox (linux)' --class virtualbox {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod btrfs
	search --no-floppy --fs-uuid --set=root 183c5c34-6d51-418a-b3a1-db1bda7a8f89
	echo	'Loading EndeavourOS with VirtualBox ...'
	linux	/boot/vmlinuz-linux root=UUID=183c5c34-6d51-418a-b3a1-db1bda7a8f89 rw nowatchdog nvme_load=YES nvidia-drm.modeset=1 loglevel=3 iommu=pt split_lock_detect=off
	echo	'Loading initial ramdisk ...'
	initrd	/boot/intel-ucode.img /boot/initramfs-linux.img
}

menuentry 'EndeavourOS with VMware (linux-lts)' --class vmware-workstation {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod btrfs
	search --no-floppy --fs-uuid --set=root e946d336-6234-4f63-b0e9-535905679ad0
	echo	'Loading EndeavourOS with VMware ...'
	linux	/boot/vmlinuz-linux-lts root=UUID=e946d336-6234-4f63-b0e9-535905679ad0 rw nowatchdog nvme_load=YES nvidia-drm.modeset=1 loglevel=3 iommu=pt split_lock_detect=off
	echo	'Loading initial ramdisk ...'
	initrd	/boot/intel-ucode.img /boot/initramfs-linux-lts.img
}

menuentry 'EndeavourOS with VMware (linux)' --class vmware-workstation {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod btrfs
	search --no-floppy --fs-uuid --set=root e946d336-6234-4f63-b0e9-535905679ad0
	echo	'Loading EndeavourOS with VMware ...'
	linux	/boot/vmlinuz-linux root=UUID=e946d336-6234-4f63-b0e9-535905679ad0 rw nowatchdog nvme_load=YES nvidia-drm.modeset=1 loglevel=3 iommu=pt split_lock_detect=off
	echo	'Loading initial ramdisk ...'
	initrd	/boot/intel-ucode.img /boot/initramfs-linux.img
}

The advantages are that I’m only dealing with (1) GRUB and (1) UEFI entry; disadvantages are that if I decide to add another kernel to the other systems, I have to again add them manually.

Not being forced to install a bootloader is one of my favorite EOS installer features.