How to have a custom Grub2 menu that is maintenance free

[Dennis N]

You may be able to just copy Arch menuentry from the Arch grub.cfg and use that in your Ubuntu custom menus.

I use Manjaro, and have done that to get Ubuntu to boot Manjaro. Otherwise, Ubuntu grub creates the same error when generating the Manjaro grub menu entry.

Manjaro is a distro based on Arch linux.

[1fallen]

You may be able to just copy Arch menuentry from the Arch grub.cfg and use that in your Ubuntu custom menus.

I use Manjaro, and have done that to get Ubuntu to boot Manjaro. Otherwise, Ubuntu grub creates the same error when generating the Manjaro grub menu entry.

Manjaro is a distro based on Arch linux.

+1 This also works.

[Cavsfan]

You may be able to just copy Arch menuentry from the Arch grub.cfg and use that in your Ubuntu custom menus.

I use Manjaro, and have done that to get Ubuntu to boot Manjaro. Otherwise, Ubuntu grub creates the same error when generating the Manjaro grub menu entry.

Manjaro is a distro based on Arch linux.

I had an idea that Manjaro did the same. Thanks for confirming that.

I just do not like editing the grub.cfg file for any reason. If my grub is on Ubuntu I'll use the falllback kernel.
But, I do like having it on Arch as I can use the normal kernel.

Grub updated on Xenial Xerus 16.04 this morning and I thought It might fix another problem I'm having with it but, it did not.
So, my grub will go back to Arch for the time being.

But, this bug needs to be fixed and the more people that sign on to it, the better.

[Dennis N]

I just do not like editing the grub.cfg file for any reason.

I didn't edit any grub.cfg when I did this, only copied the menu entry for Manjaro from the Manjaro /boot/grub/grub.cfg, pasted the copied entry into the template 40_custom file, then saved it in Ubuntu's /etc/grub.d. I created a new file, but you could add to an existing custom menu file. (You can have any number of custom menu files in /etc/grub.d. No matter - they all get merged into a single grub.cfg when you or the OS executes the update-grub command or its equivalent).

[Cavsfan]

I just do not like editing the grub.cfg file for any reason.

I didn't edit any grub.cfg when I did this, only copied the menu entry for Manjaro from the Manjaro /boot/grub/grub.cfg, pasted the copied entry into the template 40_custom file, then saved it in Ubuntu's /etc/grub.d. I created a new file, but you could add to an existing custom menu file. (You can have any number of custom menu files in /etc/grub.d. No matter - they all get merged into a single grub.cfg when you or the OS executes the update-grub command or its equivalent).

Oh, thanks for the clarification. In my Wiki I say to edit the /etc/grubd/40_custom file but, then save it as /etc/grub.d/06_custom so that it appears on top. (Ranch hand's original idea)
Then when you're sure all of the custom entries work you make 10_linux, 20_memtest86+ and 30_os-prober unexecutable so they no longer appear.

Just so you get some output on an update-grub execution, you do change the part it says not to change so you can add an echo line: (Drs305's original idea)

#!/bin/sh
echo 1>&2 "Adding system 1, system 2, etc."
exec tail -n +4 $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.

The +3 you change to +4 so that the 4th line is where execution starts (menuentry).

With Legacy/MBR partitioned systems, that works flawlessly but, so far on UEFI/GPT partitioned systems not so much...

D'oh! Now I see where you said you added it to your custom entry.

[Cavsfan]

@oldfred, I have an entire UEFI system and I wanted to have one grub in control of my system because grub keeps jumping around after an update.
So I tried the 1.8 section of the Wiki for efi:

sudo dpkg-reconfigure grub-efi-amd64

But, it did not ask me where to install grub at and just ended up installing grub to that partition, which is not the desired outcome.

On my old Legacy/MBR system,

sudo dpkg-reconfigure grub-pc

did allow me to move the asterisk from the disk to the partition to not have to worry about that grub installing or updating.

The efi command does not do that and I do not understand why. Any tips?

[oldfred]

With UEFI & gpt, only the ESP has asterisk which parted/gparted use to indicate the ESP.
Other tools like gdisk use different codes to indicate ESP. But with gpt only an ESP can or should have asterisk. Some have multiple FAT32 partitions and switch which is ESP by moving boot flag. But normally you only have one ESP per drive. I put an ESP on every drive, including larger flash drives.

Somewhere in the UEFI version of Ubuntu's grub, it is set to only install to the first ESP, not always sda (but usually), as it seems to work with NVMe drives when they are first.

I installed Fedora, just to see the difference in grub. And it did install to sdb, when I specified that ESP, so grub is configured correctly, it is some change Ubuntu makes to grub.

Ubuntu's grub also is hard coded to find the UEFI grub in /EFI/ubuntu/grub.cfg. They were updating grub with 18.10 and it installed to /EFI/grub which is standard grub2. But Ubuntu still booted using my old grub.cfg in /EFI/ubuntu, not the updated one with 18.10's UUID in /EFI/grub.
Ubuntu 18.04 similar error /EFI/grub
https://bugs.launchpad.net/ubuntu/+s...y/+bug/1781042
Ubuntu 18.10 Cosmic installed /EFI/grub
https://bugs.launchpad.net/ubuntu/+s...2/+bug/1775743

I always used (hd0,3) or (hd1,gpt4) type to find root partitions with grub. But always had issues when plugging in flash drives.
So I now am starting to use labels.

Some good examples here:
https://forum.manjaro.org/t/creating...tloader/3150/4

menuentry "Cosmic 18.10 on USB ssd test" {
    search --label --no-floppy --set=root cosmicSSD --hint hd2,gpt4
    configfile /boot/grub/grub.cfg
}

[Dennis N]

grub keeps jumping around after an update.

In the case of updates to grub, one solution is to only allow updating the grub packages on the controlling OS. That works for UEFI or BIOS. Mark the grub packages as 'hold' (or whatever term applies) on the other OSes.

Other Comments:

For Ubuntu 18.04 to always be the controlling OS, I copied it's grub files to another EFI system partition so that they won't be overwritten later by other Ubiquity installs. I had to regenerate the UEFI boot menu entry because of this with an efibootmgr command - but that's a one time thing. And you would also have to use efibootmgr to fix the boot order after installing any new OS, but that is even easier.

On UEFI, I think grub boot files for an OS will only be installed on an EFI system partition which must be FAT, not EXT4 so you can't install grub to the OS partition as we used to do in BIOS. UEFI firmware is only required to read FAT partitions.

[Cavsfan]

With UEFI & gpt, only the ESP has asterisk which parted/gparted use to indicate the ESP.
Other tools like gdisk use different codes to indicate ESP. But with gpt only an ESP can or should have asterisk. Some have multiple FAT32 partitions and switch which is ESP by moving boot flag. But normally you only have one ESP per drive. I put an ESP on every drive, including larger flash drives.

Somewhere in the UEFI version of Ubuntu's grub, it is set to only install to the first ESP, not always sda (but usually), as it seems to work with NVMe drives when they are first.

I installed Fedora, just to see the difference in grub. And it did install to sdb, when I specified that ESP, so grub is configured correctly, it is some change Ubuntu makes to grub.

Ubuntu's grub also is hard coded to find the UEFI grub in /EFI/ubuntu/grub.cfg. They were updating grub with 18.10 and it installed to /EFI/grub which is standard grub2. But Ubuntu still booted using my old grub.cfg in /EFI/ubuntu, not the updated one with 18.10's UUID in /EFI/grub.
Ubuntu 18.04 similar error /EFI/grub
https://bugs.launchpad.net/ubuntu/+s...y/+bug/1781042
Ubuntu 18.10 Cosmic installed /EFI/grub
https://bugs.launchpad.net/ubuntu/+s...2/+bug/1775743

I always used (hd0,3) or (hd1,gpt4) type to find root partitions with grub. But always had issues when plugging in flash drives.
So I now am starting to use labels.

Some good examples here:
https://forum.manjaro.org/t/creating...tloader/3150/4

menuentry "Cosmic 18.10 on USB ssd test" {
    search --label --no-floppy --set=root cosmicSSD --hint hd2,gpt4
    configfile /boot/grub/grub.cfg
}

Thanks for the reply! I'm just thankful that I can get to other grubs to boot into via BIOS. My Arch_grub option is always there.
Here is what my /boot/efi/EFI/ folder looks like:
Screenshot_2018-07-14_17-20-49.png

But, much of the time when I try to re-install the grub on Arch, it gives an error something about there is no more room.
Default was 128KB but I was able to get a 550KB partition and only about 43KB is being used, so if I boot into TTY2 I can install grub without any error.

Also, the folders have folders within them there appear to be the same files. Sometimes in BIOS it will show Arch_grub and another Arch-grub. Not sure what the other one is probably a duplicate.
Sometimes after a grub update on one of the Ubuntu systems, it will boot to a blue screen saying windows has a problem, etc. I think the Windows boot took over when I see that.
But, like I say, I can always get to a bootable grub via BIOS thankfully.

Even on every other Linux system besides Arch (Xubuntu and openSUSE Tumbleweed) where it fails to add the /initramfs-linux.img element to the initrd line.
I have to press 'e' and and add it to get to Arch or else use the fallback kernel. Then re-install grub there.

[Cavsfan]

grub keeps jumping around after an update.

In the case of updates to grub, one solution is to only allow updating the grub packages on the controlling OS. That works for UEFI or BIOS. Mark the grub packages as 'hold' (or whatever term applies) on the other OSes.

Other Comments:

For Ubuntu 18.04 to always be the controlling OS, I copied it's grub files to another EFI system partition so that they won't be overwritten later by other Ubiquity installs. I had to regenerate the UEFI boot menu entry because of this with an efibootmgr command - but that's a one time thing. And you would also have to use efibootmgr to fix the boot order after installing any new OS, but that is even easier.

On UEFI, I think grub boot files for an OS will only be installed on an EFI system partition which must be FAT, not EXT4 so you can't install grub to the OS partition as we used to do in BIOS. UEFI firmware is only required to read FAT partitions.

Thanks for the post! I guess you are absolutely right about UEFI boot, there is no longer an ext4 partition or disk that grub is installed to but, a partition that is vfat instead.
So, that explains that! I wasn't thinking about that part.

Oh, Fred I forgot to mention that I will try that custom entry again when I get a chance.