### System details

GMKtec NucBox K8 Plus; AMD Ryzen 7 8845HS with Radeon 780M; BIOS 1.02 (2025-08-22); Dell WD19TB Thunderbolt 3 dock; Omarchy 4.0.2-1; kernel 7.1.9-arch1-2

### What's wrong?

## Summary

On an encrypted Omarchy installation, the keyboard and mouse connected through a Thunderbolt dock work in the firmware and Limine, but stop working when Linux starts. The external monitors connected through the same dock remain visible throughout boot.

The dock input devices return immediately after the root filesystem is unlocked and `boltd` authorizes the enrolled dock.

The boot log appears to show why: firmware initially provides the dock's PCIe xHCI USB controller, but Omarchy's early `thunderbolt` module removes it about 10 ms after it is registered. Because the dock cannot be authorized until `boltd` becomes available from the encrypted root, its USB controller is absent during the Plymouth/LUKS prompt.

This may affect other encrypted installations where a dock's USB ports are implemented through a Thunderbolt PCIe xHCI controller and the host firmware has no BootACL.

## Expected behavior

A keyboard connected through a dock and working in the firmware/bootloader should remain usable at the LUKS prompt, or Omarchy should document when its early Thunderbolt initialization cannot support this securely.

## Actual behavior

- Dock monitors work in the firmware, Limine, at the Plymouth/LUKS prompt, and in the desktop.
- Dock keyboard and mouse work in the firmware and Limine.
- Dock input disappears when the Linux Thunderbolt driver starts.
- A directly connected USB keyboard is required to enter the LUKS passphrase.
- After unlock, `boltd` automatically authorizes the stored dock and all dock USB devices appear normally.

This is the LUKS/Plymouth prompt, not Hyprlock or a graphical login screen.

## System details

- Computer: GMKtec NucBox K8 Plus
- CPU/GPU: AMD Ryzen 7 8845HS with Radeon 780M
- BIOS: NucBox K8 Plus 1.02, dated 2025-08-22
- Dock: Dell WD19TB, Thunderbolt 3 (Intel JHL7440/Titan Ridge)
- Omarchy: 4.0.2-1
- `omarchy-settings`: 4.0.2-1
- Kernel: 7.1.9-arch1-2
- `mkinitcpio`: 41.1-1
- `bolt`: 0.9.11-3
- Limine: 12.6.0-1
- `limine-mkinitcpio-hook`: 1.37.1-1
- Encrypted Btrfs root using the stock Plymouth/`encrypt` initramfs flow

The stock configuration includes:

```bash
# /etc/mkinitcpio.conf.d/thunderbolt_module.conf
MODULES+=(thunderbolt)
```

and:

```bash
HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs)
```

## Thunderbolt state

Both USB4 domains report:

```text
security: user
iommu: no
bootacl: 0/0
```

The WD19TB is stored by `boltd` with:

```text
status: authorized
policy: auto
key: no
40 Gb/s link
```

The device UUID has been omitted because the exact value is not needed to reproduce the issue.

## Reproduction steps

1. Use an encrypted Omarchy installation with the stock early `thunderbolt` module configuration.
2. Connect a Thunderbolt dock whose USB hub is behind a PCIe xHCI controller.
3. Connect the keyboard and mouse to the dock.
4. Enroll the dock using `boltctl enroll`; verify that it is stored with `policy: auto`.
5. Reboot with the dock connected.
6. Observe that dock input works in Aptio/UEFI and Limine.
7. Observe that the external dock displays continue showing Plymouth, but dock input no longer works at the LUKS prompt.
8. Unlock using a keyboard connected directly to the computer.
9. Observe that `boltd` authorizes the dock and its USB controller/input devices return.

## Relevant boot timeline

The PCI address is the WD19TB's Intel JHL7440 xHCI controller:

