IceRiver KS1/KS2 First Boot Setup Errors and Fixes

Wait the full boot sequence before declaring failure. From cord-in-wall to right-side green LED blinking (documented boot-complete signal) takes 60-90 seconds on KS1/KS2. Hitting `Detect IP` in the first 30 seconds runs against a network stack that has not come up yet. Wait, then re-run discovery. About 1 in 6 stranded-KS1/KS2 first-boot tickets clear on this single rule before any other troubleshooting begins. If the LED never transitions to blinking, power off at the rear rocker, wait 60 seconds for caps to bleed, retry once before escalating.

Read the router's DHCP client table directly. The `Detect IP` utility is a thin Windows app that broadcasts UDP and listens for replies - when it fails the router's DHCP table is the source of truth. Log into your gateway (typically `192.168.1.1`, `192.168.0.1`, or `10.0.0.1`), find Active Leases / DHCP Clients, match the chassis-sticker MAC to a row, copy the IP. Browser to `http://<that-ip>`, log in with `admin / 12345678`. Bookmark, set a DHCP reservation, never run Detect IP on this miner again.

Disable Windows Defender Firewall on the Private profile temporarily. Settings -> Privacy & Security -> Windows Security -> Firewall & network protection -> Private network -> Off. Re-run `Detect IP`. If the miner now appears, Windows was eating the inbound UDP discovery reply. Re-enable the firewall and add a permanent inbound exception for the IceRiver Detect IP utility executable; do not leave the firewall off long-term.

Disable every active VPN client on the discovery PC. WireGuard, Tailscale, GlobalProtect, Pulse Secure, NordVPN, ExpressVPN, corporate VPNs - any of these route traffic through a tunnel by default and the LAN broadcast never reaches the miner. Disconnect every VPN, including any quietly-running Tailscale exit node, before declaring the discovery utility broken.

Try `http://192.168.1.100` directly with credentials `admin / 12345678`. Documented factory-default static-IP fallback when DHCP fails. If your LAN is on `192.168.1.0/24`, just type the URL. If your LAN is on `192.168.0.x` or `10.0.0.x`, set your laptop NIC to a temporary `192.168.1.50/24` static (no gateway, no DNS), point-to-point cable through a small unmanaged switch, and try `192.168.1.100` from there.

Factory reset to clear stuck credential / config state. With the miner booted (right-side green blinking), press and hold the rear Button for 20 seconds until the red LED blinks, then release. Wait for the unit to reboot. After the second boot, the unit is back to documented defaults: DHCP enabled, credentials `admin / 12345678`, `192.168.1.100` factory-static fallback active. Re-discover via DHCP table or factory IP. If two reset attempts in a row do not change behavior, the controller is suspect - escalate.

Update firmware before doing anything else. Once the web UI is reachable, navigate to System / Status, note the current firmware version, then download the matching image (KS1 or KS2 - do NOT mix; wrong-model firmware bricks the controller) from `iceriver.io/firmware-download/`. Open Firmware Upgrade, select the `.bin` file, click Upgrade, do NOT power off during the flash. Wait for the documented success message and the automatic reboot. Re-confirm UI access and version. Verify-flag: confirm exact menu label against current IceRiver build before customers click. This single step heads off most intermittent stratum drops and weird LED tickets owners attribute to hardware faults.

