Help understanding EFI/UEFI disk volume structure

I kindly ask the community for some guidance regarding the volume structure of a new TW installation.

disclaimer: I have trouble understanding EFI/UEFI and I am confused by the way things are installed now as compared with, say, over 10 years ago. I am learning. Please be kind and bear with me :slight_smile: Thanks in advance.

I recently installed TW over an older installation. Everything went well and the system runs smoothly. In comparison with previous installations, I was a bit baffled to see that 2 β€œnew” volumes are showing on the (XFCE) desktop. See the last two icons:

image

Of these one is mounted (4TB, last one) and the other is not (537 MB, upper one). I understand what the last mounted icon corresponds to (a RAID of two physical disks). My question here is about the first one.

Upon investigation I see that this volume corresponds to a β€œFAT partition”:

I do not recall explicitly telling the installer to create this partition nor seeing it as a proposal during the installation a couple of days ago. I usually let the installation process decide the structure of these things.

Is this normal? Is this partition being used at boot? Could it be a β€œleft over” from the older installation (which would be strange since disk was formatted). I see that the dates of the files inside this are older than a week before the installation and the directories have the date of the original installation three yrs ago:

> tree -D EFI/
[Feb  2  2021]  EFI/
β”œβ”€β”€ [Feb  2  2021]  boot
β”‚   β”œβ”€β”€ [Mar 30 22:26]  bootx64.efi
β”‚   β”œβ”€β”€ [Mar 30 22:26]  fallback.efi
β”‚   └── [Mar 30 22:26]  MokManager.efi
└── [Feb  2  2021]  opensuse
    β”œβ”€β”€ [Mar 30 22:26]  boot.csv
    β”œβ”€β”€ [Mar 30 22:26]  grub.cfg
    β”œβ”€β”€ [Mar 30 22:26]  grub.efi
    β”œβ”€β”€ [Mar 30 22:26]  grubx64.efi
    β”œβ”€β”€ [Mar 30 22:26]  MokManager.efi
    └── [Mar 30 22:26]  shim.efi

For reference, the volume β€œ@/boot” has dates corresponding to the new installation:

> tree -D
[Apr  8 11:58]  .
β”œβ”€β”€ [Apr  8 11:58]  config-6.8.4-rc1-1-default -> ../usr/lib/modules/6.8.4-rc1-1-default/config
β”œβ”€β”€ [Apr  8 12:03]  grub2
β”‚   β”œβ”€β”€ [Apr  8 12:03]  device.map
β”‚   β”œβ”€β”€ [Apr  8 12:03]  fonts
β”‚   β”‚   └── [Apr  8 12:03]  unicode.pf2
β”‚   β”œβ”€β”€ [Apr  8 12:03]  grub.cfg
β”‚   β”œβ”€β”€ [Apr  8 12:03]  grubenv
β”‚   β”œβ”€β”€ [Apr  8 12:03]  i386-pc
β”‚   β”‚   β”œβ”€β”€ [Apr  8 12:03]  acpi.mod
β”‚   β”‚   β”œβ”€β”€ [Apr  8 12:03]  adler32.mod
β”‚   β”‚   β”œβ”€β”€ [Apr  8 12:03]  affs.mod
β”‚   β”‚   β”œβ”€β”€ [Apr  8 12:03]  afs.mod
β”‚   β”‚   β”œβ”€β”€ [Apr  8 12:03]  afsplitter.mod
β”‚   β”‚   β”œβ”€β”€ [Apr  8 12:03]  ahci.mod
β”‚   β”‚   β”œβ”€β”€ [Apr  8 12:03]  all_video.mod

For reference I have another computer, a laptop which previously had Windows installed on it, where there is a partition called EFI System Partition mounted on β€œ/boot/efi”. No partition is left unmounted. On the other hand, the computer in question here is a desktop built from parts. Never had Windows on it. These setups look different.

In case you wonder, yes I have seen the documentation. I am no wiser for that. Thanks for any clarification.

For UEFI boot, you need an ESP (EFI system partition) which is formatted as FAT 32 per the UEFI standard. This is usually mounted at /boot/efi. Everyone who uses UEFI has this, Yast installer creates a 512M partition for this.
In your case, the ESP would be the /dev/nvme1n1p2 partition.

What I don’t have and suspect is the issue here is the presence of the /dev/nvme1n1p1 of type BIOS boot partition. Wikipedia tells me this is used by grub for legacy BIOS boot when the disk uses GPT partition table.

So perhaps your BIOS was set to legacy mode and not UEFI mode prior to the installation?
Could you provide the output of:

findmnt /boot/efi
efibootmgr

My TW VMs (virt-manager) use legacy BIOS so it doesn’t have ESP but has the bios boot partition instead, but I’ve until now not seen both existing in a single drive/machine. My guess is the ESP was leftover from the previous installation and yast installer decided not to tamper with it.

1 Like

I suspect you booted the installer in legacy mode, and so it kept that mode for the installed system. However, for your NVME device it preferred to create a GPT partition table. Legacy booting from a GPT disk requires a small BIOS boot partition, nvme1n1p1 on yours, be created to host bootloader code, because with GPT there is normally no unallocated space following the table in which to install bootloader code. Your nvme1n1p2 was apparently created either to facilitate a future change from legacy booting to the preferred modern method of UEFI booting, which requires a FAT formatted ESP (EFI System Partition) to host boot files, and/or to enable firmware updating from an installed operating system.

1 Like

Thanks for your reply.

I believe you are correct:

# findmnt /boot/efi

gives no results and,

# efibootmgr
EFI variables are not supported on this system.

I will check the BIOS and reply again.

EDIT: I have now had a look at BIOS and found no simple switch to β€œUEFI mode”. It is a β€œmodern” motherboard from 2020. So perhaps it is just me.

Thank you for your input. I understand that my system is now working on legacy mode.

You probably need to find the BIOS setup boot section where it currently says Compatible or Legacy or CSM or UEFI+Legacy, click on it, then select UEFI or UEFI-only, if and when you wish to make such switch. If you do that, you’ll need to boot from installation media, select boot installed system, then use YaST Bootloader to make the switch from Legacy to UEFI for your installed system. Or, you could first boot the installed system normally, use YaST Bootloader to switch the mode to UEFI for the installed system, then go into BIOS setup to switch to UEFI.

2 Likes

Great, at least we can confirm you’re using legacy BIOS to boot and not UEFI.
Not sure what happened during installation that led to the ESP being kept even when the disk was formatted.

For a mobo from 2020, there has to be a UEFI mode in there somewhere.
Make sure you’re using the latest BIOS/UEFI firmware.

1 Like

Thank you for this input. I see the BIOS has an entry called CSM, and it is enabled. This is a topic I need more time to explore and eventually implement.

I am not sure either, but I now have a better understanding, so during next install these things will be better managed.

Yes, there is a CSM option enabled. I will look at this in due time.

Thank you for your input!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.