1

After crash of an old HD disk, I bought a new SSD and would like to setup multiboot Windows 10 & Linux but I run into UEFI problems.

My disks:

  • /dev/sda is the new SSD. Linux Mint 21.3 is on /dev/sda5, and Windows 10 should be on /dev/sda1-4. To my understanding /dev/sda1 is an EFI partition.
  • /dev/sdb is a prior SSD I had. It has Linux Mint 20.3, and an old Windows 7 (I don't care about the Windows 7, I'd like to keep for now the Linux to recover some data).
  • /dev/sdc is an old hard disk on which I have a broken LVM2 partition. I don't care about it currently.

I would like to be able to multi-boot Linux Mint 21.3 and Windows 10. I can't manage to get it work!

  • I am unable to boot Windows 10 :(
  • When I run update-grub, or grub-customizer, it does not see my Windows 10. Note that os-probe is enabled.
  • I tried to add an entry in my GRUB for Windows 10, but at some point, you must provide some sort of UUID for the disk of Windows 10, and it does not look like a normal UUID like lsblk provides but something shorter. I have no idea what I should provide, and my attempts did not work (when I boot, it says it can't find that disk).
  • At some point, I changed the flags of the /dev/sda partition between boot, bios_grub and efr. I am unsure what flags should be set for /dev/sdaX
  • I assume my BIOS supports UEFI but I am not sure + I see no switch in the BIOS that would let me switch from Legacy to UEFI or vice versa. My motherboard is a MSI B75MA-P45.
  • I attempted Boot Repair utility from Linux Mint live disk, you can find my full layout there: https://sprunge.us/Lpnlrf Beware, /dev/sda was in the case the live USB mint, and my first SSD is therefore /dev/sdb, second /dev/sdc, hard disk /dev/sdd.
  • When booting Linux Mint 21.3, sudo efibootmgr -v answers "EFI variables are not supported on this system. And I have no /sys/firmware/efi. But I do have the packages grub-efi-amd64, grub-efi-arm and grub-efi installed.

Thanks for your help :)

6
  • All OSes should have been installed in UEFI mode, are they? Jan 16 at 22:17
  • As @ChanganAuto has asked are you migrating this Windows 10 install from a legacy MBR? If so, you need to use the conversion tool provided on the Windows 10 installer to convert the MBR style disk to GPT. If your BIOS doesn't have UEFI support, why are you installing in UEFI mode? Please provide your motherboard manufacturer and model.
    – eyoung100
    Jan 16 at 23:16
  • @ChanganAuto I do not know how to "install an OS in UEFI mode". During Linux install, what option should I have paid attention to?
    – user509010
    Jan 17 at 14:35
  • @eyoung100 this Windows10 was installed from scratch. It's not a migration from anything else. The disk wasn't formatted when I started installed Windows 10. I believe my BIOS has UEFI support but I am unsure how to check this. My motherboard is MSI B75MA-P45.
    – user509010
    Jan 17 at 14:37
  • 1
    How you choose to boot live installer UEFI or BIOS/Legacy/CSM, for both Windows & Linux is then how it installs or repairs. Boot-Repair looks like it was booted in BIOS mode and default tried to repair LVM install. Best to only boot in UEFI mode and use Advanced mode to choose an install & drive to install grub into. Mixed UEFI & BIOS is confusing any auto fix in Boot-Repair. Boot-Repair's comment on full drive for NTFS is a major probably for any NTF/Windows install, better to have 30% free.
    – oldfred
    Jan 17 at 15:07

1 Answer 1

1

/dev/sda is the new SSD. Linux Mint 21.3 is on /dev/sda5, and Windows 10 should be on /dev/sda1-4. To my understanding /dev/sda1 is an EFI partition.

When you ran the Boot Repair utility, the Mint Live disk you ran it from was recognized as /dev/sda, and your new SSD as /dev/sdb:

Disk sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk identifier: 88F93FC7-E70C-4253-845C-C3D93CC6658D
           Start        End    Sectors   Size Type
sdb1        2048     206847     204800   100M BIOS boot
sdb2      206848     239615      32768    16M Microsoft reserved
sdb3      239616 1257408925 1257169310 599.5G Microsoft basic data
sdb4  1257410560 1258528767    1118208   546M Windows recovery environment
sdb5  1258528768 3890251424 2631722657   1.2T Linux filesystem
sdb6  3890251776 3907028991   16777216     8G Linux swap

It clearly used to be a GPT-partitioned, UEFI-bootable disk, but because the Boot-Repair was booted in legacy BIOS style and/or because you may have toggled the partition type of sda1 from ESP to BIOS boot, it assumed it was working in a legacy BIOS system, and has now "repaired" this disk into a BIOS-bootable GPT disk.

This is an unacceptable combination for Windows 10: it requires UEFI boot on GPT-partitioned disks, and BIOS boot on MBR-partitioned disks. No other combinations are supported by Windows, and here "not supported" means "does not work."

Your Boot-Repair-generated GRUB boot menu apparently now allows you to boot Mint 21.3 (although Boot-Repair may have mislabelled it as "Ubuntu" in the boot menu), Windows 7, and the old Mint 20.3.

When booting Linux Mint 21.3, sudo efibootmgr -v answers "EFI variables are not supported on this system. And I have no /sys/firmware/efi. But I do have the packages grub-efi-amd64, grub-efi-arm and grub-efi installed.

It looks like your Mint currently boots in legacy BIOS style; this is probably Boot-Repair's doing. The fact that you have grub-efi-amd64, grub-efi and efibootmgr installed suggests that Mint was originally installed to boot in UEFI style.

The presence of grub-efi-arm would be a mistake, unless you are also developing ARM software.

/dev/sdb is a prior SSD I had. It has Linux Mint 20.3, and an old Windows 7 (I don't care about the Windows 7, I'd like to keep for now the Linux to recover some data).

Under Boot-Repair, this was recognized as /dev/sdc:

Disk sdc: 223.57 GiB, 240057409536 bytes, 468862128 sectors
Disk identifier: 0x000e99c8
      Boot     Start       End   Sectors   Size Id Type
sdc1  *         2048    206847    204800   100M  7 HPFS/NTFS/exFAT
sdc2          206848 266678271 266471424 127.1G  7 HPFS/NTFS/exFAT
sdc3       266678272 468861865 202183594  96.4G 83 Linux

This is MBR-partitioned, and looks like it may always have been BIOS-bootable. It also seems to currently have a GRUB configuration that covers Mint 21.3, Windows 7, and the old Mint 20.3.

My BIOS does not have any Legacy option, or UEFI option.

Clearly it supports UEFI, with a fixed preference on Legacy-style boot if any legacy-style boot targets are available. The fact that it provides no options to adjust that is unfortunate.

When choosing to boot from external media that is bootable in both styles (like Mint Live and most OS installation media), you should look carefully: is there just one menu item for the external media you're looking for, or is there two of them? If there is two, then one would be for the legacy BIOS-style boot, and the other for UEFI. When installing operating systems, the boot method used to boot the OS installer will also determine the boot method of the installed OS.

To make your Windows 10 work, you would have to first either convert your SSD from GPT partitioning to MBR style, or change the sda1 partition from "BIOS boot" back to EFI System Partition (ESP). In either case, you will then need to use the Windows 10 installation media's "Repair boot" functionality to rebuild the Windows bootloader of appropriate type (BIOS or UEFI). Be careful to boot the installation media in the appropriate mode.

After that, you would have to recover the boot of your Linux Mint installation(s). For that, I would recommed avoiding Boot-Repair: instead, you should just chroot into your primary Mint installation, ensure you have the GRUB packages for the desired boot process type installed: grub-pc and grub-pc-bin for legacy BIOS boot, grub-efi-amd64 and grub-efi-amd64-bin for UEFI without Secure Boot. If you also want Secure Boot support, you should add grub-efi-amd64-signed and shim-signed to the list.

With legacy BIOS boot, if your expected boot disk is not /dev/sda when chrooting, you should create a /boot/grub/device.map file to indicate which disk will be the first disk detected by BIOS when booting normally, e.g.

(hd0) /dev/sdb

if the situation is similar to when using Boot-Repair, i.e. the removable media appears as a temporary /dev/sda.

After creating the device.map file, you should run

grub-install --target=i386-pc /dev/sdb

to write a BIOS-style GRUB to the Master Boot Record of the disk that is currently sdb (but will be sda once booted without the removable media).

If you choose to boot in UEFI mode, you won't need the device.map file. The command to install UEFI version of GRUB is just:

grub-install --target=x86_64-efi /dev/sdb

where /dev/sdb is the disk that contains the EFI System Partition. If you want to support Secure Boot, add the --uefi-secure-boot option.

If you can't avoid booting in legacy mode from removable media to recover your Linux boot, but still want to set up for UEFI boot (which can be tricky given your BIOS offers no options to control the boot mode), you can install GRUB in UEFI removable media mode first:

grub-install --target=x86_64-efi --removable /dev/sdb

(Likewise, add the --uefi-secure-boot option if you want Secure Boot support.)

After this, you may have to explicitly select to boot from the SSD in order to have your Mint boot on its own in UEFI mode. Once there, you can run sudo grub-install --target=x86_64-efi --uefi-secure-boot /dev/sda to install in a way that should produce a clearly named, identifiable BIOS boot order option for Mint.


If using [g]parted, keep in mind that for some reason, it represents the various GPT partition types as "flags". When selecting the ESP flag, it will set the type of the "flagged" partition to ESP, for example. For backward compatibility, the "boot" and "ESP" flags are considered equivalent by [g]parted on GPT-partitioned disks.

1
  • Yes you are perfectly right. I fixed my system and the issue was that it was partly GPT/MBR with OS some in UEFI some not. Also my motherboard BIOS driver hadn't been updated for long and did not fully (or correctly) support UEFI. I flashed a new BIOS (still more than 11 years old!) and it solved many things for me because suddently I was seeing clearly if my USB key was seen as UEFI or not. Then I decided to reinstall correctly the OS and all is good now :)
    – user509010
    Jan 19 at 18:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .