This happened again today for the fourth time and I need some help either getting Fedora 37 into the Mint bootloader menu or will need to figure out how to recreate the Fedora bootloader menu with Mint 21 included along with Windows 10. I just re-installed Mint after loosing things due to a graphics card upgrade and having to start all over again. Now again a problem, Mint did not pick up the Fedora bootloader in it’s Grub menu. After attempting to use the Mint live USB Boot Repair feature of selecting the most likely option to fix the problem there is no longer any files whatsoever in the Boot folder of Fedora. Everything has disappeared in the boot folder. I have had this problem several times, Mint does not recognize Fedora when creating a bootloader menu for Mint. I do not want to go through another many hours of reinstalling Fedora and all the package set up I have continuously created. I am not the sharpest tool in the shed when it comes to scripting/coding and command line details. Is there any way of getting back all the files that have disappeared from the boot folder that most likely have something to do with no menu entry for booting Fedora after installing Mint, both on the same hard drive? Generally when I install a Fedora operating system last it always picks up all of the other operating systems on the hard drives. I’m lead to believe when they say Mint is a lot like Windows, even the problem of never recognizing Fedora operating systems may be similar to Windows never recognizing Linux operating systems when creating it’s bootloader.
Not sure if it’s the same issue I have: I multi-boot several versions of Linux, plus Windows 11. GRUB configs do appear to get messed up, but I usually find that the last Linux config I installed contains all of the configurations in GRUB, it’s just that that config might not be the one you’re choosing when you boot.
In the (UEFI) BIOS, make sure that the boot order has the last OS you installed as the first/default choice. Then you should have access to all configs in GRUB.
On my machines if I hit F11 when the machine boots I get the option to choose between the different installations. The Linux installations don’t usually contain all the other Linux installations in the GRUB config, but the last one I installed usually does. The last one I installed isn’t typically the default that the BIOS chooses when booting. You have to change the order, or choose a different install at boot time.
You can (should be able to) change the boot order of the various OS configs you have on the machine in the BIOS.
As an example: I installed Windows first on my machines and then various Linux distros. If I don’t change which installation I want to boot into, Windows will be chosen as the default and there won’t even be a GRUB menu.
I typically install Debian next: its GRUB config knows about Debian and Windows.
I then install Kubuntu e.g.: its GRUB config knows about Kubuntu, Debian, and Windows; Debian doesn’t know about Kubuntu.
Finally I install Fedora. Its GRUB config knows about all the rest but the rest don’t know about Fedora.
It seems like GRUB finds previous configs but doesn’t update them with the new installation. I guess it has no reason to, assuming that you’re just going to use the one GRUB config, the most recent one. However, the BIOS might not have the same view of the world.
Good luck.
Installing another distro that uses grub may cause the grub from that distro to take over for booting. Since not all distros use grub the same way you need to make sure that the last one updated is the one you intend to boot with. Thus, if you want fedora to always control grub then you should always make sure the other distro does not update grub, or always update grub within fedora last.
I haven’t proven it to my own satisfaction but it does seem that the last distro distribution (whoops!) installed has the most complete GRUB config. This certainly appears to be the case on my own installations (as per the above example). It’s reasonable to presume that the GRUB update phase during the installation (I don’t think it’s just grub2-mkconfig but it may be) finds all the GRUB configurations on the system in /boot partitions and uses the most recent one based on the file time.
That is how things should work in the perfect world. For some reason when Mint is installed last it does not recognize Fedora as a menu entry option in it’s bootloader that is created upon installation of the operating system.
If you were to also add Debian or Ubuntu, Mint would recognize those operating systems yet have experienced the problem of Fedora being neglected on several occasions installing multi operating systems on desktops with two internal hard drives. They also advise in their instructions to use their live Mint trial and installer on usb flash drive with the Boot Repair program in case something goes wrong. Unfortunately I tried using that program to possibly pick up Fedora in the menu and made and error somewhere in selecting options that erased the entire Boot folder in Fedora37. Still there is a /etc/grub.d shell script and I was hoping there might be a way to recreate all the files that were lost in the boot folder that included efi and grub.cfg files. Then edit the grub.cfg file in Mint by adding a menu entry for Fedora.
If there is no way of correcting this problem I will have to use the long and tedious method of reinstalling Fedora37 and all the personal set up. This workaround is not a good solution since I have also experienced the loss of Fedora in the bootloader menu created by Mint after an update where grub is updated and the config files.
To avoid that you need to stay away from any updates to Mint where security adjustments might be needed for internet use. Again to complicate things when it comes time to move on to newer version you always run the same risk over again.
As a result of this problem is it a bad idea to have more than one Linux operating system on any computer? Alternatively, is there a way to solve this problem and fix all these menu entries so that all you operating systems appear on every bootloader menu and a way to switch from one operating systems bootloader to another and not loose the ability to start any of the operating systems as a result of missing menu entries?
No, at least not in my experience. I have several machines, with up to 4 Linux distros in a multi-boot configuration, plus Windows. The only problem I’ve had is when I perhaps unwisely had installed Debian Testing alongside Debian, Kubuntu and Fedora and an update to GRUB made the Testing distro lose links to the other distros. Moral of that story: don’t put alpha- or beta-level operating systems on a production-level machine, even if it is one renowned for stability.
I think theoretically yes: you’d basically have to copy the last boot.cfg file that contains all the distros you want to boot to all the /boot partitions on your machine. But this a) assumes that you have one good boot.cfg that contains instructions to boot all the operating systems, and you already said that the Fedora boot configuration has been destroyed, and b) it’s prone to only being a temporary solution that will be overwritten as soon as you update one or other installations that rewrites the boot.cfg file based on the sources in /etc/default, /etc/modprobe.d, and so forth)
You have to be very careful at installation, and have a good understanding of how you’ve partitioned disks, and how other operating systems that you’ve installed have. Back up everything and make copies of grub.cfg files along the way. Ideally, you wouldn’t try any of this on a machine that’s not for testing, in case you mess up the configuration.
This has essentially been my approach: get the all distros you want installed and working together first, before installing a lot of apps and creating a lot of user data (it hasn’t always been the case: I’ve installed other OSs after the fact and it’s been OK so far, but it’s more of a risk). It has involved many re-installations in some cases before getting everything working. And this does assume that you know a priori what distros you want to install.
The Key to success is: do not install grub for every other Installations. Choose the one disto, that should manage Grub and install it within. All other Distros go with (E)LILO or Kernel stub loader. This is a complex topic, so you should read something about bios/efi and Bottloaders, how they work and how to configure. Or, if you UEFI/Bios support it, do not use Grub at all and choose your desired Boot Image through UEFI.
Thanks for your time in response here most appreciated.
I realize it has been several days since my last reply here yet after unsuccessful attempts to correct this problem I decided to create another small 50GB partition next to the one operating system partition I lost by shrinking it’s size on the right side. I have reinstalled from the exact same live usb thumb drive of Fedora 37 and put together almost the same set up that I lost with software-applications. I can enter into this lost operating system partitiion with a 1.4tb size and have attempted to try different things to solve the problem. I have never run across anything like this from instructions or tutorials yet this is something I am experimenting with. I have from the boot directory of the newly installed Fedora 37 copied all the files in the boot directory over to the empty boot directory in the partition of the lost Fedora 37 operating system. Is there a possibility that if I change any files there with the UUID number from the newly installed operating system to the one located on the lost parition as found in either fdisk or gparted and then change any pointers in files from hd0, (new partition) to the (older partition location) will this be enough to get things started again with possibly an upgrade piped into the lost partition operating system from a usb live version of the Fedora 37 o/s? Simply out of trial and error (not really knowing what I am doing) I was able to get a package download from dnf using a live thumb drive to avoid the repo from installing this package into the boot directory of the newly installed operating system if I were to use that operating system since I was not quite sure which operating system the package would go to.
Anyway, I used the command; “dnf reinstall shim-* grub2-efi-* grub2-common” then I added a command to direct the input to the older lost operating system partition boot directory. I ran this through a terminal and dnf did download the requested packages yet I am not quite sure if they went to the thumb drive live version where they would be lost upon shutting down the thumb drive session or did the files go to the older partition. My train of thought was undecided at first upon which way to write the command simply a space between the dnf command to install the package and location or to have a piping symbol | between the two commands since dnf might by default update or install the package from the operating system you were running the command from.
Now I am wondering if the packages can be sent to the older partition that I am trying to fix through dnf this way is there a possibility that if I direct an update to this partition will this possibly correct the boot directory problem? All the same files are in the boot directory copied from the newly installed Fedora o/s partition. Anyone here have any suggestions, criticisms or corrections necessary?
If all else fails I can simply use the new installation of the operating system and pretend the brtfs partition of the older lost o/s is simply an ext4 data storage disc? I can access this partition and browse through the files with no problem and simply hide it by changing the flags to bios bootable through gparted or Discs.
Your comment here about bios bootable seems to imply that you may have installed one OS in legacy (MBR) boot mode and another in UEFI mode. Doing so would prevent using grub from one of those systems to boot the other.
That can be seen if you were to boot then run lsblk -f to see what devices are seen and how they are configured → what file system types exist on each partition.
That would make sense on one computer I run that does have a gigabyte’s bios for both legacy and uefi. That computer has four different partitioned spaces created by operating systems for bios. I believe one of these spaces is an old one for when I had Ubuntu on here temporarily due to an add on graphic card failure where I lost both Fedora and Debian. This computer was custom built and does not have any manufacturer name brand, a Gigabyte H170-D3HP motherboard.
(1rst partition) /dev/sda1 grub2 core.img 1.00mb bios_grub,
(2nd partition) /dev/sda2 ext4 1.00 GIB bios_grub,
(3rd partition) /dev/sda3 btrfs 1.64 Tib (first installed Fedora 37 lost)
(4th partition) /dev/sda7 ext4 /boot 1.00 GIB
(5th partition) /dev/sda8 btrfs /, /home 49.00 GIB (2nd installed Fedora 37)
(6th partition) /dev/sda4 fat 32 /boot/efi 977 MIB boot, esp
(7th partition) /dev/sda ext 4 1009.05 GIB (Mint operating system)
(8th partition) /dev/sda ntfs 983.61 GIB (Data Storage Partition)
(9th partition) unallocated 1.84
The 4th or 5th partition is where I believe the current bootloader menu is coming from now after installing a 2nd time Fedora 37, this menu has three options available; Fedora, Mint, Windows and obviously not the first installation of Fedora since the entire boot directory was erased by a Boot Repair application in the Mint Live Installer when I attempted to get the Fedora menu entry back on the new bootloader menu that Mint created after installation. There is another bootloader option in my bios that has only Mint and Windows available, oddly this menu calls Mint Ubuntu yet boots into the new Mint operating system and not a dead end to the removed Ubuntu operating system.
There may be a double problem with another older late 2000s decade old Dell Optiplex 780 computer that has only legacy cmos bios available and no uefi. This computer while upgrading Mint created the same problem, it created a grub bootloader without a menu entry for Fedora. I was viewing a You Tube video by a guy named Chris Tech that warned of a problem where Mint’s Operating System Prober fails to pick up Fedora operating systems. His suggestion was always install Fedora last, after Mint installation, still that becomes a problem when upgrades are necessary since you get stuck in a dead end when you need to upgrade Mint. Is this operating system probe oversight done deliberately or possibly a flaw? According to another video I was watching the creator mentioned that Linux has only 1% of the worlds entire operating systems on computers, and with so many different distro varieties they are all competing for that 1% of users. Not sure if that is simply an opinion or fact.