I have Windows, Ubuntu, and now EOS.
After installing EOS, grub worked as expected and I was able to boot into all three OSes.
Then I booted into Ubuntu, ran into an issue, and performed a TimeShift restore on the Ubuntu partition. This reinstalls grub.
So I ended up with Ubuntu’s grub, with an entry for EOS – but the EOS entry doesn’t work. I just see a black screen.
I tried switching the BIOS to boot to EOS, but the EOS grub is currently broken.
Ideally, I want to keep the Ubuntu grub, since I have it, but fix the EOS entry in it.
I hope all this is clear. I am posting from Ubuntu, since I can’t currently boot into EOS.
but instead, this is generated by your Ubuntu version of grub:
initrd /boot/intel-ucode.img
The easiest solution is to use EndeavourOS grub but if you want to continue using the Ubuntu version of grub, you will need to edit the “initrd” line of all “menuentry” s for Arch based systems.
Alternatively, you could disable or uninstall os-prober and manually create the entries for your Arch based systems in /etc/default/grub.d/40_custom
You will better served by having EndeavourOS run the grub (once you get back in) as it knows how Basically it is an os-prober fault, and it is trying to boot the wrong kind of file as initrd. There are several ways to ‘fix’ the issue, but the fastest is to edit grub.cfg on Ubuntu so the EndeavourOS entry reads like this:
Working entry
menuentry 'EndeavourOS, on linux-zen' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-zen-advanced-538b9f7d-c154-49af-be53-6f2e88747d6a' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 538b9f7d-c154-49af-be53-6f2e88747d6a
echo 'Loading kernel linux-zen ...'
linux /boot/vmlinuz-linux-zen root=UUID=538b9f7d-c154-49af-be53-6f2e88747d6a rw loglevel=3 quiet
echo 'Loading initial ramdisk ...'
initrd /boot/amd-ucode.img /boot/initramfs-linux-zen.img
}
then pass control back to EndeavourOS from then on (as anything that causes Ubuntu to rewrite grub.cfg will overwrite the temporary fix.
(This is from one of my systems, so it uses linux-zen, but that doesn’t affect the problem with trying to boot with the ucode file instead of initramfs!)
Thanks to all for the valuable info.
I will edit the relevant files if and when necessary.
In the meantime, I went the no-brainer route. I ran TimeShift again in Ubuntu, but this time, I told it to restore the EOS partition. It properly installed grub for EOS, and all I needed to do was change the BIOS boot order to place EOS first.
EDIT: My memory failed me, in fact TimeShift did NOT fix the grub. The thing that worked was I booted my MX Linux live usb and used the grub fixer tool. Then I sorted out the BIOS boot order.
If I remember correctly from when I had a Ubuntu-Arch dual system, whenever there was an update to Grub on Ubuntu side, it put itself back in the top of boot priority in UEFI settings. So I had to change it back to Arch again.
Since in a multiboot system it is sufficient to have Grub bootloader installed only in the OS that control the boot process, in this case ENOS, it can be removed in the other OS:es present in the system.
It serves no purpose at all to have Grub installed in all the systems.
Since the one from Arch is capable to boot Ubuntu and your Win system, you could, if you choose so, remove Grub in Ubuntu altogether.
The only downside of such an approach would be if Arch’s Grub were to be hit by such a bad bug to render it completely useless. That is unlikely to happen but you never know with probabilities
All very true - but not the only truth! I only use grub on Garuda, because of the bootable Timeshift entries for grub. Even then, I call it from rEFInd, which is a much better multi-boot solution. Of course, I am biased, as I run it on this machine (5 distros) and my older one (8 distros) without effort or constant regeneration of grub.cfg!
Truth cannot be but one but perhaps there are multiple ways to arrive at it?
In this case it is true that you can create a perfectly functioning multiboot system. Using Grub or rEFInd are only two different ways (of perhaps some more) to achieve it.
I guess when @dalto logs in to the forum, we will have a third way as well.
Yup - Garuda defaults to btrfs, and uses Timeshift and grub to keep 5 snaps ‘online’ - along with the setup that does a snapshot before running pacman upgrades. Never needed any of them, but I guess it’s nice to have!
If I actually decided I needed snpashots, either I would go though the setup for using btrfs/snapper/refind together for snapshot bootability - or more likely learn enough ZFS to run everything on that!
As for the third alternative, I’m quite sure that with enough effort and configuration that systemd boot can handle multi-boot too, as you implied!
It all comes down to one’s tolerance for simplicity of use vs simplicity of concept I suppose…l
I do use Timeshift and grub-btrfs to make snapshots of my current EnOS on btrfs and add them to Grub boot menu. But I only make the snapshots on-demand before some “major” updates and not all the time when pacman is run.
I have only had to use them to rollback the system once or twice due to my own modifications to the system that I wanted to be easily reverted.
Sounds easy enough to implement with a couple aliases to determine whether to update, or snap-and-update I guess. Personally, I have only had to revert the updates themselves, and I use my shifttime script for that! (Arch archive-based reversion). Most of the rest of the configurations I do are preserved in a directory on my data drive, where they are pulled when installing a new system, and so easily accessed in case of need. Things like some fonts, themes, extensions for code along with a pkglist.txt to install from!
Enjoy your coffee! The script, BTW, is also on our Wiki (Under Pacman category - something like Easy Downgrade by Date). A better version is ‘in development’ at the moment, but the functionality is OK on the original - just less forgiving of entry errors!
Doesn’t that mean that every time you need to update grub, you need to boot into the other OS? I would probably just add a manual entry for EOS on the Ubuntu side and disable os-prober.
Gee - I didn’t know I could do tricky! An earlier install of Garuda I managed on ext4 - but I found that Timeshift sucked in rsync mode! I went with the default btrfs the next time
You are right!
Frankly, it has been quite a while since I tried a multi-boot system with only one of the in charge of the boot. I had forgotten the hassle of booting back and forth.
This sounds like the smoothest way to solve it. So either as suggested by @kjw or a custom.cfg?
And let Ubuntu be in charge of the Grub?
I didn’t know that. They are quite restrictive then how a system should be setup.
Yes, I would do it as suggested by adding and entry to grub.d.
At that point, it won’t matter. Ubuntu grub will have a manual config for EOS and EOS grub should be able to auto-detect Ubuntu. You can happily let them fight back and forth.
I just remove os-prober on the other OS so it only updates the grub on that machine. EOS controls the grub for all and has os-prober installed and set up. If the OS updates it’s grub it’s only if you are booting from it and it won’t have the other OS in it anyway. I do this even when using rEFInd so that i don’t have the other OS in each grub bootloader because i launch from rEFInd and then grub loads the OS.
Hmm, I am in Ubuntu right now and I can’t find the file with the menu entries.
This is my /etc/default/grub:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
and /etc/default/grub.d/init-select.cfg:
# Work around a bug in the obsolete init-select package which broke
# grub-mkconfig when init-select was removed but not purged. This file does
# nothing and will be removed in a later release.
#
# See:
# https://bugs.debian.org/858528
# https://bugs.debian.org/863801
I ran TimeShift without reinstalling grub this time but it still killed my OES grub for some reason
Basically it is an os-prober fault, and it is trying to boot the wrong kind of file as initrd. There are several ways to ‘fix’ the issue, but the fastest is to edit grub.cfg on Ubuntu so the EndeavourOS entry reads like this:
I didn’t know that. They are quite restrictive then how a system should be setup.