Writing SN/MTM back to a replacement ThinkPad system board

A procedure for restoring a machine’s identity to a blank replacement system board on modern UEFI-only ThinkPads. That identity is the machine type, serial number, product name and UUID.

Verified on an Alder Lake ThinkPad (2022, 21xx machine type, N3xET BIOS) running Linux, with no Windows installation on the target machine. The approach should generalise to other ThinkPads of the same era.

The problem

A replacement system board from Lenovo Parts arrives with its identity fields blank. A donor board, similarly, may need re-writing to match your chassis. DMI reports the following on a new board.

Product Name:   INVALID
Serial Number:  INVALID
UUID:           Not Settable
Chassis Serial: INVALID

Daily use is unaffected. However, three obnoxiously beep-y POST errors fire on every boot. This seems to be a modern ThinkPads reproduction of BEEP through the HDA codec.

Notably 2200 and 2202 are sometimes merged as one (at least you get just two beeps then). Warranty lookups, parts lookups, Lenovo Vantage reporting and anything else keyed to the machine type also likely break. Not tested with Vantage, ew micro$oft.

Values you need

The string written to the EEPROM is the C0 field.

C0 = 1S + <MTM> + <SERIAL>          e.g.  1S21XX00XXXXABCD1234

Concatenated, no dashes, no spaces.

The kernel logs the MTM at every boot, so it survives a lost label if the disk is unchanged.

sudo journalctl -o cat -g 'DMI:' --no-pager | sort -u

The serial number is never otherwise logged. It has to come from the label, an invoice or a previous screenshot.

Reading the board’s FRU

Reading the B0 field returns the Lenovo 8S barcode string.

8S + <FRU part number> + <board serial>

This is the planar FRU. Seems that no OS interface exposes it. It is absent from DMI and from the hardware maintenance manual, which only points at the online parts lookup.

What does not work

Tried each and wasted time, don’t do it unless the rest fails:

• Lenovo’s Right-to-Repair in-BIOS writer (support article HT516543) is documented to auto-launch on first power-on while the MTM is blank. On some machines it never appears, at any BIOS version, warm or cold boot.

• Asset Information is a BIOS-resident UEFI application in the boot entry list. It is a read-only viewer.

• BIOS Setup shows MTM and serial on the Main tab. Neither field is editable.

• thinklmi (/sys/class/firmware-attributes/thinklmi/) exposes around 105 BIOS attributes. None of them covers SN or MTM. There is no Linux-side write path.

• Lenovo Diagnostics, in every version and in both the UEFI and Linux builds, is a hardware test suite with no VPD write path. Its only serial-related symbol is SetEnableSerialNumberValidation.

• Running the maintenance utility from the internal ESP fails, as does running it from any non-removable device such as a portable SSD or a disk-mode enclosure.

• Old toolkits run and read the EEPROM fine, then withhold the service functions when their platform table predates your machine. Check the table before spending a reboot.

What works

1. Get a current Lenovo Golden Key / U1 toolkit

The toolkit is distributed through LSTC (Lenovo Service Tool Center), a Windows application for field service technicians. Version numbering is 3.5.x where x increments over time (3.5.3 is roughly 2021, 3.5.76 roughly 2025, 3.5.81 roughly 2026). Two builds are mirrored under downloads below.

Verify a candidate build knows your machine before using it.

# your BIOS ID prefix, e.g. N3IET, from: cat /sys/class/dmi/id/bios_version
strings MTMSN/BIOSID/BIOSID.dat | grep '^<BIOSID>:'

# your machine type, e.g. 21E8
grep '^<MT>=' MTMSN/ThinkPad/plnsrv.ini

Both must return a line. A build that does not list your BIOS ID will boot and read the EEPROM fine but decline the service functions.

Adding your machine type to plnsrv.ini by hand “works”. It is a plain-text lookup table read at runtime, and it gates the product-name string. Adding your BIOS ID to BIOSID.dat to force an unsupported platform down a write path is not advisable. It also doesn’t really seem to work.

2. Reveal the Advanced menu

If you need it, the PDT unlock lives on the Advanced menu. Set MTMSN/ThinkPad/tpconfig.ini as follows.

[advanced features]
hide_adv=1
hide_eep_init=0

hide_adv=1 gives the Advanced menu. Lenovo’s own file comments that 0 means Advanced. The comment is wrong.

Set hide_eep_init=1 to hide the destructive Initialize EEPROM entry entirely.

3. The key must be created by Lenovo’s own formatter

This is the crux. A hand-built key with the correct volume label still fails.

System is locked!
Please confirm if the USB disk is created correctly.

usbfmtpw.exe ships in the toolkit root and must format the key. It refuses fixed drives with Fixed drive can't be formated., so in a VM the target must be attached as a removable USB device.

qemu-img create -f vpc -o subformat=fixed key.vhd 2G

-drive if=none,id=key,file=key.vhd,format=vpc \
-device usb-storage,drive=key,removable=on

The libvirt equivalent.

<disk type='file' device='disk'>
  <driver name='qemu' type='vpc'/>
  <source file='/path/to/key.vhd'/>
  <target dev='sdb' bus='usb' removable='on'/>
</disk>

removable='on' sets the RMB bit, which is what makes Windows report DRIVE_REMOVABLE. Hyper-V and VirtualBox cannot present a virtual disk this way. QEMU/KVM can.

Run usbfmtpw.exe from inside the toolkit directory. Per USBFMT.INI it deploys from .\EFI\BOOT relative to itself, so it formats the key and installs the UEFI Shell in one pass. Afterwards copy the entire toolkit tree onto the key.

4. The boot-sector signature, decoded

Diffing a Lenovo-created key against a hand-built one shows what the check actually tests. The volume label LENOVOBIOS is necessary and not sufficient on its own.

The key is also a superfloppy. FAT is written to the whole device, with no partition table and hidden sectors 0. Any MBR or GPT-partitioned key is wrong on topology alone.

The three fields that most likely matter are the OEM name, the media descriptor and the drive number. All three declare removable media at filesystem level, which matches the tool’s documented refusal to run from anything else.

An untested shortcut follows from that. Run mkfs.vfat -F 32 -n LENOVOBIOS /dev/sdX on the whole device with no partition table, then patch offsets 0x03, 0x15, 0x18, 0x1A and 0x40, along with the backup boot sector at sector 6 (offset 0xC00). This would remove the Windows VM from the process entirely. It has not been verified, and which field the tool actually reads remains untested.

5. Removable media is mandatory

The utility only runs from a device whose removable-media bit is set. This is a property of the USB bridge firmware.

lsblk -o NAME,SIZE,TRAN,RM,FSTYPE,LABEL,MODEL
cat /sys/block/sdX/removable      # must be 1

iODD-style image emulators work in the right mode only.

Such devices pass the boot sector through unmodified, so a Lenovo-formatted image keeps its signature through emulation. Their displays often truncate filenames to around 7 or 8 characters. Prefix images to make them findable.

Downloads

LGK_EFI_3.5.75.zip is the EFI-only toolkit. This is the build the procedure above was verified against. It carries the BIOSID.dat platform table and the MTMSN/ThinkPad handler, and it is the smaller of the two.

LGK_EFI+Tools_V3.5.60.zip is an older build bundled with the Windows-side tools. Useful for usbfmtpw.exe and for the LSTC material. Its platform table is older, so check it against your BIOS ID before relying on it.

thinkpad-u1-3576-lenovobios-key.vhd.zst is a ready-made key image. It is a 12 GB fixed VHD compressed to around 7.5 MB with zstd, since the volume is almost entirely zeros.

zstd -d thinkpad-u1-3576-lenovobios-key.vhd.zst -o key.vhd

The image holds a genuine usbfmtpw-formatted superfloppy, with the LENOVOBIOS label, OEM name LENOVO y, media descriptor 0xF0 and drive number 0x00. The full toolkit tree sits on top, with hide_adv=1 already set. Write it to a removable device, or select it on an image emulator in USB Flash mode. Only the C0 string changes between machines.

Verify after decompression.

EFI/BOOT/BOOTX64.EFI          md5 971ccb18e7b742fe512c0847667226d3   (UEFI Shell)
MTMSN/ThinkPad/BootX64t.efi   md5 20711c28f48d7b3f424ceb34608282f8   (V1.20 handler)

Procedure

1. Boot the key with Secure Boot disabled, because the maintenance binary is unsigned. A LUKS root with a TPM2 keyslot bound to PCR 7 will prompt for its passphrase, since toggling Secure Boot moves PCR 7. Have the passphrase ready.

2. Confirm the red System is locked! banner is absent. If it appears, the key was not created by usbfmtpw. Go back to step 3 above.

3. From the main menu take 7 - PDT, then 2 - Unlock PDT. Expect Command success. PDT will be unlocked only for the next boot.

4. Reboot straight back into the key. The unlock lasts exactly one boot, so do not detour into the OS in between.

