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.