Inspecting Linux Partitions and UEFI Boot Entries

Hello! Last time, you connected GPT partitions, loader files on the EFI System Partition (ESP), and firmware boot variables. Now you will inspect those pieces on Linux and see how far the evidence lets you trace a boot entry to a file.

Allow about 40 minutes. An Ubuntu VM is a suitable place to start, but it may have been installed in legacy BIOS mode rather than UEFI mode. That is a useful finding, not a failed lesson. Everything below is read-only apart from an optional temporary, read-only mount. Do not format partitions, delete files, or change boot order.

Establish what the running system can show

Open a terminal in your Linux VM. First check how this instance of Linux was booted:

if test -d /sys/firmware/efi; then
    echo "This Linux session booted in UEFI mode"
else
    echo "No UEFI interface exposed to this Linux session"
fi

If the directory exists, Linux has a UEFI firmware interface for this boot. If it does not, the VM may have booted in legacy mode; the result does not prove that your physical computer lacks UEFI. Keep going with the disk inspection either way. We will handle unavailable boot variables at the end.

A disk layout, a mounted filesystem, and a firmware boot entry are three different kinds of evidence. We will inspect them separately before trying to connect them.

Inspect the partition table

Start with a map of disks and partitions:

lsblk -o NAME,PATH,TYPE,SIZE,PTTYPE,PARTTYPE,PARTUUID,FSTYPE,MOUNTPOINTS

Find a row whose TYPE is disk, then examine its partition rows. PTTYPE tells you the disk’s partition-table format, commonly gpt or dos. On a GPT disk, PARTTYPE identifies a partition’s role, while PARTUUID identifies that particular partition. Look for an ESP type and a FAT filesystem (vfat in many Linux listings). A partition named /dev/sda1 is only an example: your VM might use a different disk name or partition number.

For another view, run fdisk against the whole disk you identified, not an example device name copied without checking:

sudo fdisk -l /dev/sda

Replace /dev/sda with your disk path if needed—for example, /dev/nvme0n1. Here -l lists information; this command does not open an interactive partition editor. Look for Disklabel type: gpt and a partition of type EFI System.

Read ArchWiki’s EFI system partition, under “Check for an existing partition,” from its fdisk -l instruction through the explanation of the resulting partition list:

Do not conclude “this is the ESP” from FAT alone: other partitions can use FAT. The partition type is stronger evidence of its intended role, and its contents offer a further check. Equally, an ESP need not be the first partition.

Inspect the ESP’s files

Check whether a FAT filesystem is already mounted:

findmnt -t vfat -o TARGET,SOURCE,FSTYPE

Compare each SOURCE with the ESP partition you found using lsblk. If it is mounted, note its TARGET—often /boot/efi, but do not assume that path. For a target of /boot/efi, you can list UEFI executables without changing them:

sudo find /boot/efi/EFI -maxdepth 3 -type f -iname '*.efi' -print

Replace /boot/efi with the actual mount target if yours differs. Look at the directory names as well as the filenames: you may find several loaders under one ESP’s EFI directory. If the EFI directory is absent, recheck that the mounted filesystem is the partition you identified.

If the ESP is not mounted, you may skip this step or inspect it with a temporary read-only mount. Only do this after verifying the partition path and its type in the previous step:

esp_partition=/dev/sda1
esp_mount=$(mktemp -d)
sudo mount -o ro "$esp_partition" "$esp_mount"
sudo find "$esp_mount/EFI" -maxdepth 3 -type f -iname '*.efi' -print
sudo umount "$esp_mount"
rmdir "$esp_mount"

Replace /dev/sda1 before running the first line. If mount fails, stop rather than continuing the sequence; if umount fails, do not remove the directory until you have resolved why it is still mounted. There is no need to remount an ESP that is already accessible.

A listed .efi file tells you it is present, not that firmware selected it on this boot—or that Secure Boot accepted it. Those require different evidence.

Inspect firmware boot entries

In a UEFI-booted Linux session, try:

sudo efibootmgr -v

If efibootmgr is not installed, do not install it solely for this lesson; use the example below. If it reports that EFI variables are unsupported, return to the /sys/firmware/efi check. On some systems, variable access may also be unavailable despite a UEFI boot. Report that limitation rather than inventing an entry list.

Watch only the inspection portions of Diego Sandoval’s UEFI boot explained (for Linux users). The first shows ordinary and verbose efibootmgr output; the second shows a partition table. You have already studied the boot-manager concepts, so focus on what each command actually reveals.

For the meaning of the fields, read the tool’s own README:

In your output, BootCurrent identifies the entry selected for the current boot. BootOrder lists the normal priority; the order in which Boot#### lines are printed is not necessarily that priority. An asterisk marks an active entry, not the currently running one. If BootNext appears, it specifies a one-boot override.

The verbose part of a disk-based entry may resemble:

Boot0001* Example  HD(1,GPT,...)/File(\EFI\example\loader.efi)

The HD(...) portion describes the target partition. File(...) gives a path relative to the root of that partition. It is not a Linux path beginning at /boot/efi; that Linux path exists only when the partition is mounted there.

Connect the three views—and mark their limits

Use one entry from your own efibootmgr -v output if available. First, find its number in BootOrder and note whether it is active. Next, compare the GPT partition identifier shown in its HD(...) path with PARTUUID from lsblk (letter case may differ). Finally, use the mount target to translate its File(...) path into a Linux filesystem path and check whether that file is present.

For example, if a matching ESP is mounted at /boot/efi, an entry containing File(\EFI\ubuntu\shimx64.efi) refers to a file you would look for at /boot/efi/EFI/ubuntu/shimx64.efi. This comparison is useful because a boot entry can remain configured even when its disk or file is missing. A matching file, in turn, does not prove why that entry was chosen.

Here is a real verbose listing to interpret if your VM cannot provide one:

In the screenshot, BootCurrent is 0012, while BootOrder begins with 0013. Entry Boot0012 points to \EFI\ubuntu\shimx64.efi. Several highlighted entries refer to the same GPT partition identifier but to different files—one ESP can contain multiple loaders. The listing alone cannot explain why 0012, rather than 0013, became current.

If you also use the partition-table screenshot from the previous lesson, remember that the two screenshots show separate example systems. Do not match their partition numbers as though they came from one machine.

If your VM has no usable UEFI entries

You can still record what you observed: the disk’s partition-table type, whether an ESP exists, whether it is mounted, and whether loader files are visible. Then state the boundary plainly: “This Linux session does not expose usable UEFI boot variables, so I cannot inspect its live firmware boot entries.” An ESP on disk does not, by itself, prove the current session booted through UEFI. There is no need to change VM firmware settings just to manufacture a result.

For an interview, the valuable habit is to separate observation from inference: “I found a GPT ESP with this partition identifier; efibootmgr -v shows an active entry targeting that identifier and this loader path; I checked whether the file exists.” If a link in that chain is unavailable, say which one.

Key takeaways

You can inspect the partition table with lsblk and fdisk -l, the ESP’s contents through its mount point, and firmware boot entries with efibootmgr -v when UEFI variables are accessible. Match a boot entry to a partition using its identifier, then resolve its loader path on that partition. Presence, configured priority, and current selection are related facts—but they are not interchangeable proofs.

This completes the platform-boot module. Next, the course turns from what starts to what makes startup trustworthy: roots of trust and UEFI security mechanisms.