hey y'all - was looking for some insight with an odd issue i was facing:

Issue:
My new ASUS mobo throws the "GPT Header Corruption has been detected..." error at post but only when two of my HDDs are plugged into the StarTech ASM1166 card.

Workaround atm: Pressing F1 to get past the error and into BIOS, selecting the Unraid USB to launch as normal. Further workaround would be to disable waiting at POST errors via BIOS, but haven't done that until I find out more.

System:

• Unraid 7.3.1

• ASUS Prime B760M-AYW WiFi D4 II, BIOS 1837, i5-14400

• StarTech 6-Port SATA III 6Gbps PCIe Card, Non-RAID (6P6G-PCIE-SATA-CARD)

  • flashed to firmware 211108-0000-00 (the stock firmware wasn't detecting on my mobo until I flashed / updated)

• 4 onboard SATA ports that are occupied by 3x 12TB HDDs + 1x 4TB HDD

• ASM1166 currently holds 2x 4TB HDDs + 1x Cache SSD

• BIOS: CSM disabled, Secure Boot set to "Other OS", Recovery Policy left to default (Local User Control)

What else I've checked:

• sgdisk -v is clean on every drive

• Long SMART tests have passed on the drives plugged into the StarTech card

• Warning appears with the Unraid USB removed as well

Additional notes:

• StarTech card plugged in with 0 drives plugged in does not prompt the error, and when the SSD Cache drive is plugged in on it's own, it does not cause any issues either

• The same two drives that are causing this error DO NOT prompt the error to appear when plugged into the native sata ports on the motherboard (leading me to believe the drives are not the issue)

• 12TB drives are brand new and passed their addition to parity with 0 issues, 4TB drives are ~3,000 hours in

• SSD is MBR (doesn't trigger the error), both HDDs are GPT and do trigger the error via the card

Questions / Insight I was looking for:

• Is there a known cause for why the drives would only throw this error when plugged into the ASM1166?

• Is this a cosmetic error / is it safe to continue using / storing files on the drives knowing this error appears at POST?

Diagnostic output attached as well, and thank you for any help insight y'all

There's a LSI HBA I can purchase if needed, but wasn't sure if it's worth swapping over from the ASM1166's lower power usage / smaller profile.

diagnostics-20261004-1619.zip

Your diagnostics look fine from the Unraid side. Through the ASM1166, Linux sees both 4TB disks at full size with valid GPT partitions, and the layout is the same as the 4TB disk on the onboard ports. There are no disk or controller errors in the logs, and your clean sgdisk -v matches that. The partitions aren't corrupt.

During POST, the board doesn't read those disks with its own driver. It reads them through the ASM1166's UEFI firmware (option ROM). My best guess is that this option ROM has a problem with disks larger than 2TB. The backup GPT header is stored at the end of the disk, and on a 4TB disk that's past the 2TB point. If the controller firmware reports the wrong size or can't address that far, the BIOS reads the wrong sectors and decides the header is corrupt. That would also explain why the SSD doesn't trigger it: it uses MBR, so the BIOS doesn't check for a GPT on it.

If you want to confirm it, temporarily connect one of the 12TB disks to the card. It should also trigger the warning. A GPT disk smaller than 2TB shouldn't.

Is it safe? For normal use, yes. Unraid doesn't use the card's option ROM, so it's only the BIOS that sees the problem. The one thing to avoid is letting the BIOS "recover" or repair the GPT. If it's reading the disk wrong, a repair could write to the wrong place. Leave the recovery policy at "Local User Control", never accept a repair prompt, and don't set it to automatic.

Options:

- Keep pressing F1, or disable "wait for F1 if error" in the BIOS. Either is fine as long as the BIOS never repairs anything.

- If your BIOS has a setting to disable the option ROM for that PCIe slot, try it. Unraid boots from the USB, so it doesn't need the card's option ROM.

- Use the onboard ports for the large GPT disks and the card for the SSD or smaller disks.

I wouldn't buy an LSI HBA just for this. The card is working correctly in Unraid. The warning only comes from the BIOS.

I’m seeing what looks like the same issue on two systems, but there the firmware actually writes to the disk, without prompting and without logging any error. I’m posting because I don’t think “cosmetic” is a safe assumption, and your diagnostics suggest you could be exposed. (Disclaimer - I did use some Ai to assist on my journey)

My systems: two NAS OEM motherboards from a Chinese manufacturer, each with two onboard ASM1166 controllers and an AMI-based BIOS. One has 4TB disks (7,814,037,168 sectors each) and the other has 10TB disks.

What I found: during startup, the firmware writes each disk’s backup GPT (33 sectors) at a wrong address. It uses (total sectors − 33) mod 2^32, which is the correct address with the upper 32 bits dropped.

• On a 4TB disk, the backup GPT belongs at sector 7,814,037,135. The firmware writes a byte-for-byte copy at 3,519,069,839 instead, which is about 1.8TB into the disk and inside the data partition.

• 10TB disks are hit at the address that formula predicts for them.

How I confirmed it: on the 4TB unit, I wrote a known marker over those 33 sectors on every disk, rebooted, and read them back.

• Cold power-on: the marker was replaced by the GPT copy on every disk on one of the two controllers. The disks on the other controller kept their markers. Repeated three times.

• Warm restart: every disk, on both controllers, was overwritten. Repeated twice.

• With Fast Boot enabled: only the boot disk was overwritten.

• Errors: across 11 boots, the kernel logs show no SATA errors, resets or I/O errors, and SMART is clean. sgdisk -v also reports nothing, because the real primary and backup GPTs are fine. The damage is to whatever data was at the wrapped address.

It shows up in Unraid parity checks. When I ran Unraid on these units, non-correcting parity checks kept reporting sync errors at the same sectors, and I couldn’t explain them at the time. They match the wrapped address exactly:

• 10TB disks, partition start 64: sync errors at 2,353,004,440 / 448 / 456 / 464 / 472. That’s exactly the 33 wrapped sectors, in Unraid’s 4K steps.

• 4TB disks, partition start 64: sync errors at 3,519,069,768 to 3,519,069,800. The first was in February 2025, a few months after I bought the unit.

• 4TB disks whose partition started at 21,257,952: sync errors at 3,497,811,880 to 3,497,811,912. That’s the same physical address, because Unraid reports sectors relative to where each partition starts.

• Why one check showed only 2 errors, not 5: on a two-disk array (parity plus one data disk), both disks get their own GPT copy at the same spot. The copies only differ in the first and last 4K blocks, so parity only disagrees there.

My theory (not proven): it matches JorgeB’s option ROM idea. If the ASM1166 UEFI path gets disk addresses wrong above 2TB, the firmware reads the backup GPT from the wrong place and decides it’s corrupt. EDK2’s partition driver restores an invalid backup GPT automatically. I haven’t confirmed that AMI’s code does the same. If it does, it would write to that same wrong address, which is exactly what I’m seeing. Your BIOS asks first, which is why I’d check rather than assume nothing has been written.

From your diagnostics:

• Disk1 (WD40EFZZ) is on the ASM1166 card. It’s a 61%-full XFS array disk, so if the BIOS has ever written at the wrapped address, it has very likely written over file data.

• Your 4TB disks are the same size as mine (7,814,037,168 sectors), so the wrapped address is identical: sector 3,519,069,839.

• Your logs don’t include a completed parity check, so they can’t show whether anything has been written yet.

Why it matters on Unraid: XFS array disks have no data checksums. If this write happens, nothing reports it. If it has happened on disk1, a non-correcting parity check should show sync errors at sectors 3,519,069,768 to 3,519,069,800, which is your partition start of 64 plus 4K steps. A correcting check would rewrite parity to match the damaged data, and then the original can’t be rebuilt. Please don’t run a correcting check until you’ve confirmed either way.

Read-only check (it only reads, it doesn’t write anything). It reports whether each disk over 2TiB has its backup GPT copy at the wrapped address:

for d in /dev/sd?; do
  N=$(blockdev --getsz $d); [ "$N" -le 4294967296 ] && continue
  REAL=$((N-33)); WRAP=$((REAL % 4294967296))
  a=$(dd if=$d bs=512 skip=$WRAP count=33 iflag=direct 2>/dev/null | md5sum | cut -c1-32)
  b=$(dd if=$d bs=512 skip=$REAL count=33 iflag=direct 2>/dev/null | md5sum | cut -c1-32)
  h=$(dd if=$d bs=512 skip=$((WRAP+32)) count=1 iflag=direct 2>/dev/null | head -c 8 | tr -cd '[:print:]')
  [ "$a" = "$b" ] && r="MATCH - backup GPT copy found at wrapped address" || r="no match"
  echo "$d N=$N WRAP=$WRAP $r [$h]"
done

• “MATCH” with [EFI PART]: the firmware has written there, and whatever data was at that spot has been overwritten.

• “no match”: nothing has been written there, at least so far.

I’d run it on all your disks. Anything that has ever been on the ASM1166 card matters most, including the unassigned 4TB.

Anyone else with an ASM1166: if you’ve had unexplained parity sync errors that come back at the same sectors, calculate (disk sectors − 33) mod 4294967296, subtract your partition start (usually 64), and compare.

I’ve reported this to the manufacturer with the full test data. Results from other hardware would help show whether this is down to the ASM1166 itself or the vendor’s firmware.

Thanks riff.79, that's a very useful finding. I checked your numbers and they're exact. (disk sectors − 33) mod 2^32 gives 3,519,069,839 for 4TB disks and 2,353,004,511 for 10TB disks. After you subtract the partition start, the 33 sectors always cover exactly five 4K blocks. That matches the 5 parity sync errors that keep coming back at the same sectors, which we've seen in other reports with ASM116x controllers. Your explanation for the 2-error case also makes sense. So I agree this isn't always cosmetic. On some boards, the firmware may write the backup GPT to the wrong place without asking.

@dxwntime this changes my earlier advice a little. It's probably still fine in your case, but it's worth checking:

- The fact that you still get the warning on every boot is a good sign. If your BIOS had already written the backup GPT to the wrong address, that copy would read back as valid on the next boot, and the warning would most likely stop. So your BIOS is probably only warning, not writing. That's a suspicion, though, not proof.

- To confirm, run riff.79's script. It only reads. Run it on all disks that have ever been on the card, including the unassigned 4TB.

- Run a non-correcting parity check. If it finds sync errors at sectors 3,519,069,768 to 3,519,069,800, post the result before you do anything else.

- Don't run a correcting check until we know which disk has the copy. If it's on disk1, a correcting check would make parity match the damaged data, and the original data couldn't be rebuilt. Your parity disks are on the onboard ports, so it's disk1 that matters here.

- If disk1 does show a match, it doesn't mean a file was damaged for sure. That spot could be free space. We can find out which file is affected, if any, and you can restore that file from backup.

To prevent it:

- If your BIOS lets you disable the option ROM for that PCIe slot, do it. Unraid doesn't need it to boot from USB, and without it the BIOS can't read or write those disks at POST.

- Keep the GPT recovery policy at "Local User Control" and never accept a repair prompt.

- Or, as before: put the 4TB-and-larger GPT disks on the onboard ports and use the card for the SSD or smaller disks.

ASM1166 wrapped GPT corruption – confirmed on Gigabyte B550I AORUS PRO AX, workaround verified

Sharing another confirmed case of the ASM1166 wrapped-backup-GPT issue, this time on different hardware, together with the workaround that has stopped the corruption on my system.

This is intended as a report of what happened and what worked on my particular hardware. I am not able to provide troubleshooting/support for other hardware or BIOS combinations.

System

• Gigabyte B550I AORUS PRO AX

• BIOS FF

• ASMedia ASM1166 PCIe SATA controller

• PCI ID 1b21:1166, rev 02

• 5 × 8 TB WD80EFPX HDDs connected to the ASM1166

• UEFI boot from the Unraid USB drive

• Incident diagnosed on Unraid 7.3.2

• System subsequently upgraded to Unraid 7.3.4

Original symptom

Monthly parity checks repeatedly found exactly the same two sync errors:

2743151176
2743151208

A correcting parity check removed them, but after a later reboot the same two errors appeared again.

SMART data was clean and there were no SATA resets or I/O errors in the Linux logs.

Confirming the wrapped GPT write

All five 8 TB disks have:

total sectors:       15628053168
real backup GPT:     15628053135
wrapped address:     2743151247

where:

wrapped = (total sectors - 33) mod 2^32

Using a read-only comparison of the 33 sectors at that wrapped address against the real backup GPT at the end of each disk, all five HDDs initially contained an exact copy of their own backup GPT at the wrapped location.

The hashes matched byte-for-byte, including the EFI PART header.

The real GPTs at the ends of the disks were still valid. The unwanted writes were inside the usable data area.

Because the XFS partition starts at sector 64, the corresponding XFS-relative range was:

2743151183 .. 2743151215

Using XFS fsmap, I checked what those 33 sectors belonged to.

On three of the data disks the region overlapped allocated file data. On the fourth data disk it happened to be free space.

So in this case this was not just a cosmetic GPT warning: approximately 16.5 KiB of filesystem data had actually been overwritten on multiple disks.

BIOS workaround

Before experimenting with the BIOS, I shut the server down and physically disconnected all HDDs from the ASM1166.

On this Gigabyte BIOS I changed:

CSM Support                  Enabled
Storage Boot Option Control  Disabled

I left:

Other PCI Device ROM Priority = UEFI Only

The system continued to boot normally in UEFI mode from the Unraid USB drive.

The BIOS description for Storage Boot Option Control says that it controls execution of UEFI and Legacy Storage OpROMs.

My assumption is therefore that disabling it prevents the ASM1166 storage Option ROM from being executed during POST.

This is a motherboard/BIOS-specific setting. Other vendors may use different names or may not expose an equivalent option.

Verification

After correcting parity, I saved a hash of the affected 33-sector area on the parity disk as a sentinel.

I then tested with all HDDs connected:

1. cold boot — sentinel unchanged

2. start array — sentinel unchanged

3. warm reboot — sentinel unchanged

4. another cold boot — sentinel unchanged

5. start array again — sentinel unchanged

Before the BIOS workaround, the wrapped location had repeatedly become an exact copy of the backup GPT after boot.

With:

CSM Support                  Enabled
Storage Boot Option Control  Disabled

this no longer happened.

I then restored/repaired the three affected files and ran a complete non-correcting parity check across the full 8 TB array.

Result:

0 sync errors

I subsequently upgraded Unraid from 7.3.2 to 7.3.4 and rebooted again.

No new wrapped-GPT write occurred on active data.

Important detail: a MATCH may be stale data in free space

After repairing the affected files, I initially found that two disks still returned:

wrapped GPT == real backup GPT

At first this looked like the problem had returned.

However, checking those locations with XFS fsmap showed:

free space 33

on both disks.

Those GPT bytes were simply remnants of the original corruption left behind in now-unallocated disk space.

They were not evidence of another write during the latest boot.

So after recovery, a simple MATCH at the wrapped location does not necessarily prove that the latest boot caused another corruption event.

It is important to also check whether that disk range is currently allocated to filesystem data or is merely stale content in free space.

Current result

With this BIOS configuration:

CSM Support                  Enabled
Storage Boot Option Control  Disabled

I have successfully completed:

• multiple cold boots

• a warm reboot

• an Unraid OS upgrade and reboot

• repair/restoration of the affected files

• a full non-correcting parity check with 0 errors

and I have not seen the ASM1166 recreate the wrapped backup GPT on an active data region.

---

Read-only detection script

The following script only reads the disks.

It does not modify the GPT, filesystem, parity, or disk contents.

It checks SATA disks larger than 2 TiB for a byte-for-byte copy of their own backup GPT at the suspected 32-bit wrapped address.

#!/bin/bash

echo "ASM1166 wrapped GPT read-only check"
echo

for sys in /sys/block/sd*; do
    dev="/dev/${sys##*/}"

    [ -b "$dev" ] || continue

    N=$(blockdev --getsz "$dev" 2>/dev/null) || continue

    # Skip disks <= 2 TiB / 2^32 sectors
    [ "$N" -gt 4294967296 ] || continue

    REAL=$((N - 33))
    WRAP=$((REAL % 4294967296))

    WRAP_HASH=$(
        dd if="$dev" bs=512 skip="$WRAP" count=33 \
            iflag=direct status=none |
        sha256sum | awk '{print $1}'
    )

    REAL_HASH=$(
        dd if="$dev" bs=512 skip="$REAL" count=33 \
            iflag=direct status=none |
        sha256sum | awk '{print $1}'
    )

    echo "$dev"
    echo "  sectors       : $N"
    echo "  real GPT start: $REAL"
    echo "  wrapped start : $WRAP"

    if [ "$WRAP_HASH" = "$REAL_HASH" ]; then
        echo "  RESULT        : MATCH - backup GPT copy found at wrapped address"
    else
        echo "  RESULT        : no match"
    fi

    part="${dev}1"

    if [ -b "$part" ]; then
        partname=$(basename "$part")
        start=$(cat "/sys/class/block/$partname/start" 2>/dev/null)

        if [ -n "$start" ] && [ "$WRAP" -ge "$start" ]; then
            echo "  partition start: $start"
            echo "  relative start : $((WRAP - start))"
        fi
    fi

    echo
done

echo "IMPORTANT:"
echo "A MATCH proves that GPT bytes are present at the wrapped address."
echo "It does NOT prove that the latest boot wrote them."
echo "They may be stale bytes in currently free filesystem space."

Interpreting the result

If the script reports:

RESULT : MATCH - backup GPT copy found at wrapped address

the 33 sectors at the wrapped address are identical to that disk's backup GPT.

Before running a correcting parity check, I would investigate whether those sectors belong to allocated filesystem data.

---

XFS allocation check

For an XFS Unraid data disk, the affected disk LBA needs to be converted to a filesystem-relative sector by subtracting the partition start.

For example:

DEV=/dev/sdd
MOUNT=/mnt/disk2

PART="${DEV}1"
PARTNAME=$(basename "$PART")

PARTSTART=$(cat "/sys/class/block/$PARTNAME/start")
N=$(blockdev --getsz "$DEV")
WRAP=$(((N - 33) % 4294967296))
FSSTART=$((WRAP - PARTSTART))

echo "Disk wrapped address : $WRAP"
echo "Partition start      : $PARTSTART"
echo "XFS-relative address : $FSSTART"

xfs_io -r -c "fsmap -d $FSSTART $((FSSTART + 32))" "$MOUNT"

This is also read-only.

For example:

free space 33

means the GPT-looking bytes are currently sitting in unallocated space.

If the output instead references an inode/data extent, that range is allocated and should be investigated before modifying parity.

---

Read-only hardware / boot information

Linux cannot reliably read vendor-specific BIOS settings such as:

Storage Boot Option Control = Disabled

so that setting should be checked manually in the BIOS.

The following commands can, however, collect the relevant hardware and boot information without modifying anything:

echo "=== BOARD ==="
dmidecode -s baseboard-manufacturer
dmidecode -s baseboard-product-name

echo
echo "=== BIOS ==="
dmidecode -s bios-version
dmidecode -s bios-release-date

echo
echo "=== BOOT MODE ==="
if [ -d /sys/firmware/efi ]; then
    echo "UEFI"
else
    echo "Legacy"
fi

echo
echo "=== SECURE BOOT ==="
SB=$(find /sys/firmware/efi/efivars -maxdepth 1 \
    -name 'SecureBoot-*' 2>/dev/null | head -1)

if [ -n "$SB" ]; then
    printf "SecureBoot: "
    od -An -t u1 -j4 -N1 "$SB"
else
    echo "SecureBoot variable not available"
fi

echo
echo "=== ASMEDIA CONTROLLERS ==="
lspci -nn | grep -Ei 'ASM116|1b21:116'

On my system the Unraid USB continued to boot in UEFI mode after enabling CSM.

---

One recovery warning

If recurring parity errors line up with this wrapped-GPT location, I would not immediately run a correcting parity check.

First determine whether the wrapped GPT copy exists and whether its sectors overlap allocated file data.

A correcting parity check cannot restore the overwritten file bytes. It can only make parity consistent with whatever data currently exists on the data disks.

Again, this is only a report of what happened and what worked on my specific hardware combination. I am sharing the commands because they are read-only and may help identify the same failure mode elsewhere, but I cannot provide troubleshooting/support for other systems.

Edited November 8Nov 8 by vtmarvin

Thanks @vtmarvin , that's a very useful report. Your numbers are exact, and this is the first confirmation that stopping the storage option ROM from running also stops the writes.

A few notes for anyone who finds this thread later:

• Getting 2 sync errors instead of 5 means every disk in the array got its own GPT copy, parity included. The three middle blocks are all zeros on every disk, so parity still matches there. Only the first and last blocks differ.

• Using the parity disk as the sentinel was the right choice. If a data disk still has the old GPT copy, a new write puts the same bytes back, so you can't detect it there.

• If the array disks are encrypted, subtract the encryption header offset as well as the partition start before you run the fsmap check.

• On that Gigabyte BIOS, you must enable CSM to see the option, and with CSM enabled you can't use Secure Boot, though that's currently not possible to use with Unraid, but maybe it will with Unraid 8. On other boards, check first for a per-slot option ROM setting.

If you know it, which firmware version is on your ASM1166? It's the one detail we're still missing to compare the cases.

Thanks @vtmarvin for posting your update, and for the read-only script. I have found the root cause in my case with the ASM1166 (rev 02) controllers, and the controller firmware update stopped it on my hardware.

ASM1166 firmware version as reported by the vendor's flash tool (the same on every controller I checked):

Before: 19 10 17 00 00 00

After: 24 06 25 00 00 05

With the old version, the backup GPT was written to (total sectors - 33) mod 2^32 on disks over 2 TiB. It was a byte-for-byte copy of each disk's own backup GPT, and it overwrote file data. On my units it varied with how the machine restarted: a cold power-on and a warm restart overwrote different disks, and enabling Fast Boot limited it to the boot disk. No ATA or I/O errors were logged.

After the update, a marker written over the wrapped 33 sectors stayed intact across cold and warm boots on every controller I tested. A full scrub of the original data disks also came back clean. My sample is small, so I am not calling it fully resolved.

The version looks like a YYMMDD build date followed by a build number (2019-10-17 before, 2024-06-25 after).

On your workaround: disabling Storage Boot Option Control stops storage option ROMs running at POST, and a controller firmware update may be fixing the same boot-time code. The way my overwrites changed with cold versus warm boots and with Fast Boot points the same way. I have not tested that setting on my hardware, so I can't say the two fixes are the same thing as I have resolved my issue.

Edited November 8Nov 8 by riff.79
missed the person I was replying to

@JorgeB Yes — I was able to read it directly from Linux using the ASM116x firmware tool:

ASM116x Firmware Update Tool V1.1.1.0

Dev[0]::FWver from PCIe: 21 11 08 00 00 00

So the controller firmware is:

211108-0000-00

I only used the read-only -S option; I did not flash or modify the controller firmware.

Edited November 8Nov 8 by vtmarvin

I have exactly the same issue on Asrock N100M using generic AliExpress ASM1166 card currently running 211108-0000-00. I cannot enable CSM without external graphics card (limitation of MB BIOS) and only workaround which seems to work is to enable Fast Boot. Does anyone have working FW which fixes the issue and at the same time doesn't break ASPM? @riff.79 I'm not able to find 240625-0000-05 anywhere and I'm not sure if it's good idea to even try it on my card.

On 11/8/2026 at 11:26 PM, vtmarvin said:

@JorgeB Yes — I was able to read it directly from Linux using the ASM116x firmware tool:

ASM116x Firmware Update Tool V1.1.1.0

Dev[0]::FWver from PCIe: 21 11 08 00 00 00

So the controller firmware is:

211108-0000-00

I only used the read-only -S option; I did not flash or modify the controller firmware.

Yes I was told that the 22 leading firmware should have fixed this issue @vtmarvin

22 hours ago, Morbo said:

I have exactly the same issue on Asrock N100M using generic AliExpress ASM1166 card currently running 211108-0000-00. I cannot enable CSM without external graphics card (limitation of MB BIOS) and only workaround which seems to work is to enable Fast Boot. Does anyone have working FW which fixes the issue and at the same time doesn't break ASPM? @riff.79 I'm not able to find 240625-0000-05 anywhere and I'm not sure if it's good idea to even try it on my card.

I have a few versions of the firmware - any clues on your controller to what its a clone of?

7 minutes ago, riff.79 said:

I have a few versions of the firmware - any clues on your controller to what its a clone of?

I don't really know, but it looks exactly like "Axagon PCES-SA6". I don't even know the size of flash chip. 211108-0000-00 was default factory firmware it came with. Do you have any version which you would recommend to try first? I will check flash chip size first. Thank you.