Portable Arch Linux: Surviving BIOS Updates — What Breaks and How to Fix It


estimated read time: 6 minutes

BIOS Updates and Portable Arch: What to Expect

BIOS updates are good practice — they ship security patches, AGESA microcode updates, and hardware fixes. They also, reliably, break things on a dual-boot portable Arch Linux setup.

This article documents the three specific failures that hit after a BIOS update on the ASUS PRIME X670E-PRO WIFI and how to fix each one. These are not edge cases — they have happened consistently across multiple updates.

The three issues, in the order you will encounter them:

  1. The Ethernet adapter changes its interface ID — no network connection
  2. Windows Update modifies the EFI boot entries — systemd-boot disappears
  3. Secure Boot custom keys are wiped — Arch refuses to boot

Issue 1: Ethernet Adapter Changes Interface ID

After a BIOS update, the network adapter may get reassigned a different kernel interface name. If systemd-networkd is configured to bring up a specific interface name and that name no longer exists, you will have no network connection.

This sounds straightforward but the catch is that you cannot use the network to fix the network. You will need to work offline.

Step 1 — Check the current interface state:

networkctl list

The output will look something like:

IDX LINK     TYPE     OPERATIONAL SETUP
  1 lo       loopback carrier     unmanaged
  2 eno1     ether    off         unmanaged
  4 wlp101s0 wlan     off         unmanaged
  5 enp99s0  ether    degraded    unmanaged

The degraded status is the clue. Note the interface name — in this example, enp99s0.

Step 2 — Check what systemd-networkd thinks the interface is called:

cat /etc/systemd/network/20-wired.network

It will look something like:

[Match]
Name=enp10s0

[Network]
DHCP=yes

If the Name= value does not match the degraded interface from step 1, that is your problem.

Step 3 — Fix it:

sudo nano /etc/systemd/network/20-wired.network

Update Name= to match the actual current interface name, then restart the network service:

sudo systemctl restart systemd-networkd

Network should now come up. If it does not, check networkctl status enp99s0 (or whatever your interface is) for further diagnostics.

Issue 2: Windows Hijacks the EFI Boot Order

This one is subtle and takes a while to notice. After a BIOS update, Windows may run its own boot repair and silently overwrite the EFI boot entries so that the Windows Boot Manager takes priority — bypassing systemd-boot entirely.

The symptom: after the BIOS update, the machine boots straight into Windows without showing the systemd-boot menu, even when Arch’s EFI entries are present.

The root cause is that both Windows and Arch live on the same EFI partition on the Samsung T7. When Windows modifies the EFI boot entries, it sets itself as the first entry.

Short-term fix — correct the boot order:

Enter the BIOS and check:

Boot > Boot Option Priorities > Boot Option #1

Set it back to the systemd-boot entry on the T7.

Longer-term fix — keep Windows off the T7’s EFI partition:

The proper solution is to ensure Windows hands off to its own internal NVMe EFI partition rather than sharing the T7. When switching to Windows from the systemd-boot menu, selecting the Windows entry should pass control to the internal drive’s EFI. This way, Windows updates cannot touch the T7’s boot entries.

The practical check: after booting Windows, open an elevated PowerShell and run:

bcdedit /enum firmware

Verify the Windows Boot Manager entry points to your internal NVMe (\EFI\Microsoft\Boot\bootmgfw.efi on the internal drive), not the T7.

Issue 3: Secure Boot Keys Are Wiped

This is the most disruptive failure and happens on every BIOS update. The Platform Key (PK) and associated Secure Boot key database is reset to factory state when the BIOS is flashed.

With your custom keys gone, the firmware no longer trusts your signed bootloader. Arch will not boot.

The recovery process is covered in full in Article 3 — Secure Boot with sbctl, but the quick summary:

  1. Disable Secure Boot (Advanced > Boot > Secure Boot > Other OS)
  2. Clear the Secure Boot keys (Advanced > Boot > Secure Boot > Clear Secure Boot Keys) — mandatory before re-enrolment
  3. Fix boot order, boot into Arch
  4. Run sbctl create-keys && sbctl enrol-keys -m
  5. Run sbctl sign-all
  6. Re-enable Secure Boot (Windows UEFI mode)

This takes about five minutes once you know the steps.

Issue 4 (Bonus): USB Detection Timing on BIOS 3287

The BIOS version PRIME-X670E-PRO-WIFI-ASUS-3287 introduced a specific timing regression with the Samsung T7. After this update, the T7 was intermittently not detected during POST — roughly 70% of boot attempts would fail to see the drive, causing the system to fall through to the Windows-only NVMe and skip the systemd-boot menu entirely.

Attempts to fix it via BIOS settings had no effect:

What actually fixed it: Moving the T7 from the U32G2_20 port to the U32G2_4 port on the motherboard. The U32G2_20 port appears to have a power delivery or enumeration timing issue introduced by the 3287 AGESA update (ComboAM5 PI 1.2.7.0). The U32G2_4 port has been stable since the switch.

If you see intermittent T7 detection failures after a BIOS update, try a different USB port before spending time in BIOS settings.

Summary

IssueTriggerFix
Ethernet ID changeBIOS update renames adapterUpdate Name= in /etc/systemd/network/20-wired.network
Windows hijacks boot orderBIOS update / Windows UpdateFix boot priority in BIOS, keep Windows on its own EFI partition
Secure Boot keys wipedAny BIOS flashClear keys, re-run sbctl enrol + sign-all
T7 not detected (3287 regression)BIOS 3287 AGESA updateMove T7 to U32G2_4 USB port

None of these are permanent damage — they are all recoverable in a few minutes. The key is knowing they are coming so you are not troubleshooting blind at midnight after what should have been a routine update.

Portable Arch Linux Series