Ok! It will take a few days because I have to do much work till monday and this means that I have not the time to switch to Linux. I have checked diskpart and diskmgr in Windows. Both show the same result as lsblk. Windows is installed on nvme0n1. Part 1 is system reserved, part 2 is drive “C”, part 3 is the recovery partition.
Grub should be installed on a FAT32 partition, shouldn’t it?
I have never seen short a UUID.
At the moment both OS boot without problem. I am not able to read the grub.cfg, so I don’t see what is wrong. But I have found out that Windows boots when when I select “insmod part_msdos”.
As soon as he said that, I was silent, as I have not have had an MBR scheme disk in ages.
But the os-prober malfunctions on MBR Windows do seem abundant searching around. Especially with NVMe drives.
But where I was going for earlier, is using a /etc/grub.d/.. way. (And disabling os-prober.)
Depending how comfortable @Umbra_noctis is. There is a way you can test this first in the clunky grub command line (from hitting c upon booting). But it’s a little easier, to just attempt to boot your own menu entry. Which I believe should look like this for you..
As soon as he said that, I was silent, as I have not have had an MBR scheme disk in ages.
→ Sorry! I didn’t know that this was an important info.
Could you explain what you have written, please? I know I am inquisitive. I understand the exec command but not the rest of that line; the line “insmod part_msdos” and the line starting with “menuentry”
But the os-prober malfunctions on MBR Windows do seem abundant searching around.
Just thinking: Would it be safer to eliminate Grub completly and restore the Windows bootloader? Theoretically I should be able to enter Linux via Super Grub2 disk.
I have linked a tutorial (below) in hopes that you might find something useful in it’s content.
Note that I’m not suggesting you follow it to solve your issue, but there a portions that you might find invaluable in understanding multi-booting between Windows and Linux.
It tells grub to preload the driver module for an MBR partition table.
It creates a menu entry in grub for booting the Windows partition. The chainloader command passes the control of the boot process onto a secondary boot loader — in this case, the Windows boot loader.
If you toggled in the BIOS to boot the Windows disk, sure.. But that’s every time you wanted to switch OSs. That’s awkward to me, but it would work. (And you will still need grub or another boot loader for Linux.)
Most people will have GPT partition table types, and most people would not need to know this. And os-prober would not have messed up. (I am still only guessing at this, but I think it’s a safe guess.)
Most editing of grub configuration is done in /etc/default/grub, this is what as far as most people need. This is a special case for you, you need to create your own boot-entry/menu-item.
Each menuentry is just a selection in the grub boot menu when you first power on.
People running GPT disks will have something like this:
Something went wrong. Without the os-prober grub isn’t able to find Windows at all.
I tried os-prober now. It finds Windows but still Windows isn’t listed in the Grub menue. Tomorrow I shall try if update-grub with os-prober will work.
Then the first part did exactly as expected. os-prober was adding an entry that wasn’t working, we got rid of it.
Did you then add the menu entry in the steps above?
In involves creating a file from scratch, before the update grub command. (I don’t know your technical know how.)
But if you followed those steps (and created that file in /etc/grub.d), you should have a new entry in your grub menu. I was hopeful this one would work.
Are you sure you have to rebuild your initramfs for the kernel? (As we’re just trying to get to the Windows bootloader from grub.)
It was an instinctive copy/paste, but no, the important factor is to update the grub configuration.
The takeaway is to use the entry in /etc/default/grub as indicated GRUB_DISABLE_OS_PROBER=false to enable os-prober.
To disableos-prober, the line should be commented.
I’ll just add that creating a manual stanza was a fair suggestion considering the OP is booting as MBR.
As it’s likely a hybrid-MBR (on a GPT disk) and without an $ESP I should think that;
insmod part_gpt
insmod ntfs
set root=(hdX,gptX)
# set root=UUID=1234-5678 # or set the UUID
might still be needed, and maybe something like:
chainloader +X
X being the respective partition number in all cases.
Note: This is all from distant memory, and may not be accurate.
Because having os-prober active would cause some clutter in boot options, disabling it would have minimised that. This was a commonplace scenario in times of “MBR-only” systems.
The only problem was that os-prober was needed to discover their Windows boot loader.
I’m unsure whether the OP followed/understood your instructions, but I suspect all they might have done was to inadvertantly prevent os-prober from loading.
Not to trying overwhelm you @Umbra_noctis, but @soundofthunder and I are mostly on the same page saying different things.
I was thinking there is a language barrier here, but I’ll give this one last go. And I actually did overlook one step in my instructions (I forgot to say you have make the script executable.)
I’ll reiterate the instructions. One last time, maybe a little more clear, as they are spread out over multiple posts and it could use tidying up. (After, I’ll circle back to @soundofthunder’s post).
But for now here’s the way to add your own menu entry with my untested UUID method:
HOW TO: Add GRUB Menu Entry
Once os-prober is disabled, as it seems like one of the few things we successfully did, we can simply do this..
1. Create configuration
We need to contents in the block below, pasted or typed exactly into a brand new file.
(You can change the name from “Windows 10 (Legacy MBR)” to whatever you want if you wish.)
You can view the other files in folder with: sudo ls -l /etc/grub.d (And how it fits into the numbering, and how other entries work if you’re interested.)
3. Update grub
Self-explanatory..
sudo update-grub
reboot
You should have a new menu choice upon restarting.
And hopefully it boots Windows.
That was it for me.. All I wanted to throw in as I thought this was an easy thing to fix. And I still believe that.
I do not think the rest of this will help you @Umbra_noctis, as you do not communicate that you are even understanding any of this.
So I didn’t want to go down this rabbit hole now, because if the above works, this is not even needed. But all this is kind of important, for troubleshooting any grub related boot issues. And to top it off, this is harder to explain the grub command line. (Over the above method.)
From the grub menu at boot, at least on my keyboard, using the c key.
From there you can type out the commands interactively. So you type out:
insmod part_msdos
insmod ntfs
ls
Then you can see exactly which drive you want to be booting in, but I think yours will come up something like (hdX,msdosX) (not gptX).
Pick one of the partitions you think it is and run ls on it.
ls (hd0,msdos1)
bootmgr Boot/ System Volume Information/
The one with bootmgr is the one we want, and should look something like the above. You just have to try until you find it.
Once we know which one that is, then we can try booting that in grub notation.
set root=(hd0,msdos1)
chainloader +1
If it works, you can use those commands you typed, and go back to step 1 of the post, and use them in a working /etc/grub.d config.
All this is why I went with the UUID, even though I remember using the old hd0 notation too.
What makes you say it’s a hybrid-MBR disk? We would also need part_msdos having both, if that’s the case.
When using MBR, I’m pretty sure this has to be +1, as it’s the first sector, not partition. Let’s hope it’s not hybrid-MBR. (Still doable I think, for a person comfortable in Manjaro.)
Windows is installed to a disk with a GPT partitioning scheme and each OS is booting as Legacy (as established earlier) – it can be little other than a hybrid MBR.
On that point, I’m not 100% certain – my first instinct tells me it’s not needed for this GPT disk; there are no msdos partitions – though, I’ve not played with such configurations since the infancy of UEFI.
(Prior to that I preferred LILO – if I wanted Windows as part of a multi-boot scenario I’d simply strip a copy of the Windows boot sector to file (using dd) and load it with LILO)
As Windows resides on an NTFS volume on a disk with a GPT partitioning scheme, insmod part_gpt and insmod ntfs would be needed.
insmod part_msdos would be needed if Windows were installed to a disk with a traditional MBR partitioning scheme.
When read by gdisk/gptfdisk (or similar) there should be a protective MBR waving and shouting “Here I am, pick me! pick me! ”.
Maybe I wasn’t precise enough. I have had created the file in grub.d, disabled os-prober and updated grub. The result was that Windows wasn’t listed. I tried os-prober, it found Windows but it was still not listed in the grub menu. Then I tried update-grub with activated os-prober and Windows is now listed again. (But I don’t know if it is the “normal” Windows-entry or the additional file in the grub.d directory.) The last two days it booted without problem. I shall test it and shall report in aprox. ten days.
Be sure I am reading very carefully and I do be able to understand your English, I am just a little out of practise writing it. I also understand many commands but not all of them and I have very little experience with configuration files.
P.S.: I have not slightest idea why soundofthunder thinks that Windows is installed on a hybrid MBR. It isn’t.
Your own inxi output has shown that Windows is installed on a disk using a GPT partitioning scheme, and it’s booting as MBR (as previously established by others) – there is no $ESP – it’s not booting as UEFI.
If you can show any reasoning that defies information already provided by your own system, I’ll gladly defer to magical logic.
where you have maximal 4 partitions.
”.