5

Is there a way to know which partition you actually booted from?

fdisk -l reveals a "Boot" column that I definitely don't have on my NVME. Is this just legacy information?

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048   1126399   1124352   549M  b W95 FAT32
/dev/sda2         1126400 975688107 974561708 464.7G  7 HPFS/NTFS/exFAT
/dev/sda3       975689728 976769023   1079296   527M 27 Hidden NTFS WinRE

...

Device              Start        End    Sectors   Size Type
/dev/nvme0n1p1     616448 2458216447 2457600000   1.1T Linux filesystem
/dev/nvme0n1p2 2458216448 3907024031 1448807584 690.8G Linux filesystem
/dev/nvme0n1p3       2048     616447     614400   300M EFI System

Partition table entries are not in disk order.

Considering lsblk shows that /boot/efi is mounted I'm 90% sure that it's using my nvme drive, I just wanted to confirm that's true even though there's no boot indicator from fdisk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 465.8G  0 disk
├─sda1        8:1    0   549M  0 part
├─sda2        8:2    0 464.7G  0 part
└─sda3        8:3    0   527M  0 part
sdb           8:16   0   1.8T  0 disk
├─sdb1        8:17   0    99M  0 part
├─sdb2        8:18   0    16M  0 part
└─sdb3        8:19   0   1.8T  0 part
nvme0n1     259:0    0   1.8T  0 disk
├─nvme0n1p1 259:1    0   1.1T  0 part
├─nvme0n1p2 259:2    0 690.8G  0 part /
└─nvme0n1p3 259:3    0   300M  0 part /boot/efi

I also noticed Disklabel type is dos for /dev/sda and gpt for /dev/nvme0n1 if that factors in.

2
  • 1
    This quickly shows a lot of info: lsblk -e 7 -o model,name,fstype,size,fsused,label,partlabel,mountpoint,uuid
    – oldfred
    May 5 at 17:37
  • Consider that you may not even have been booted from a partition. You may have been booted via PXE, or from a removable device that is no longer there, or even from another running linux system via kexec.
    – b0fh
    May 5 at 21:39

2 Answers 2

15

Since your system apparently boots in UEFI style, the answer to the titular question is:

Run efibootmgr -v as root, see the four-digit ID on the BootCurrent: line (usually the first line of output), then look at the corresponding BootNNNN line to find both the PARTUUID of the partition to boot from, and the filename containing the actual boot manager/loader used.

Then run lsblk -o +PARTUUID to see the partition-unique UUIDs embedded in the GPT partition table. Find the UUID you saw on the BootNNNN line of the efibootmgr -v output, and you'll know the partition.

(On MBR-partitioned disks, there is no real partition UUID, and so a shorter combination of a disk signature number and a partition number is displayed in place of a real partition UUID.)


The Disklabel type is definitely a factor here: it indicates your sda uses classic MBR partitioning and boot sequence, while your nvme0n1 uses GPT partitioning and UEFI-style booting.

While the GPT partition table can store a boot flag that is essentially the same as the Boot flag field in the fdisk -l output of a MBR-partitioned disk, booting MBR-style from a GPT-partitioned disk is expected to be a rare corner case, and so fdisk -l will not include it. The native UEFI-style way will not use such a flag at all, since it's now the system firmware's job to know both the name of the bootloader file and the PARTUUID of the partition to load it from.

But if such a legacy flag is enabled on a GPT partition, using the i command (= print information about a partition) of a modern Linux fdisk will show it, by the presence of a LegacyBIOSBootable keyword on the Attrs: line of output.

To actually toggle such a flag, you would have to use the experts-only extra commands of a GPT-aware Linux fdisk: first x, then A to toggle the flag.

If you just want a list the partition table with the UEFI partition flags included, you can use fdisk -x /dev/nvme0n1. Be advised that the output is quite a bit wider than the traditional fdisk -l output.


If you are booting using the classic MBR/BIOS style, then the answer to the title question is "you don't, really." There is no ubiquitous standard way for BIOS-style firmware to tell the OS which device was actually used to boot the system. This was a long-standing problem on all OSs and OS installers on systems using legacy BIOS-style boot.

If the /sys/firmware/edd directory exists, it may contain information that allows the identification of the boot disk, by identifying the order in which BIOS saw the disks in. By convention, the current boot disk is moved to the first hard disk position (also known as "disk 0x80") in the BIOS disk list, and most BIOS-based bootloaders rely on this fact.

So if /sys/firmware/edd/int13_dev80 exists, and the bootloader has not switched the BIOS int13 IDs of the disks around (GRUB can do so, if you have a custom dual/multi-boot configuration that requires swapping disk IDs), then the information within may be useful to identify the actual boot disk used by the firmware.

Unfortunately the BIOS extension required to have this information available was not as widespread as it could have been, and not always completely and correctly implemented even when it was present. I've seen a lot of systems with no EDD info available, some systems with incomplete EDD info, and even one system in which querying the EDD info caused the boot to hang.

(Apparently the EDD info interface was designed by Dell, so if you mostly work with Dell systems, you may have better luck than me.)

2

Linux (grub/systemd) doesn't keep the information about the partition it booted from.

If your system boots in EFI mode it uses /dev/nvme0n1p3 otherwise it's /dev/sda1 since sda looks like an MBR partitioned disk.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.