Boot Partition Confusion

[nickname]

Hi y'all,

I currently have a dual-boot (well, sort of) set up with Mint 19.1 and Windows 10 Pro on a laptop with (1) HDD and (3) SSDs. Over the last few months as I've bought the SSDs and installed them, I've moved Windows from one drive to another, installed Mint a couple of times, and the result is a bit of a mess. Now I'm trying to sort it out so I can install Trident OS as a third boot option and sort out my GRUB menu so I can use it to boot into any of the three without having to touch UEFI/BIOS options.

To this end, I went about gathering some info and after running a series of System Settings (UEFI/BIOS) and boot experiments, this is what I found out:

In the UEFI/BIOS > UEFI Hard Disk Drives BBS Priorities, I have four options to boot from:

• Windows Boot Manager (P4: KINGSTON)
• ubuntu
• ubuntu (P2: HGST)
• ubuntu (P4: KINGSTON)

I set each of these, in turn, as the primary boot partition and got these results:

• #1 boots straight into Windows 10
• #2 to #4 all bring up the GRUB menu.

So, there’s an amount of redundancy in regards to booting into Linux. Also, I don’t know yet which partition holds the GRUB menu and/or boot loader for Mint. In fact, I don't even know if—with this new UEFI stuff—if GRUB is on a partition or not.

Another thing… According to gparted (see below) there are only two EFI system partitions associated with Linux:

• sdc2, and
• sdd2.

I don’t know where the third ubuntu option comes from and since all three boot Mint, somewhere along the line, they must all point to the same boot loader and/or partition.

Also, gparted shows that:

• P4: KINGSTON is sdd, and
• P2: HGST is sdc.

But that must mean that when #1 is selected in UEFI/BIOS, Windows is using a boot loader built into the Windows kernel on sdd4 or control is somehow being passed to sdc3 or sdb1.

Moving on…

The GRUB menu has five options:

• mint 19.1 (boots Linux)
• mint advanced options (boots Linux)
• Windows on sdc2 (Windows-based repair mode)
• Windows on sdd2 (Windows-based repair mode)
• System Setup (UEFI/BIOS)

In effect, because both Windows options go into repair mode, if I want to switch OSs I have no choice but to go back into UEFI/BIOS and change the boot priorities.

The odd thing about this is that both sdc2 and sdd2 are fat32 partitions mounted to /boot/efi under Linux and because of this, I’d guess they have nothing to do with Windows repair/recovery. Yet, this is how GRUB sees them.

And also, how could both possibly be mounted to the same mount point (/boot/efi)?

And because Windows 10 is installed on sdd4 (see gparted output below) I would have thought its boot loader would be somewhere on that drive as well, but now I’m thinking it must be on either:

• sdb1, or
• sdc3.

I came to this conclusion because gparted sees these as Microsoft Reserved partitions, but has no other info about them. Also, there are no other Microsoft-related partitions except those for Recovery.

gparted Drive Info

sda (232gb)

• sda1 = linux mint (116gb)
• unallocated space I’m reserving for Trident

sdb (465gb)

• sdb1 = Microsoft reserved (15gb)
• sdb2 = ntfs (mounted as ~/Data) 465gb)

sdc (931gb)

• sdc1 = ntfs (Microsoft Recovery partition) (499mb)
• sdc2 = fat32 (/boot/efi) (100mb)
• sdc3 = Microsoft Reserved (16mb)
• sdc4 = ntfs (mounted as ~/DataBU) (931gb)

sdd (223gb)

• sdd1 = ntfs (Microsoft Recovery partition) 94mb)
• sdd2 = fat32 (/boot/efi) (78mb)
• sdd3 = msftres (16mb)
• sdd4 = ntfs (mounted as ~/WinSys) (223gb) (NOTE: This is also the partition that boots into Windows 10 Pro)

I’m beginning to think the brave options would be:

