Troubleshooting

Common issues and solutions for the Interceptor Carrier Board

  12 minute read  

This guide covers common issues encountered with the Interceptor Carrier Board and their solutions.

Power Issues

Reseating the compute module

Several procedures on this page start with reseating the compute module. Read this first, because reseating is not free.

The module sits on fine-pitch board-to-board connectors, and those connectors have a finite mate life. Every removal and refit spends part of it. Worn or displaced contacts produce exactly the intermittent symptoms that prompt reseating in the first place, so repeated reseating can manufacture the fault you are trying to clear.

Reseat once. Power off, unplug the supply, lift the module evenly, inspect both the module and board connectors for bent or missing contacts under good light, and refit with even pressure on both connectors.

If one reseat does not fix it, move to a known-good module or contact support@exaviz.com rather than repeating the cycle. Tell us roughly how many times the module has been removed over its life - that number changes what we look at, and it is not recoverable once the board is in front of someone else.

System won’t power on

Symptoms: Power LED doesn’t illuminate, no activity.

Solutions:

  1. Verify ATX PSU is switched on (check rear switch)
  2. Check that 24-pin ATX connector is fully seated
  3. Verify PSU is functional (test with another system or PSU tester)
  4. Check front panel power button wiring on J2

System powers off randomly / crashes

Symptoms: System runs for a while then shuts down or freezes.

Likely Cause: Unstable +3.3V rail from PSU.

Solutions:

  1. Replace PSU - This is the most common cause. Low-quality PSUs cannot maintain 3.3V under low load conditions typical of Pi-based systems
  2. Use a Flex ATX PSU from the Exaviz Store or a quality brand (Corsair, EVGA, Seasonic)
  3. Check voltage with multimeter (should be 3.3V ±5%)

System unstable under load

Symptoms: Crashes when accessing SATA drives or using PoE.

Solutions:

  1. Verify PSU wattage is adequate for your configuration
  2. Check 12V rail capacity (especially with PoE boards)
  3. Ensure all power connections are secure

See also: SATA drives dropping under sustained I/O for detailed symptoms and diagnosis when drives fail under load.

Boot Issues

Keyboard not working at boot menu

Symptoms: Keyboard works after OS loads but not in boot menu or during early boot.

Cause: Some keyboards (especially Apple keyboards) are not recognized during early boot stages.

Solution: Use a standard PC/Windows keyboard for boot menu navigation and initial setup. Your preferred keyboard can be used after the OS loads.

“GPT no bootable partition” error

This error has two common causes:

Cause 1: CM5 USB boot limitation

CM5 cannot boot from USB 2.0, and the Interceptor board only has USB 2.0 ports.

Solutions for CM5:

  1. Use SD card boot - If CM5 has blank eMMC, it will boot from SD
  2. Flash eMMC - Use a separate Raspberry Pi IO Board (CM4 or CM5 IO Board both work) with rpiboot to flash the OS to eMMC, then install CM5 on the Interceptor

Cause 2: Windows flashing issue

Flashing OS images from Windows can sometimes create invalid GPT partition tables that prevent booting. This affects CM4 and CM5 when booting from USB flash drives.

Solutions for Windows flashing issues:

  1. Flash from Linux or macOS - This consistently resolves the issue
  2. Flash to SD card or eMMC instead of USB flash drive
  3. Try a different tool - Raspberry Pi Imager or Balena Etcher

See FAQ for more details.

No video output

Symptoms: HDMI displays show no signal.

Solutions:

  1. Try the other HDMI port (J4 or J5)
  2. Banana Pi CM4: Only HDMI0 (J4) works - this is a known limitation
  3. Check config.txt for HDMI configuration issues
  4. Try a different HDMI cable or monitor
  5. Connect via SSH to verify system is booting

SD card not detected

Solutions:

  1. Try a different SD card
  2. Reformat card as FAT32 (for boot partition)
  3. Re-flash the OS image
  4. Check SD card slot for debris or damage

Slow boot from USB flash drive (~45 second delay)

Symptoms: System takes 45-60 seconds to boot from a USB flash drive. You see the network link activate and DHCP requests before the OS finally starts loading.

Cause: This is a boot order timing issue, not a hardware problem. The USB flash drive needs 1-2 seconds after power-on for the USB subsystem to enumerate it. This can bite when your boot order puts SD/eMMC before USB and network after it. SD fails almost instantly (~100ms), so the bootloader reaches USB before the drive is ready. It moves on to Network boot, which takes 30-60 seconds to timeout (DHCP requests, link negotiation). After the timeout, the boot loop restarts and USB succeeds on the second pass.

