The small linux problem thread

GPT vs. MBR mismatch and dual-boot - best solution given where I’m at?

I’m preparing my wife’s machine for dual-boot between Ubuntu 22.04 and Win10, and got into an MBR/GPT conundrum. It’s a Coffee Lake system on an ASRock z370m mainboard. My intended procedure was the following:

  1. Install Win10 on an 1Tb NVMe on M2_1
  2. Install Ubuntu on a 256Gb NVMe on M2_2
  3. Configure CMOS to boot from the Ubuntu drive by default
  4. Configure GRUB to show Win10 alongside Ubuntu in the menu

Now I’m at step (4). After setting GRUB_DISABLE_OS_PROBER=false in /etc/default/grub, as we apparently have to do nowadays, update-grub still doesn’t find the Windows bootloader.

I believe I found the cause: It turned out the Windows drive was formatted using a DOS disklabel, while the Ubuntu drive had a GPT label:

$> fdisk -l
Disk /dev/nvme1n1: 953,87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: ADATA SX8200PNP    # <-- windows                     
Disklabel type: dos
Disk /dev/nvme0n1: 238,47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SAMSUNG MZVPW256HEGL-00000 # <--  Linux + Grub
Disklabel type: gpt

Why this happened I don’t know. In addition to not finding the Windows disk, update-grub also gave me this message:

Memtest86+ needs a 16-bit boot, that is not available on EFI, exiting

Having MemTest86 in the menu is handy, but not critical.

My questions

Would converting the Ubuntu/Grub drive to DOS/MBR solve both the issue with loading Windows, and the issue with loading MemTest86+? If so, can I get away with it without reinstalling Ubuntu?

Or is it rather recommended to use GPT for both disks (I guess that would require re-installing Windows)?

Or alternatively, can I get around the problem with booting Windows entirely without re-labelling disks, by some kind of chainloading?


It looks like you did a BIOS/MBR install of Windows - I didn’t think that was possible.

Once grub is booted in UEFI mode, it can’t run BIOS/MBR executables.

I suggest you reinstall Windows, and be careful to boot the installer in UEFI mode, perhaps by disabling legacy or compatibility mode in the firmware settings. Once an installer has been booted in BIOS/MBR mode, it can’t do a UEFI install, and vice versa. Then, run sudo update-grub in Ubuntu, and it should find Windows.

Yes it’s possible on drives 2TB in size and below.

if you can switch your uefi back to bios… some older boards have the option.

or you can convert the disk over which i found pretty painless following this guide

convert mbr to gpt windows 10

i dont have the option to switch back to bios rather than uefi.
but the hard drive was formatted for mbr and had little to no effect on the system or its booting.
when i realised and though it would be a benefit i tried it, it worked. couldn’t see a difference :smiley:

ubuntu i have no idea how to convert it or even if its possible.

Yes, interestingly both installer images booted from the same Ventoy-formatted USB stick. Although I switched boot drive from CMOS in between, maybe it had unexpected side effects (CSM is on).

I might go for that potentially non-destructive conversion method as a first try, and try to convert the Windows disk. Both installs are new so there is really nothing to backup, only a matter of saving time.

Google suggests I can non-destructively switch the Linux drive to MBR too. But its probably better in the longer term to go full UEFI, and I’ll have MemTest86+ on a nearby stick anyway.


1 Like

Looking for a quick fix for this.

I want to set all my IPs via dhcp, but I realized virtual dummy interfaces always generate random MAC addresses. I need to set a MAC address manually, but the constraint is that I want to only use the ip command. From what I’ve read online, it looks like the command would be something like this:

ip link add dummy0 type dummy
ip link set dev dummy0 down
ip link set dev dummy0 address ab:cd:ef:12:34:56

But I am getting

RTNETLINK answers: Address not available

Anyone aware of why this is? Should I not use a dummy, but a macvlan interface?


Ignore this. Apparently ab:cd is not allow. If you use 00:00:anything:else, it works.

My son’ s friend decided to mash the keyboard for the living room PC (20.04) and now it’s zoomed in and i can’t fix it. xrandr says its 1920x1080 60Hz and it’s not the accessibility Zoom feature…

Anyone got ideas - google hasn’t returned anything helpful

Did google change it’s Signing certificate ?
I am … so confused …

Look legit to the eyes… but i am not allowing this without more intel

Fedora 35

1 Like

Which desktop environment are you using? Gnome has a zoom feature in the accessibility menu. You’ll a small stick-figure person as the accessibility menu on the GDM log-on screen as well.