UEFI Shell Filesystem Mapping

A practical guide to map, fs0, removable media, ESP visibility, and why Shell filesystem aliases can change.

2 min read
Shell & Firmware Tools cover

A USB stick worked yesterday. Today Shell shows fs1: instead of fs0:. A boot script fails even though the EFI file is still there.

This is not random. It is a symptom of how UEFI Shell maps devices.

First command

Shell> map -r

map -r refreshes mappings. In debug sessions, I run it before trusting any fsX: name.

Typical output may look like:

FS0: Alias(s):HD0a65535a1:;BLK1:
     PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,...)
FS1: Alias(s):HD1a65535a1:;BLK3:
     PciRoot(0x0)/Pci(0x14,0x0)/USB(0x2,0x0)/HD(1,MBR,...)

The important part is not only FS0. The important part is the device path under it.

Real world example: startup.nsh cannot find tool

A script says:

fs0:\tools\flash.efi

It works on the engineer’s desk, then fails in the factory.

Why?

Because the factory jig has an internal ESP, a recovery USB, and sometimes a diagnostic USB. The tool USB becomes fs2: instead of fs0:.

A safer script searches:

for %a run (fs0 fs1 fs2 fs3 fs4)
  if exist %a:\tools\flash.efi then %a:\tools\flash.efi
endfor

Debug checklist

When an EFI file is not found

Use this before blaming the file path.

Firmware Engineer Notes

When debugging boot media, I record three things together:

fsX alias
Device Path
Directory listing

Only recording fs0: is not enough. It hides the reason why the mapping changed.

Found this useful?

Save it or share it with someone learning firmware, BIOS/UEFI, and embedded systems.

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.