You are effectively paying a ~45 second Network boot penalty because the USB drive needed an extra second or two to enumerate.

Fix: Set USB as the first boot device. The bootloader’s own initialization (EEPROM config, clock setup) provides enough time for the USB subsystem to be ready by the time it checks the first boot mode:

# CM4: Requires a Raspberry Pi IO Board + rpiboot to update EEPROM
# CM5: Can be updated from the running system
sudo rpi-eeprom-config --edit

Set:

BOOT_ORDER=0xf215

This decodes as (right to left): USB 2.0, then SD/eMMC, then Network, then restart the loop. It is the same value recommended under Bootloader Settings, so setting it here does not put the two pages in conflict.

The USB digit for the Interceptor is 5 (BCM-USB-MSD), not 4 (USB-MSD). Digit 4 boots from a USB controller on the PCIe bus, and on the Interceptor that PCIe lane carries the JMicron JMB58x SATA controller. The board’s USB comes from the CM4’s own USB 2.0 host, which is what digit 5 selects. A boot order built around 4 has nothing to enumerate on this hardware.

With USB first, the drive is already enumerated when the bootloader checks it, so it boots immediately without ever reaching Network.

Network Issues

Ethernet switch not detected (RTL8367RB err=-19)

Symptoms:

  • dmesg shows rtl8367rb: err=-19 or similar
  • No DHCP IP address on WAN port
  • Network interfaces missing

Likely Cause: Usually indicates a bad CM4 module or improper seating.

Solutions:

  1. Reseat the CM4 module once - see Reseating the compute module before repeating it
  2. Check CM4 connector pins for damage
  3. Test the CM4 on a Raspberry Pi IO Board if available
  4. Try a different CM4 module

No network connectivity

Symptoms: Cannot ping or SSH to the device.

Solutions:

  1. Check Ethernet cable connections
  2. Verify link LEDs on the RJ-45 ports are illuminated
  3. Try a different port on J8
  4. Check IP configuration:
    ip addr show

Only some ports working

Solutions:

  1. Check individual port LEDs
  2. Try different cables
  3. Check switch driver is loaded:
    sudo dmesg | grep rtl

Storage Issues

SATA drives not detected

Symptoms: Drives not showing in lsblk.

Solutions:

  1. Check SATA and power cables are connected
  2. Verify drives work in another system
  3. Check controller status:
    sudo dmesg | grep -i "sata\|jmb\|ahci"
lspci | grep -i sata

Poor SATA performance

Symptoms: Slow transfer speeds.

Solutions:

  1. Check for SATA errors:
    sudo dmesg | grep -i error
  2. Verify AHCI mode is enabled
  3. Check cable quality (use quality SATA III cables)

SATA drives dropping under sustained I/O

Symptoms:

  • Drives make beeping or clicking sounds under heavy I/O (RAID rebuild, large file copies)
  • Multiple SATA ports re-linking simultaneously
  • Kernel logs show ATA bus error and failed command: READ FPDMA QUEUED
  • Link speeds progressively degrade from 6.0 Gbps → 3.0 Gbps → 1.5 Gbps
  • System load spikes (load average exceeds CPU count)

How it presents:

A single bad SATA cable causes one port to re-link repeatedly. But when multiple ports start failing at the same time — especially during sustained I/O like a RAID rebuild — the cause is almost always an undersized PSU that cannot deliver enough current on the 12V rail.

The drives momentarily lose power, causing the SATA link to drop. The kernel detects the link failure and re-establishes it at a lower speed. This cycle repeats, degrading performance further and producing audible beeping as drives spin down and back up.

How to diagnose:

  1. Check how many ports are re-linking:

    # Count re-link events per port
dmesg | grep -c "ata1: SATA link up"
dmesg | grep -c "ata2: SATA link up"
dmesg | grep -c "ata3: SATA link up"

  2. Check for speed degradation and bus errors:

    # Look for speed limiting and failed commands
dmesg | grep -E "ata[0-9]: (limiting|SATA link)"
dmesg | grep "failed command"

  3. If one port is re-linking → likely a bad cable (swap the cable)

  4. If multiple ports are re-linking simultaneously under load → PSU cannot supply enough power

