I’m running the latest Linux Mint as my daily driver. I have 3 internal drives partitioned as such
1TB SSD:
-1GB /boot/efi
-50 GB swap (I know this is huge but I’m not starving for disk space.)
-100 GB Linux Mint root
-100 GB Ubuntu 23.04 root
-760 GB for virtual machines (auto mounted at boot in Mint & Ubuntu)
240GB SSD - NTFS for Windows 10
1TB HDD - 700GB NTFS Data (Holds an offline copy of my One Drive) and 300 GB EXT4 Data (basically just a place to throw larger files I’m working with briefly.
I’ve triple booted before and GRUB automatically added an entry for Windows. All GRUB shows now is Ubuntu 23.04 and Mint plus the recovery entries.
Troubleshooting thus far:
-Booted from Windows 10 ISO with Ventoy and ran bootrec /scanos, bootrec /fixboot, and bootrec /rebuildbcd all completed successfully. I figured this would give me at least add a Windows option for my UEFI boot menu to start with, then I’d reinstall Ubuntu and let GRUB do it’s thing.
-I tried messing around with rebuilding GRUB after booting from a thumb drive but I wasn’t exactly sure what I was doing and didn’t want to render my computer completely unbootable.
There’s gotta be an ‘easy way’ to have GRUB scan for other operating systems rebuild it’s config. Worse case scenario I’ll reinstall all three OSes but that’s a pain in the rear. Any ideas?
Grub2 uses osprober to scan for OS’s.
You can run osprober on its own… it will just report what if finds
Which OS maintains the grub config files?
Go there and look at /etc/grub.d… you will see several files with names beginning with numbers. These are the files that control the making of /boot/grub/grub.cfg.
You may need to make 40custom file if grub (via osprober) can not find windows.
you can temporarily edit /boot/grub/grub.cfg to fix an issue, but the change will not be permanent, because grub.cfg gets overwritten . There may not even be windows entry in grub.cfg, because you dont get a grub menu item.
another option is to run grub at its command prompt, and try to boot windows using the grub commands (see the manual or find an example) . You cant do any harm trying this and you might find out what the problem is.
Did you do anything that might have upset the windows disk? eg a windows install or update.
What happens if you use the bios to tell it to boot from the windows disk ( I assume the bios default is to boot from the linux disk) . If you cant boot it that way there is something wrong on the windows disk… eg the windows bootloader is damaged.
There’s gotta be an ‘easy way’ to have GRUB scan for other operating systems rebuild it’s config
I assume you know how to use update-grub in Linux?
It should invoke osprober , scan the other OS’s , and rebuild grub.cfg.
Do it in the Linux that installed grub originally, not in the other Linux.
It is possible that osprober is disbled. Check that … Ubuntu used to come with it disabled
You enable it in /etc/default/grub
something like GRUB_DISABLE_OSPROBER=false
I will have to check that… running on memory
correction GRUB_DISABLE_OS_PROBER=false
Thank you for helping me troubleshoot and taking the time to write all that up. I apologize but I got impatient and fixed the problem by overwriting the MBR with Windows 10’s MBR via Win recovery thumb drive. This time the automated start up repair option worked. It nuked GRUB. Once I confirmed Windows ability to boot, I booted Mint from a thumb drive and nuked all the partitions on the 1TB SSD.
I did a fresh install of Mint. APT and Flatpak is currently plugging away installing all my apps. I have 200 GB set aside to install Ubuntu 23.04 (or maybe Fedora) over the weekend. It shouldjust work but I don’t need 23.04 for anything but to play around with. So that install can wait.
Going this route I didn’t have to reinstall Windows which is a gigantic PITA. Linux is so easy to reinstall. I have one huge command to add the LibreOffice fresh PPA, Veracrypt PPA, apply updates, and install all my apps in one shot.
Be careful when you install a second Linux.
You currently have Mint controlling grub and you want to keep it that way, I think.
So, on the second install, do not let the installer write grub anywhere… then Mint will remain in control of grub
Never do update-grub in the second linux… always do it in Mint.
Whenever the second linux has an install or an update that involves a new kernel,
you will need to go into Mint after, and do update-grub… so it will see the new kernel in the second OS.
Those are the ‘rules’ for keeping multiboot with 2 linuxes happy.
If you stick to that you should have no trouble.
This sounds like a good rule to be safe, tho I do not know if the grub from all distro of Linux are incompatible. I know from past experience that Manjaro grub wiped out the pointer to my Mint partition.
Gentoo grub is about the only grub config that will find and boot Windows, Arch based, and Debian based. If you boot Windows and Linux on the same drive, do not install grub, install EasyBCD in Windows and use it to boot Linux. If separate drives are used, never install grub in Windows. To be safe, I will usually unplug my Windows drive, and keep the Linux drive as the boot drive and let grub find Windows.
The issue is that it gets very confusing if you do update-grub in more than one linux, because then you are keeping 2 grub.cfg files. Which grub.cfg file will it use when you boot?
I am not sure… I think it will go to the one owned by the linux that last did grub-install.
Does anyone know?
If two Linux distros are on the same drive, then the last distro installed will boot first, regardless of update-grub or grub-mkconfig. You can use /etc/default/grub.cfg and use either the “saved” or assign a “grub-menu #” to the OS one wishes too boot first. I usually use the “saved” option.
That is a different thing… youbare talking about the ordering of items in the grub menu
What i was asking about was, if there are 2 linuxes on a disk, when the bios starts grub, how does grub know which linux to look at to get its grub.cfg file ?
I have always imagined that what happens is, when you do a grub-install ( or write grub from an install script) , the grub that gets written to the disk has to include some pointer, to tell it where to look to get the grub.cfg file. I think that pointer always points to the linux which installed grub. So the last install of grub determines which grub.cfg file gets used.
It´s a very interesting discussion.
Perhaps I was a bit lazy… or curious, so I just submitted this question to ChatGPT.
O.K., as always, take it with a grain of salt and it´s up for discusssion.
Here´s what it came up with:
In a dual or multiple boot scenario, GRUB (the bootloader) is responsible for loading the appropriate operating system. When the BIOS starts GRUB, it needs to know which Linux system to boot and where to find its configuration file (grub.cfg).
Your understanding is partially correct. When you install GRUB, it is typically installed to the Master Boot Record (MBR) or the EFI System Partition (ESP) of the disk. This is the initial stage of GRUB, known as the “stage 1” or the “bootloader stage.” This stage contains a small piece of code that is responsible for loading the next stage of GRUB.
The next stage of GRUB, known as “stage 1.5” or “core.img,” resides in the filesystem and contains more advanced functionalities. This stage is typically stored in the /boot/grub directory of the Linux partition where the GRUB package is installed.
When you install multiple Linux distributions, each installation has its own GRUB package and configuration files. However, only one GRUB bootloader resides in the MBR or ESP. This bootloader, which is usually associated with the last installed Linux distribution, knows how to locate and load the other Linux distributions.
The GRUB configuration file (grub.cfg) contains the necessary information to identify and boot the available Linux distributions. It specifies the location of the kernel, initramfs, and other boot parameters for each operating system entry.
When you start your computer, GRUB is loaded from the MBR or ESP and reads its configuration file to display the boot menu. You can then select the desired Linux distribution from the menu, and GRUB will load the corresponding kernel and initramfs, passing control to that Linux distribution.
In summary, the pointer you mentioned is the GRUB bootloader itself, which is installed in the MBR or ESP, and it uses the information in the grub.cfg file to determine how to boot the selected Linux distribution.
So it is saying that the grub bootloader is little more than a pointer to a grub.cfg file.
It doesnt say, but it implies, that it will always point to the grub.cfg file in the root filesystem of the linux that installed grub.
So yes, chatGPT has the answer, but it does not say it very clearly
The moral for linux multiboot users is… always keep control of which installed linux is in charge of grub… by only doing grub-install or update-grub from that distro.
Very interesting point Neville. I know I one time I had 4 Linux DIstro on one HDD. I believe they were Mint Cinnamon, Mint Xfce, Ubuntu, and Xubuntu. And maybe a 5th one Zorin. They all booted fine, but which one had the grub.cfg? I do not know. Since all of those Distro were Ubuntu related maybe that kept me from having a problem.
Just a guess, but maybe the grub menu stored in the EFI partition has the pointer to each Linux partition’s grub.cfg file. On my laptop I have 2 Distro installed. I am pretty sure that each Distro will perform a grub update when I update either OS. Maybe there is a way I could test / prove it.
Hi Howard,
The grub menu is not stored anywhere. It is generated on the fly, from the grub.cfg file
each Distro will perform a grub update when I update either OS.
Oh yes, both distros can do update-grub… and will each write a new grub.cfg in their
own /boot/grub partition. But only one of those grub.cfg files will be looked at when you boot… it will be the one owned by the distro that last did grub-install, or the distro that was last installed if you have never done grub-install.
Yes, you can get away with things like that.
If you dont know or cant remember which one has the active grub.cfg… how can you
find out? I dont know?..
Afterthought:
YES we do know…@4dandl4 said it…
The one at the top of the grub menu is the grub-controlling distro… as long as you
dont deliberately configure grub to change the order.
I think I would just go to the Linux I want to have in control of grub (ie the most stable one) , and just issue grub-install to move the pointer to that one
followed by update-grub to make sure its grub.cfg is an uptodate one
You can get issues if one Linux does a kernel upgrade. It will be ok if it is the grub-controlling distro, but if it is one of the others , you need to gontonthe grub-controlling distro and issue update-grub by hand, so it will find the new kernel.
No!!! I am saying you can have all the Distros you want, but only one is needed too install grub and use os-prober to find other entry’s, the boot order can then be set. And yes, a kernel-upgrade can muck up the whole mess, just went through this with Gentoo.
I apologize but I got impatient and fixed the problem by overwriting the MBR with Windows 10’s MBR via Win recovery thumb drive. This time the automated start up repair option worked. It nuked GRUB. Once I confirmed Windows ability to boot, I booted Mint from a thumb drive and nuked all the partitions on the 1TB SSD.
.