vtmarvin

@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 00So the controller firmware is: 211108-0000-00I only used the read-only -S option; I did not flash or modify the controller firmware.

ASM1166 wrapped GPT corruption – confirmed on Gigabyte B550I AORUS PRO AX, workaround verifiedSharing 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. SystemGigabyte 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 symptomMonthly parity checks repeatedly found exactly the same two sync errors: 2743151176 2743151208A 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 writeAll five 8 TB disks have: total sectors: 15628053168 real backup GPT: 15628053135 wrapped address: 2743151247where: wrapped = (total sectors - 33) mod 2^32Using 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 .. 2743151215Using 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 workaroundBefore 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 DisabledI left: Other PCI Device ROM Priority = UEFI OnlyThe 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. VerificationAfter 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: cold boot — sentinel unchanged start array — sentinel unchanged warm reboot — sentinel unchanged another cold boot — sentinel unchanged 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 Disabledthis 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 errorsI 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 spaceAfter repairing the affected files, I initially found that two disks still returned: wrapped GPT == real backup GPTAt first this looked like the problem had returned. However, checking those locations with XFS fsmap showed: free space 33on 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 resultWith this BIOS configuration: CSM Support Enabled Storage Boot Option Control DisabledI 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 scriptThe 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 resultIf the script reports: RESULT : MATCH - backup GPT copy found at wrapped addressthe 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 checkFor 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 33means 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 informationLinux cannot reliably read vendor-specific BIOS settings such as: Storage Boot Option Control = Disabledso 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 warningIf 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.