• go ahead with the Trident installation and see what new confusion its boot loader/menu brings, or
• scrape it all down to metal and start over (which I'm not keen on).

Besides, I just don’t know if I’m that brave.

Questions:

• Most importantly, is there any point to cleaning up this mess or should I just find the right tool(s) to figure out what's doing what and get on with life?
• Elsewhere in this forum, I read about boot-repair. I'm guessing this will help me sort out how to do a triple-boot system, but will it help me figure out which EFI partition(s) are booting Mint and which of those pesky Microsoft Reserved partitions boots Windows 10 (non-recovery)?
• Is boot-repair the best tool for the job, or should I look elsewhere?

NOTE: I've been working almost exclusively on Windows for the last ten years and I've gone a bit soft (you might say: Micro-soft), so if there's a tool with a GUI, I'd feel more comfortable, but it's not a show stopper if I have to go to a shell to do this. It just means I'll have to do my deep-breathing exercises and get all brave (see earlier comment on bravery).

[gm10]

Sounds like you've got GRUB installed on both devices. To see what exactly the UEFI boots, run

Code: Select all

efibootmgr -v

That will show you which device/path and parameters are actually configured for each entry.

If you're familiar with Windows, as you say, the equivalent tool there is Bcdedit.exe.

Using something like boot-repair might be easiest indeed if you don't want to dive into the details.

[nickname]

efibootmgr Boot Order info:

Boot0008 ubuntu /File(\EFI\UBUNTU\GRUBX64.EFI)
Boot0006 Windows Boot Manager /File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)
Boot0001 ubuntu /File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0007 ubuntu /File(\EFI\UBUNTU\GRUBX64.EFI)
Boot0000 Windows Boot Manager /File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS

Digging around, I read that the BootXXXX numbers don't refer to anything hard and fast, but are the order in which the entries were added to Grub.

I'm not sure what else this is telling me, though.

[gm10]

You sure you had the -v parameter added? I've never seen the output formatted like that. It should look something like this, showing the actual boot devices:

Code: Select all

$ efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0001,0003,0000
Boot0000* Windows Boot Manager	VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* Linux Kernel	HD(1,GPT,c009a9bd-6176-4d64-b80b-054474c7d612,0x800,0x1f000)/File(\EFI\Linux\vmlinuz)r.o.o.t.=.U.U.I.D.=.3.7.4.b.1.6.2.b.-.4.a.f.f.-.4.7.2.e.-.9.3.5.1.-.c.8.9.e.b.8.a.b.3.f.b.f. .r.o. .q.u.i.e.t. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4. .a.d.d._.e.f.i._.m.e.m.m.a.p. .i.n.i.t.r.d.=.\.i.n.i.t.r.d...i.m.g.
Boot0002* GRUB2	HD(1,GPT,c009a9bd-6176-4d64-b80b-054474c7d612,0x800,0x1f000)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0003* UEFI OS	HD(1,GPT,c009a9bd-6176-4d64-b80b-054474c7d612,0x800,0x1f000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

[nickname]

Yes, I did. I just posted the parts that seemed to actually be human-readable and said something that struck me as relevant. Here's the full output:

BootCurrent: 0008
Timeout: 1 seconds
BootOrder: 0008,0006,0001,0007,0000
Boot0000 Windows Boot Manager HD(2,GPT,b1852155-bd66-41e5-917c-28de0f83f40b,0xfa000,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0001* ubuntu HD(2,GPT,a8ba65b9-935f-4258-bd31-1df47fb78675,0x3304b,0x2730c)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0006* Windows Boot Manager HD(2,GPT,a8ba65b9-935f-4258-bd31-1df47fb78675,0x3304b,0x2730c)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot0007* ubuntu HD(2,GPT,b1852155-bd66-41e5-917c-28de0f83f40b,0xfa000,0x32000)/File(\EFI\UBUNTU\GRUBX64.EFI)..BO
Boot0008* ubuntu HD(2,GPT,a8ba65b9-935f-4258-bd31-1df47fb78675,0x3304b,0x2730c)/File(\EFI\UBUNTU\GRUBX64.EFI)..BO


[gm10]

Yes, I did. I just posted the parts that seemed to actually be human-readable and said something that struck me as relevant. Here's the full output:

Code: Select all

BootCurrent: 0008
Timeout: 1 seconds
BootOrder: 0008,0006,0001,0007,0000
Boot0000  Windows Boot Manager	HD(2,GPT,b1852155-bd66-41e5-917c-28de0f83f40b,0xfa000,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0001* ubuntu	HD(2,GPT,a8ba65b9-935f-4258-bd31-1df47fb78675,0x3304b,0x2730c)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0006* Windows Boot Manager	HD(2,GPT,a8ba65b9-935f-4258-bd31-1df47fb78675,0x3304b,0x2730c)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
Boot0007* ubuntu	HD(2,GPT,b1852155-bd66-41e5-917c-28de0f83f40b,0xfa000,0x32000)/File(\EFI\UBUNTU\GRUBX64.EFI)..BO
Boot0008* ubuntu	HD(2,GPT,a8ba65b9-935f-4258-bd31-1df47fb78675,0x3304b,0x2730c)/File(\EFI\UBUNTU\GRUBX64.EFI)..BO

Oh this is quite readable. We can see that all your boot entries point to the same device HD(2, that Boot0001 and Boot0008 boot the same GRUB in the same ESP partition as your Windows boot loader, but the Boot0008 entry doesn't support secure boot, so I'd just delete it, there's no reason to have it:

Code: Select all

sudo efibootmgr -Bb 8

Boot0007 boots GRUB from a different partition.

The alphanumerical sequences shown are your partition UUIDs. If you run

Code: Select all

lsblk -f

you can see how those UUIDs translate to your devices, so you'll know which partitions exactly are involved here.

[nickname]

The alphanumerical sequences shown are your partition UUIDs. If you run

Code: Select all

lsblk -f

you can see how those UUIDs translate to your devices, so you'll know which partitions exactly are involved here.

Sorry, I'm not seeing the correlation. There are lots of alpha-numeric sequences in lsblk's output, but none match those in efibootmgr's output:

Code: Select all

NAME     FSTYPE   LABEL    UUID                                 MOUNTPOINT
loop0    squashfs                                               /snap/blender/25
loop1    squashfs                                               /snap/core/6405
sda                                                             
└─sda1   ext4              260b4e10-086f-4f3a-9ac2-2b1f9477ca84 /
sdb                                                             
├─sdb1                                                          
└─sdb2   ntfs     Data     5AA6B3C7A6B3A245                     /mnt/Data
sdc                                                             
├─sdc1   ntfs     Recovery D61228FD1228E469                     
├─sdc2   vfat              E42A-F805                            /boot/efi
├─sdc3                                                          
└─sdc4   ntfs     DataBU   52D02E5BD02E4597                     /mnt/DataBU
sdd                                                             
├─sdd1   ntfs     Recovery 01D497A4CAFAECE0                     
├─sdd2   vfat              E42A-F805                            
├─sdd3                                                          
└─sdd4   ntfs              01D497A788D85AC0                     /mnt/WinSys
sde                                                             
└─sde1   ntfs     Elements 6C72DED372DEA15E                     
mmcblk0                                                         
└─mmcblk0p1
         ext4     SysSnap  0ee8d592-e78f-4a09-8b5d-a59421260b9a

Or are they there and I'm looking at them wrong somehow?

[gm10]

Sry, my bad, gave the wrong command for the situation, we don't need the UUID, we need the PARTUUID. Use this command:

Code: Select all

sudo blkid 

[nickname]

we need the PARTUUID. Use this command:

Code: Select all

sudo blkid 

Code: Select all

/dev/sda1: UUID="260b4e10-086f-4f3a-9ac2-2b1f9477ca84" TYPE="ext4" PARTUUID="6476ea51-c17d-402b-9943-3d795ade841b"
/dev/sdb2: LABEL="Data" UUID="5AA6B3C7A6B3A245" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="fa03cc90-3717-4b08-a716-1b279c971f4b"
/dev/sdc1: LABEL="Recovery" UUID="D61228FD1228E469" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="6e357fe5-5a28-44d0-9bfd-2e9f0a742bc6"
/dev/sdc2: UUID="E42A-F805" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="b1852155-bd66-41e5-917c-28de0f83f40b"
/dev/sdc4: LABEL="DataBU" UUID="52D02E5BD02E4597" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="d5123b5d-fb5c-40a2-8e38-0affbefbf1f3"
/dev/sdd1: LABEL="Recovery" UUID="01D497A4CAFAECE0" TYPE="ntfs" PARTLABEL="M-oM-?M-?M-oM-?M-?M-oM-?M-?M-oM-?M-?$" PARTUUID="c101d536-f618-45aa-b54c-8e1e4b478020"
/dev/sdd2: UUID="E42A-F805" TYPE="vfat" PARTUUID="a8ba65b9-935f-4258-bd31-1df47fb78675"
/dev/sdd4: UUID="01D497A788D85AC0" TYPE="ntfs" PARTUUID="a94233a6-4edb-430c-aa6e-950f7d98a5c2"
/dev/mmcblk0p1: LABEL="SysSnap" UUID="0ee8d592-e78f-4a09-8b5d-a59421260b9a" TYPE="ext4" PARTUUID="c99186e7-01"
/dev/sde1: LABEL="Elements" UUID="6C72DED372DEA15E" TYPE="ntfs" PARTUUID="006d81ce-01"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/sdb1: PARTLABEL="Microsoft reserved partition" PARTUUID="68d9e6a8-2441-4199-8cb6-b2ec7b37815f"
/dev/sdc3: PARTLABEL="Microsoft reserved partition" PARTUUID="df8af205-f879-49f1-b143-7ca02268e083"
/dev/sdd3: PARTUUID="8d79c695-a00e-4428-814c-00af5a957549"
/dev/mmcblk0: PTUUID="c99186e7" PTTYPE="dos"

[gm10]

Well, you can check that yourself, as I said, compare the PARTUUID and you'll know which entry boots from which partition...