Solutions:

  1. Stop any heavy I/O immediately (e.g., stop a RAID rebuild) to prevent potential data loss:
    sudo mdadm --stop /dev/md0
  2. Upgrade your PSU. See the sizing guide below.
  3. Once the PSU is replaced, reassemble and rebuild:
    sudo mdadm --assemble /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1

Fan Issues

Fans running at full speed

Expected Behavior: The fan headers (M1-M4) do not support PWM speed control. Fans will always run at full speed when connected.

Workaround: Use low-noise fans or external fan controllers if noise is a concern.

Fans not spinning

Solutions:

  1. Verify fans are 12V DC (not PWM-only)
  2. Check fan connections
  3. Test fans on another 12V source

Serial Console Issues

Cannot connect via UART

Solutions:

  1. Use a 3.3V USB-to-Serial adapter (not 5V!)
  2. Check TX/RX are not swapped:
    • Adapter TX → Board RX (J2 Pin 6)
    • Adapter RX → Board TX (J2 Pin 5)
    • Connect GND
  3. Use correct serial settings: 115200 8N1

Video Issues

No HDMI output

Symptoms: No video on either HDMI port.

Solutions:

  1. Reseat the compute module once - improperly seated modules are a common cause of HDMI issues. Power off, remove the CM4/CM5, and reinstall ensuring proper alignment on both connectors. Read Reseating the compute module first: repeating it can create the fault you are chasing
  2. Check connector pins — Pins can become damaged invisibly during installation
  3. Try a different HDMI cable
  4. Try the other HDMI port
  5. Test on a Raspberry Pi IO Board — If available, test the CM4 on a standard Pi IO Board. If the green LED doesn’t light, the module may be defective
  6. Try a known-good module — If you have another CM4/CM5, swap to verify

No display on HDMI1 (Banana Pi)

Expected: This is a known limitation. Only HDMI0 (J4) works with Banana Pi CM4.

4K resolution issues

Solutions:

  1. Verify monitor and cable support HDMI 2.0
  2. Check config.txt settings:
    hdmi_enable_4kp60=1

Logging and Diagnostics

No logs from before a reboot (“journalctl -b -1” is empty)

Symptoms: After rebooting a board to recover from a problem, there is no record of what happened. journalctl -b -1 returns nothing, and journalctl --list-boots only ever shows a single boot.

Cause: Raspberry Pi OS keeps the systemd journal in RAM only. It ships /usr/lib/systemd/journald.conf.d/40-rpi-volatile-storage.conf containing Storage=volatile, which discards all logs on every reboot. This is a Raspberry Pi OS default, not an Exaviz setting, and it protects SD cards from write wear.

The practical consequence is that rebooting a misbehaving board destroys the evidence of why it misbehaved — usually before anyone has collected it.

To confirm this is what you are seeing:

# shows the effective setting from all config locations
systemd-analyze cat-config systemd/journald.conf | grep -E '^Storage'

# /run/log/journal means RAM only; /var/log/journal means persistent
journalctl --header | grep 'File path'

Solution: Add a drop-in that sorts after the Raspberry Pi one:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-persistent-journal.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=200M
EOF

sudo systemctl restart systemd-journald
sudo journalctl --flush

Verify it took effect — this line should now appear, and it is absent when persistence is not working:

journalctl -b 0 -u systemd-journald | grep 'System Journal'
# System Journal (/var/log/journal/<machine-id>) is 8M, max 200M, 192M free

After the next reboot, journalctl --list-boots will list more than one boot.

Trade-off to weigh before enabling. Persistent logs mean additional writes to the boot media. On an SD card or USB flash drive that contributes to wear; on an SSD it is not a practical concern. The SystemMaxUse=200M cap bounds both the write volume and the disk space used, which matters on the small filesystems these boards typically run.

Our recommendation is to enable it, especially on any board you are actively diagnosing. Leaving it on means that when something does go wrong, the record already exists — whereas enabling it after an incident is too late to explain that incident.

To revert, delete /etc/systemd/journald.conf.d/99-persistent-journal.conf and restart systemd-journald.

Getting More Help

If you’ve tried these solutions and still have issues:

  1. Gather Information:

    # System info
uname -a
cat /etc/os-release

# Hardware detection
lsusb
lspci
lsblk

# Recent errors
sudo dmesg | tail -100

  2. Contact Support:

Next Steps

Last modified October 12, 2026