Configure the Kaspa pool with a real stratum URL + payout address. Pool Configuration page -> enter a real Kaspa pool URL (verify-flag: pool-specific port, `4444` is common but confirm against the pool's docs) -> enter your `kaspa:` payout address (from a Kaspa wallet; `kaspatest:` for testnet) -> set worker name -> save -> reboot. Watch fans throttle from full-tilt to steady-state within 60-120 seconds; that transition is the controller authorizing hashboards into productive load. Hashrate appears in 5-10 minutes on both local UI and pool dashboard.

Change the default password immediately. User Settings -> set a unique strong password, save, reboot. Default `admin / 12345678` is documented public knowledge - leaving it unchanged on a network-reachable miner is a botware open door (we have seen Goldshell and IceRiver units hijacked into pool-redirection malware specifically because operators left defaults). Pair this with a DHCP reservation in the router so the miner pulls the same IP on every reboot.

Verify line voltage at the outlet under load. Multimeter on AC, probe at the operator-supplied `C14` cord plug while the miner is hashing. Documented input window `170 V - 300 V`. On North American `120 V` circuits expect sag - confirm voltage stays above the safe-boot window during fan startup inrush. If sag is severe (below `100 V` momentarily), move to a `220-240 V` outlet on a `15 A` or `20 A` breaker. KS1/KS2 are designed for `220-240 V`; running on `120 V` works but with reduced reliability margin.

SD-card recovery flash if the web UI is dead and factory reset does not bring it back. Power off, wait 60 seconds for caps to bleed, open the chassis. Locate the controller's microSD slot. Pull the SD card. On a separate machine, write the matching KS1 or KS2 firmware image (downloaded from `iceriver.io/firmware-download/`) to the SD with BalenaEtcher. Re-insert the SD, reassemble, power on. Watch for the recovery LED pattern - verify-flag: confirm against IceRiver's documented recovery indicator pattern for the exact firmware revision before customers escalate. After successful recovery, the unit boots back to factory defaults; re-run Tier 1 / Tier 2.

UART console access for static-IP override and diagnostic capture. Open the chassis (power off and 60-second wait first). Locate the UART debug header on the controller - typically a 3- or 4-pin TTL serial header labelled `UART`, `DEBUG`, `J3`, or `J5` depending on revision. Verify-flag: pinout varies by controller revision; confirm against a salvaged reference unit before powering up TX/RX - wrong wiring damages the USB-to-TTL adapter or the miner MCU. Connect USB-to-TTL (`GND`-to-`GND`, host `RX` to miner `TX`, host `TX` to miner `RX`, leave `VCC` unconnected). Open serial terminal at `115200 8N1`. Boot, watch console, use documented commands to override IP config or pull diagnostics.

C14 power cord diagnostics. If line voltage is good at the wall but the miner does not see clean power, swap the operator-supplied `C14` cord with a known-good one rated for the local voltage and at least `10 A` continuous. Cheap C14 cords are a documented failure mode - undersized conductors, oxidized pins, or marginal moulded plugs all show up as random first-boot wedge events. KS1/KS2 ship without a cord per the official IceRiver FAQ; cord is the operator's responsibility.

Inspect the controller for shipping damage. With the chassis open, look for unseated ribbon cables, dislodged heatsinks, loose hashboard-to-controller connectors, blackening near the AC input section, capacitor bulging on the controller PSU, or any sign of physical damage from shipping (KS1/KS2 are 5-7 kg packed and have arrived in the field with cracked solder joints from rough handling). Re-seat anything obviously loose; document anything visibly damaged before escalating to repair.

Stop DIY when any of these are true: factory reset fails to restore defaults across two consecutive attempts, firmware update fails mid-flash AND SD-card recovery does not bring the unit back, UART console returns no characters at any baud rate (`9600`, `38400`, `115200`), visible damage on the controller (cap bulging, blackening at AC input, cracked solder, burnt-component odor), or two or more KS1/KS2 in the same shipment exhibit identical never-completes-boot behavior. Book at https://d-central.tech/services/asic-repair/ - Western English-language IceRiver authority, Canada / US / international welcome.

What D-Central does at the bench for KS1/KS2 first-boot failures. Diagnostics against a known-good KS1 / KS2 reference unit, controller PSU regulator inspection (documented `0.45 V` ASIC rail from `uP9512`, `1.8 V` from `Gs9238`, `0.8 V` from `SGM2036`, plus the `5 V` rail derived from `12 V` input - any of these out-of-tolerance produces wedged-boot behavior), controller-board recovery flash with verified-clean firmware images, RJ-45 magnetics replacement if the network port is dead, and 24-hour hashrate burn-in (KS1 ~ `1 TH/s`, KS2 ~ `2 TH/s`). Verify-flag: confirm exact per-unit nameplate vs IceRiver's currently-published spec before quoting customer ROI.

Ship the miner safely. Pack in original foam if you have it, or double-box with at least 5 cm of foam on every side. KS1/KS2 are heavier than they look - sturdy outer box, reinforced corners, arrows pointing up. Include a printed note with: model (KS1 or KS2), serial number from the chassis sticker, observed symptoms (`Detect IP` empty / web UI unreachable / boot wedged / fans full-tilt no hashrate / firmware-update failure mid-flash), firmware version if known, LAN environment (consumer router / managed switch / VLAN config), and AC environment (`120 V` vs `240 V`). Notes save 30-60 minutes of bench diagnostic time, which directly saves you repair dollars.