```text
[166.611356] pci 0000:68:00.0: [8086:15f0] class 0x0c0330 PCIe endpoint
[166.636394] xhci_hcd 0000:68:00.0: xHCI Host Controller
[166.636430] xhci_hcd 0000:68:00.0: new USB bus registered
[166.646056] ACPI: bus type thunderbolt registered
[166.646291] xhci_hcd 0000:68:00.0: remove, state 1
[166.646346] xhci_hcd 0000:68:00.0: USB bus deregistered
[166.648688] thunderbolt 1-2: new device found, vendor=0xd4 device=0xb070
[166.648798] thunderbolt 1-2: Dell WD19TB Thunderbolt Dock
[167.672470] Starting Show Plymouth Boot Screen...
[167.711526] Started Show Plymouth Boot Screen.
[168.852196] Starting Thunderbolt system service...
[168.925209] boltd: auto-auth: policy: auto, iommu: no -> ok
[168.925213] boltd: auto-auth: security: user mode, key: no -> ok
[168.931511] boltd: authorize: finished: ok
[169.077892] pci 0000:68:00.0: [8086:15f0] class 0x0c0330 PCIe endpoint
[169.083677] xhci_hcd 0000:68:00.0: xHCI Host Controller
[169.083804] xhci_hcd 0000:68:00.0: new USB bus registered
[170.714008] input: Logitech Gaming Mouse G502 .../0000:68:00.0/usb1/...
```

This shows the firmware-provided xHCI controller being removed when the early Thunderbolt driver takes control, before Plymouth can receive input. It returns only after userspace `boltd` authorizes the dock.

## Troubleshooting already performed

- `boltctl enroll` immediately restored dock USB during the original session.
- Enrollment persists and automatic authorization succeeds after every unlock.
- `bolt.service` is correctly `static` and is started automatically; it is not a service-enable problem.
- Re-enrolling the dock is unnecessary and does not address pre-LUKS operation.
- The monitors remain active, demonstrating that DisplayPort tunnelling is separate from the missing PCIe xHCI tunnel.
- BIOS was tested both with USB4 settings on `Auto` and with `USB4 pre-CM`, both routers, and both PCIe tunnels explicitly `Enabled`.
- With the explicit BIOS settings, firmware still presents the xHCI controller initially, but Linux reports the dock as `boot=0`; the early driver removes it in the same way.
- The firmware exposes no Thunderbolt BootACL (`0/0`) and no USB-only security mode.
- AMD-Vi/IOMMU is active generally, but the Thunderbolt domains report `iommu_dma_protection=0`.

## Why this may be an Omarchy-wide configuration issue

The current unconditional early module loading has conflicting effects depending on the hardware:

- #1893 needed early Thunderbolt loading so Plymouth appeared on a Dell WD22TB4 display.
- PR #1894 introduced the early module configuration.
- #3906 reported that the same early loading destroyed a working DisplayPort tunnel on a CalDigit TS4 system.
- On this machine, early loading preserves the display but destroys the firmware-provided dock USB controller until after LUKS.

Related:

- https://github.com/omacom/omarchy/issues/1893
- https://github.com/omacom/omarchy/pull/1894
- https://github.com/omacom/omarchy/issues/3906

This suggests that always loading `thunderbolt` in the initramfs cannot produce the desired result on every firmware/dock combination.

## Possible solution directions

I do not think Omarchy should automatically authorize every Thunderbolt device in the initramfs, because that would bypass the `user` security policy and expose users to pre-unlock DMA devices.

Safer possibilities might include:

1. Make early `thunderbolt` loading optional or hardware-dependent instead of unconditional.
2. Provide and document a supported way to opt out when firmware already supplies the required preboot display and input paths.
3. Document this failure mode for encrypted systems with `bootacl: 0/0`.
4. Optionally provide an explicit setup flow for authorizing one selected dock in the initramfs, clearly explaining that UUID/vendor/device metadata is identification rather than cryptographic authentication and that early PCIe authorization has a DMA-security tradeoff.
5. Add a diagnostic command that identifies when a firmware-provided dock xHCI controller is removed before the LUKS prompt and restored by `boltd` afterward.

I am happy to test a supported opt-out or another proposed solution on this hardware. I can also test whether omitting the early `thunderbolt` module preserves the firmware-provided USB controller, provided there is a safe recovery path if the external Plymouth display disappears.