Dual boot Debian 12 and EOS Plasma

[ricklinux]

@jfabernathy
So i went ahead and installed debian again and then created the partition on it and then installed EOS with reuse partition. It’s not a problem as it then boots to EOS and then you update grub after setting os-prober. But the issue is that it knocks out my Kde install on the other drive. So i have to arch-chroot and reinstall grub and update it. Then it boots on my Kde.

Edit: So then i have the option to boot debian and i can add eos to it. But if i run the os-prober and update grub on that EOS install it would again wipe out my Kde install on the first disc. I’m not sure why other than the folder in efi is named endeavouros even though they are on different drives?
I don’t know and it doesn’t really matter to me as long as i understand what works and what doesn’t on my hardware because on someone else’s it may be a different outcome.

[samarium]

My guess is that you are getting the efi endeavouros grub entry overwritten because that is the default name of the bootloader for EOS, and I “think” that EFI only looks on the first drive, unless, maybe, you tell it to boot the second drive and then it possibly looks for an EFI partition there. I haven’t done the dual boot drive experiment, so don’t know. You could do find /boot/efi -ls | grep -i \.efi\$ to see the modify times of all the efi files which might help clarify things, and you could check the second disk for EFI partition and efi files to I guess.

I just rebuilt my EFI boot entries from scratch using efibootmgr, however I didn’t have two installs wanting to use the name endeavousos, as I had explicitly renamed them.

If you want multiple EOS installs to co-exist with grub, then I do it with GRUB_DISTRIBUTION, and maybe you should try the following:

