Drive 2 partition 2 is my daily driver OS, which provides a boot menu that I have carefully customized using Grub Customizer.
Here comes Drive 1 partition 7, where I’ve installed the latest EndeavourOS ISO to test out DEs and other experiments I don’t dare doing on my daily driver.
The problem is, upon install of this EOS test instance, it has taken over boot menu and I can’t get it back. I have told it on install to set up its boot on Disk 2, as I want to have the Boot sector of the first disk untouched (Windows lives there and I don’t want to spook it out).
I was expecting boot to be taken over by the new test install, but was also expecting to be easily able to force my daily driver to take over again.
I’ve tried grub-install, grub-bios-setup, to no avail. Boot menu is still controlled by the new EOS instance.
This is only a problem when new kernels are installed because I then have to boot into the test EOS instance and make changes to the grub menu from there.
tl;dr:
I’d like to have my daily driver OS take over the boot sector of Disk 2.
I would like to have the boot menu controlled by my daily driver located in Disk2Part2.
If you boot into your test drive, that is drive 1 partition 7, and run efibootmgr -v, what does it show? Perhaps you could use efibootmgr to change the boot order and put back your daily drive back in charge of booting?
I was talking about boot sector because I have actually no idea how UEFI boot works
In my head I’m still stuck in my old BIOS understanding of how booting works.
I’ve tried fiddling around with efibootmgr but options 0000 and 0002 won’t boot at all.
I tried sudo efibootmgr -n 0000 and sudo efibootmgr -n 0002 but the PC hangs on a blank screen after POST
I’ve also tried sudo efibootmgr -o 0002,0001,0003,0000 but it doesn’t work, on the next reboot I see the sequence is restored to BootOrder: 0003,0001,0000,0002
On many machines, you can change the boot order with direct moves in the BIOS screen (perhaps from F8 ?). You might have a keyboard access to choose boot order, or (like mine) you can drag the desired one to the top of the list. Not everything HAS to be done from the command line!
That said, I should mention that rEFInd can also show you all the options it can find - and allow your choice to prevail (including any grub instances it finds). It also allows direct access to the Windows boot…
If it was me i would reinstall EndeavourOS onto the partition 7 that you originally installed it. I would install using manual partitioning and set the efi partition as disk 2 part 2. You need to set it as /boot/efi and flag as /boot. It has to be formatted to fat32 also. Set the partition 7 on Disk one as /root and install. You can use gparted to set these up first but you still have to go through the manual install and set /boot/efi and flag as boot and set the /root.
I would very much like to do just that. How would I go about doing that?
Unfortunately that is not really an option for me. I’ve tweaked the system to a to great extent and don’t really want to go about wasting hours to set everything back from scratch.
I have read concerns about Grub customizer only in the last months. I’m using this setup for almost a year now. So I’m stuck with it. I’d like to cleanse everything boot related and start from scratch, and this time I’d stay away from G customizer, I promise :P. I’d like to do this evidently without affecting current daily driver install.
...
(1/1) checking for file conflicts [##############################################################] 100%
(1/1) checking available disk space [##############################################################] 100%
warning: could not get file information for etc/default/grub
warning: could not get file information for etc/grub.d/
warning: could not get file information for etc/grub.d/00_header
warning: could not get file information for etc/grub.d/10_linux
warning: could not get file information for etc/grub.d/20_linux_xen
warning: could not get file information for etc/grub.d/30_os-prober
warning: could not get file information for etc/grub.d/30_uefi-firmware
warning: could not get file information for etc/grub.d/40_custom
warning: could not get file information for etc/grub.d/41_custom
warning: could not get file information for etc/grub.d/README
:: Processing package changes...
(1/1) reinstalling grub [##############################################################] 100%
:: Running post-transaction hooks...
(1/1) reinstalling grub [##############################################################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Updating the info directory file...
Grub was installed, but should I worry about those warnings?
Grub (IMHO unnecessarily) adds complexity because it uses information from /boot/grub/grub.cfg of other installed linuxes as well. Those other linuxes may have incorrect/outdated info about other linuxes…
So, one idea (that I haven’t tried yet!) is to uninstall os-prober from the other linuxes and keep os-prober only in the main linux.
Then generate grub on all other linuxes, and finally in the main linux.
That should make grub.cfg on the main linux much cleaner.
Another potential trick is to create file /boot/grub/custom.cfg and copy (and maybe modify) desired grub menu entries from grub.cfg there. This custom.cfg will be automatically used by grub.cfg, giving the boot grub menu some new entries.
Custom.cfg will not be overwritten by package updates of grub or os-prober.