# `initramfs_async=0` correlates with ~76-second kernel phase on Linux 7.1

## Summary

After updating to Omarchy 4.0.0-1 / Linux 7.1.8, cold boots consistently spend approximately 76 seconds in the kernel phase before normal userspace starts. SDDM and the desktop start promptly afterward.

The installed Omarchy defaults deliberately add `initramfs_async=0` as a workaround for a Linux 7.1 asynchronous-initramfs/Plymouth race on encrypted systems. On this mixed AMD/NVIDIA machine, the synchronous path appears to impose a severe boot-time regression while unpacking an approximately 266 MiB initramfs. This report asks whether the workaround should be narrowed, revised, or removed once the upstream race is fixed.

The delay was first noticed after testing sleep/hibernate, but a subsequent ordinary cold reboot reproduced it. The journal shows that the attempted sleep operation was S3 suspend rather than hibernation, so the boot delay does not appear to depend on a saved hibernation image.

## Expected behavior

The encrypted system should retain a working Plymouth/LUKS prompt without adding roughly 76 seconds to every boot.

## Actual behavior

`systemd-analyze time` reports:

```text
Startup finished in 30.189s (firmware) + 4.345s (loader) +
1min 15.918s (kernel) + 4.601s (userspace) = 1min 55.056s
graphical.target reached after 4.345s in userspace.
```

The first kernel journal entry occurs at essentially the end of that delay on two consecutive boots:

```text
[   76.780692] Linux version 7.1.8-arch1-3 ...
[   76.648164] Linux version 7.1.8-arch1-3 ...
```

SDDM starts shortly afterward:

```text
[   80.260756] sddm: Starting...
```

This makes SDDM/userspace unlikely to be the source of the delay.

## Relevant Omarchy configuration

`/etc/limine-entry-tool.d/omarchy-defaults.conf` contains:

```bash
# Kernel 7.1 unpacks the initramfs asynchronously, which races /init: the
# early /proc, /sys, /dev, and /run mounts fail while unpacking settles, so
# plymouthd exits when it can't read /proc/cmdline and encrypted boots fall
# back to an unthemed text LUKS prompt. Unpack synchronously until the race
# is fixed upstream.
KERNEL_CMDLINE[default]+=" initramfs_async=0"
```

The loaded initramfs is reported as approximately 266 MiB uncompressed:

```text
Freeing initrd memory: 265956K
```

The NVIDIA open driver is included for early KMS. It loads successfully and no NVIDIA timeout/error occurs around the delay:

```text
NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64 610.57.04
```

This system has both an NVIDIA discrete GPU and an AMD integrated GPU. Omarchy's current `omarchy_hooks.conf` therefore retains the generic `kms` hook rather than taking the NVIDIA-only path that removes it. This may retain the large nouveau/GSP firmware payload described in #6790 and amplify the cost of synchronous unpacking. The symptoms here remain distinct from #6790: the observed regression is a repeatable 75.9-second kernel phase after `initramfs_async=0` was introduced.

## Steps to reproduce

1. Boot an encrypted Omarchy installation using Linux 7.1 with the packaged `initramfs_async=0` default.
2. After login, run `systemd-analyze time`.
3. Run `journalctl -b -k -o short-monotonic | head -1`.
4. Observe an approximately 76-second kernel phase and first kernel log timestamp on this system.
5. Reboot normally and repeat; the delay reproduces.

An A/B boot without `initramfs_async=0` has intentionally not yet been performed because removing it may regress the encrypted-volume prompt. Guidance for a safe test would be welcome.

## System details

- Omarchy: 4.0.0-1
- Kernel: 7.1.8-arch1-3
- CPU: AMD Ryzen 7 9800X3D
- Discrete GPU: NVIDIA GeForce RTX 5080 (GB203)
- Integrated GPU: AMD Granite Ridge Radeon Graphics
- NVIDIA driver: `nvidia-open-dkms` / `nvidia-utils` 610.57.04
- Bootloader: Limine 12.5.2, UKI via systemd-stub
- Root: LUKS-encrypted Btrfs
- Resume target: Btrfs swapfile via `resume=/dev/mapper/root resume_offset=1876530`
- Motherboard: ASUS ROG STRIX X870E-E GAMING WIFI, BIOS 2306

## Questions for maintainers

1. Is this boot-time regression known for the Linux 7.1 `initramfs_async=0` workaround?
2. Can the workaround be limited to affected initramfs/Plymouth configurations or replaced with ordering/readiness logic?
3. What is the preferred safe A/B procedure for encrypted systems so the LUKS prompt remains recoverable?
4. Should the workaround be version-gated and removed automatically once the upstream kernel race is fixed?
5. Does the mixed-GPU case need separate initramfs pruning so required AMD KMS support is retained without bundling unused nouveau firmware?

## Additional note

The installed `omarchy debug --no-sudo --print` command referenced by existing reporting guidance is not available in Omarchy 4.0.0-1 (`Unknown Omarchy command`). No diagnostic-upload URL is therefore included.

Related: #6790 (`kms` hook bundles unused nouveau GSP firmware on NVIDIA installs).