5. Run Planar service. It performs all writes in one confirmed step.

   - Set S/N data(C0) to: 1S<MTM><SERIAL>
   - Set brand name: <product name>
   - Set keyboard language ID: <e.g. US English (0409)>
   - Create a new random UUID.

   The same writes are available individually from Set system identification (1 - Add S/N data to EEPROM, device type C0), the brand-name utility and Assign UUID.

6. Verify with 2 - Read S/N data from EEPROM. C0 should now appear alongside B0.

7. Reboot, re-enable Secure Boot, then verify with sudo dmidecode -t 1 -t 2 -t 3.

Why writes are refused without the unlock

TpReadEEPROMBlock : Write access to Block#84 is denied Status=0xf

0xf is EFI_ACCESS_DENIED. The firmware refuses the write. The serials live in the PDT (Product Data Table), which is locked. UUID and brand name usually write without the unlock, because those blocks carry no PDT protection. Only the system-unit serial does. Partial success on two of the three POST errors is therefore expected before the unlock.

Checking ISH support... This system does not support ISH. may appear during the PDT flow. It is benign and does not prevent the unlock.

Afterwards

The EEPROM write resets BIOS settings to factory defaults. Re-apply anything customised. On Linux this goes through thinklmi, and needs no BIOS password if none is set.

A=/sys/class/firmware-attributes/thinklmi/attributes
echo Linux   | sudo tee $A/SleepState/current_value      # S3 rather than s2idle
echo Disable | sudo tee $A/KeyboardBeep/current_value
cat $A/pending_reboot                                    # 1 = takes effect next boot

SleepState=Windows is the default. It leaves the kernel with only mem_sleep: [s2idle], which suspends poorly on Alder Lake under Linux. Linux enables S3 (deep). Verify after reboot with cat /sys/power/mem_sleep.

Silencing the POST beep

The beep can be suppressed while the serial remains unwritten. Modern ThinkPads carry no separate buzzer. POST beeps go through the HDA codec, and the codec’s mute state survives a reboot. KeyboardBeep and PasswordBeep in BIOS have no effect on POST error beeps.

/proc/acpi/ibm/volume reports the state and is typically read-only (volume_control=N). It mirrors the codec rather than driving it. Muting via ALSA flips it.

# /etc/systemd/system/mute-before-shutdown.service
[Unit]
Description=Mute audio codec at shutdown to silence the BIOS POST error beep
After=sound.target
Wants=sound.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'for c in Master Speaker Headphone; do /usr/bin/amixer -c0 -q set "$c" unmute 2>/dev/null; done; exit 0'
ExecStop=/bin/sh -c 'for c in Master Speaker Headphone; do /usr/bin/amixer -c0 -q set "$c" mute 2>/dev/null; done; exit 0'

[Install]
WantedBy=multi-user.target

Two traps are worth avoiding.

Do not use DefaultDependencies=no with Before=shutdown.target. That runs the unit so late that /dev/snd is gone, and ExecStop fails with Invalid card number '0'. Normal dependencies stop the unit early enough that the card still exists.

Always pass -c0. Without it amixer uses the ALSA default device, which for root routes through PipeWire and silently does nothing.

Test it without rebooting. systemctl stop should mute and systemctl start should unmute.

systemctl stop mute-before-shutdown && grep mute /proc/acpi/ibm/volume   # expect: on
systemctl start mute-before-shutdown && grep mute /proc/acpi/ibm/volume  # expect: off

Remove the unit once the serial is written. The beep then stops at source.

Caveats

The U1 toolkit is marked Lenovo Confidential - for development, service and manufacturing use only. Lenovo support will not discuss it.

The UUID is auto-generated. The original is unrecoverable by any method. This is harmless for normal use. Anything keyed to it, such as MDM enrolment records or some licensing, will no longer match.

A replacement board may carry different silicon from the original, since CPU and soldered RAM differ between SKUs. The MTM you write encodes the original configuration, so DMI will not match the actual hardware. Writing it back is still correct. It is the machine’s identity, and what warranty and parts lookups key on.

Writes through this tool are reversible. The menus offer Read and Delete alongside Add, carry confirmation prompts, and refuse to silently overwrite (Target block already exists). The one-shot Right-to-Repair writer behaves differently.

Only write a serial that genuinely belongs to the machine in front of you. Verify it against two independent sources before committing.

Takedown

The toolkit binaries are mirrored here to keep a repair path open for hardware their vendor no longer supports. See TAKEDOWN_REQUESTS.txt for the contact address and the process.