• copy /boot/efi/EFI/EndeavousOS/grubx64.efi somewhere safe so you can reinstall if you want
• stash a copy of efibootmgr | grep -i \.efi\$ so you have a reference if you want to rebuild with efibootmgr
• update /etc/default/grub so GRUB_DISTRIBUTION=name1
• rerun grub-install which should pickup GRUB_DISTRIBUTION and create /boot/efi/EFI/name1/grubx64.efi and add name1 to the EFI boot order, probably first
• since grub isn’t a new version, you don’t need to run grub-mkconfig, but it shouldn’t change, you can always run -o /tmp/grub.cfg and then diff /tmp/grub.cfg /boot/grub/grub.cfg.
• boot the second EOS install and repeat with name2, as I think that the grubx64.efi is build to know where to find it’s modules and grub.cfg, so would be /boot and /boot/grub location dependent, so you can’t just copy the grubx64.efi from name1 and construct an entry on the EFI partition for name2
• if you check the grubx64.efi files they will be different where the /boot /boot/grub locations are different, ie md5sum /boot/efi/EFI/*/*.efi

[ricklinux]

@samarium

My guess is that you are getting the efi endeavouros grub entry overwritten because that is the default name of the bootloader for EOS, and I “think” that EFI only looks on the first drive, unless, maybe, you tell it to boot the second drive and then it possibly looks for an EFI partition there.

I agree that it probably just overwrites it because of that reason. I have no proof other than i know that it destroys the UEFI boot entry every time. I don’t want to bother going through all that is needed to understand why. The only thing that matters to me is that i understand how my hardware works when i do this or i do that. I’m only doing what i know fixes it. I don’t think it’s changing anything to do with where the files are located. It just overwrites the original entry with a new one that happens to be on a different drive.

[jfabernathy]

Here’s one to try. I follow discussions on BTRFS on the Kubuntu forum and have learned a lot over the years. The link below is to a discussion about multi-boot from a singe BTRFS partition with multiple subvolumes. I may try this on a system that isn’t critical.

Dual boot from single parition

[ricklinux]

Thanks this might be helpful sometime.

[jfabernathy]

So I found out a little more. Not good. My system was working with the following disk layout:

/dev/nvme0n1p1 fat32 ESP
/dev/nvme0n1p2 btrfs debian 12
/dev/nvme0n1p3 ext4 eos hyprland

To get the default grub to show debian 12 as OS 1 and EOS as OS 2 I had to sudo grub-install /dev/nvme0n1
and then edit /etc/default/grub and uncomment the os-prober disable.

However when I went back and booted my EOS install USB key I did a manual partitioning and selected the same ESP partition but had it use KEEP option and reused the EOS partition from before but reformat it to btrfs.

So now the default grub menu is the EOS one and os-prober enabled makes no difference. If I use F11 and boot back into debian 12 reinstalling grub there has no effect. So I can make either OS’s grub the default but I can’t seem to have both as before.

Not a huge deal as my debian is the one with my email, media stuff, etc. The EOS i3wm will be for learning WMs. I don’t think os-prober likes 2 btrfs boot partions to probe.

Looks like I’ll need to dig a little deeper

[ricklinux]

Do you do the same on Debian. It has a grub file also to set if you are running the grub update command on it.

[jfabernathy]

@ricklinux

Do you do the same on Debian. It has a grub file also to set if you are running the grub update command on it.

I removed the comment that disables the os-prober thus enabling it on both EOS and Debian. I reinstall grub on both OSs. and run update-grub on both. All this does is make the default grub the last OS that ran reinstall grub.

In reality, just leaving it on Debian is my personal default right now so no intervention is needed. whether I have to hit F11 or move the cursor to the EOS entry is about the same to me right now. Since I change what’s on the 2nd OS so frequently, I may just start using EXT4. Snapshots are really only needed where I don’t want a complete reinstall on my main system. booting from a snapshot and restoring is quicker. But switching between i3wm on EOS and Hyperland on EOS is quick and I keep my .config/ stuff on a NAS

[ricklinux]

@jfabernathy

All this does is make the default grub the last OS that ran reinstall grub.

Yes. It also doesn’t matter to me which one boots because you just select what ever you want when starting the computer. My issue installing EOS takes over the drive that boots in UEFI because of the naming i think. Both are the same name so it just seems to overwrite the UEFI entry. But that’s also not that big of an issue. I can fix it easily.

[samarium]

I’m currently tracking down an ext4 grub boot problem. I can easily maintain multiple grub boot environments on the EFI and maintain the boot / selection order with efibootmgr -o, and if I want to designate the next boot, efibootmgr -n. Where I would have multiple conflicting EndeavourOS installs, I override the name of the one I want to keep, in this case with GRUB_DISTRIBUTOR=eos in /etc/default/grub, as this is easier than constantly updating testing installations. In the case of testing, I specify a tmp GRUB_DISTRIBUTOR, so I get a tmp EFI install / name.

# grub-install --module="ahci gzio" --compress=no --recheck -v > /tmp/ev 2>&1 && efibootmgr -o 0,1,2,3,4 -n 4 | grep 000[0-4] && grep mkim.*core /tmp/ev && grep GRUB_DISTRIBUTOR /etc/default/grub | tail -1 && find /boot/efi | grep grubx64 | xargs ls -ltr
BootNext: 0004
BootCurrent: 0003
BootOrder: 0000,0001,0002,0003,0004
Boot0000* sirpool	HD(2,GPT,b533a913-5d1b-4345-a597-2f89085942de,0x800,0x200000)/File(\EFI\sirpool\grubx64.efi)
Boot0001* altRoot	HD(2,GPT,b533a913-5d1b-4345-a597-2f89085942de,0x800,0x200000)/File(\EFI\altRoot\grubx64.efi)
Boot0002* endeavouros	HD(2,GPT,b533a913-5d1b-4345-a597-2f89085942de,0x800,0x200000)/File(\EFI\endeavouros\grubx64.efi)
Boot0003* eos	HD(2,GPT,b533a913-5d1b-4345-a597-2f89085942de,0x800,0x200000)/File(\EFI\eos\grubx64.efi)
Boot0004* tmp	HD(2,GPT,b533a913-5d1b-4345-a597-2f89085942de,0x800,0x200000)/File(\EFI\tmp\grubx64.efi)
grub-install: info: grub-mkimage --directory '/usr/lib/grub/x86_64-efi' --prefix '(,gpt8)/grub' --output '/boot/grub/x86_64-efi/core.efi'  --dtb '' --sbat '' --format 'x86_64-efi' --compression 'auto'   'ahci' 'gzio' 'ext2' 'part_gpt' 
GRUB_DISTRIBUTOR=tmp
-rwxr-xr-x 1 root root 294912 Jun 18 16:04 /boot/efi/EFI/altRoot/grubx64.efi
-rwxr-xr-x 1 root root 217088 Jun 21 15:55 /boot/efi/EFI/sirpool/grubx64.efi
-rwxr-xr-x 1 root root 139264 Jul 27 23:38 /boot/efi/EFI/EndeavourOS/grubx64.efi
-rwxr-xr-x 1 root root 139264 Jul 28 22:05 /boot/efi/EFI/eos/grubx64.efi
-rwxr-xr-x 1 root root 212992 Jul 29 15:44 /boot/efi/EFI/tmp/grubx64.efi

I just run this line each time, and it maintains the efibootmgr settings I want as well as compiling and installing grub with the tmp label so I don’t break my existing grub EFI selections and lets me know current status.

I don’t expect you will need anything this complex, but GRUB_DISTRIBUTOR and efibootmgr -o/-n are useful things to have in your toolkit.

[pebcak]

@jfabernathy

I don’t think os-prober likes 2 btrfs boot partions to probe.

Fwiw, I post this once again

@pebcak

@jfabernathy

When I rebooted after install, I came to the grub menu with only EOS as a choice and it booted fine. I uncommented the GRUB_DISABLE_OS_PROBER=false
Then I ran grub-mkconfig. However, no changes when I rebooted. Still only one choice.

Currently, all my systems are on EXT4, each with it’s own ESP.

However, I do remember, when I was trying to set up dual/multi -boot systems on Btrfs quite some time back, that the the “regular” os-prober didn’t pick up other systems on Btrfs. I had to use a patched version for it to be able to detect the other systems.

Here is the package in AUR if you want to try it:

https://aur.archlinux.org/packages/os-prober-btrfs

You could build Manjaro’s os-prober as well, as theirs is also patched for it to detect other systems on Btrfs on the disk if I remember correctly.

Packages / Community / os-prober · GitLab

Good luck!

[jfabernathy]

I went back and repeated my EOS install but used ext4 this time and after I reinstalled grub on Debian 12, it could find EOS and update it’s grub menu.

So now I’m back to dual booting via grub using the grub on Debian. It seems that a system running with BTRFS is not the problem, it’s the OS-prober not picking up a btrfs system other than itself.

[ricklinux]

I’m not so sure? I think it has to do with conflicting eos installs for me. I’m going to try this again when i get some time? Are you just installing EOS on the same drive with Debian and the first install is Debian 12? Then you are installing EOS on the same drive with Debian using either btrfs or ext4?

Edit: Sometimes the more i think i learn the dumber i feel!

[jfabernathy]

I have one nvme partitioned as:
/dev/nvme0n1p1 fat32 ESP
/dev/nvme0n1p2 btrfs Debian 12
/dev/nvme0n1p3 ext4 EOS - Hyperland

Debian had the whole drive before I started and I used gparted to reduce the size of the debian partiton to give me 500GB for EOS.

Then I booted the EOS install key and did a manual partitioning where I set the mount point for the ESP partition to /boot/efi and to keep the data, which it didn’t. I created the EOS patition as ext4 with mount point of /. The install was without a desktop so I could install hyprland using the Sol Does Tech HyprV4 script from github.

After install, the default boot was EOS with no mention of Debian. I used F11 to boot back into Debian and reinstall grub and after that it sees EOS and Debian and updates the system to use Debian grub by default.

Debian had previously been setup to use OS-Prober.

[knwt]

Why not install EOS to the same BTRFS as debian using subvolume. You need to make a snapshot of current subvolume /@, /@home to new like /@debian, /@debian_home. Edit grub.cfg to point to the new subvolume. Mount @debian to /mnt, edit /mnt/ect/fstab to new subvlume @debian, @debian_home.

After booting to new subvolume ok, boot usb and install EOS, manually select the same BTRFS for /.

[jfabernathy]

That’s basically what the post above talks about. I may try that on a clean ssd to save what I have now.
post no.23

[samarium]

Correct re os-prober visibility.

Both ext4, and os-prober on both can see the other.

Both btrfs and need a os-prober on each that can see other btrfs installations.

As long has you have different OS name or GRUB_DISTRIBUTOR in /etc/default/grub then you should get different efibootmgr entries, so can boot the other using that entry.

No idea about the dual install inside btrfs, but would seem to require os-prober to be able to handle it. I don’t generally use btrfs, so no idea, but it is an interesting option. I’m basically trying to the the same thing with zfs rather than btrfs, and making slow but steady progress.

Either os-prober needs to recognize the situation and deal with it or you need alternate scripting in /etc/grub.d to detect the other installs and generate the boot menu entries.

[jfabernathy]

@jfabernathy

Here’s one to try. I follow discussions on BTRFS on the Kubuntu forum and have learned a lot over the years. The link below is to a discussion about multi-boot from a singe BTRFS partition with multiple subvolumes. I may try this on a system that isn’t critical.

Dual boot from single parition

So I tried the Dual boot from a single 1TB partiton and got it working. I have in my Grub Menu, Kubuntu, EOS, and Debian 12 all with Plasma KDE DE. Now I’m going to try adding EOS with no DE and then add Sol Does Tech’s Hyprland.