Installing Debian 13 Alongside Omarchy Without a USB: An Overnight Linux Recovery Expedition

What began as a fairly simple experiment turned into one of the most useful Linux troubleshooting exercises I’ve done.

The goal sounded straightforward: I already had Omarchy installed on a laptop, and I wanted to install Debian 13 alongside it without using another USB flash drive or CD.

By the end of the night, I had worked through encrypted storage, Btrfs subvolumes, the Limine bootloader, Debian’s initramfs, chroot recovery, Linux user administration, a missing graphical desktop, a missing display manager, and missing Intel Wi-Fi firmware.

The result was worth it.

Debian 13 now boots successfully into Cinnamon, recognizes the laptop’s Intel wireless adapter, connects to Wi-Fi, and boots remarkably fast.

I am also keeping Omarchy installed for now. After everything that happened, it has proven itself to be an excellent rescue environment.

The Starting Point

The laptop originally contained Omarchy.

Rather than immediately wiping the existing installation, Debian 13 was installed into the existing encrypted Btrfs environment.

The physical disk eventually looked conceptually like this:

sda
├── sda1        EFI/boot
└── sda2        LUKS encrypted partition
    └── root    Btrfs filesystem

Inside that Btrfs filesystem were several subvolumes.

Running:

sudo btrfs subvolume list /

revealed:

@
@home
@log
@pkg
@factory
@debian

The important discovery was:

@debian

That proved the Debian installation had not disappeared or been destroyed. Debian was sitting inside its own Btrfs subvolume while Omarchy continued to use the original root subvolume.

This became the foundation of the entire recovery.

Debian Was There — It Just Wouldn’t Boot Properly

The Limine bootloader had a Debian 13 entry pointing at the Debian kernel and initramfs.

The boot configuration used the encrypted mapper device as the root filesystem and selected the Debian Btrfs subvolume:

root=/dev/mapper/root rootflags=subvol=@debian rw

That was exactly what we wanted.

The Debian initramfs was also inspected to make sure encryption support was present. It contained components such as:

cryptroot
cryptroot/crypttab
scripts/local-block/cryptroot
scripts/local-top/cryptroot

So Debian had the machinery required to access the encrypted root filesystem.

Yet every boot attempt appeared to stall.

The laptop would eventually reach something resembling:

Debian GNU/Linux 13
tty2

For quite a while, this looked like a boot failure.

It wasn’t.

That realization became one of the most important lessons of the entire exercise.

Using Omarchy as the Rescue System

Instead of repeatedly trying the same Debian boot, I returned to Omarchy.

Because Omarchy could already unlock and mount the encrypted Btrfs filesystem, it became the recovery environment for Debian.

The Debian subvolume could be mounted directly:

sudo mkdir -p /mnt/debian
sudo mount -o subvol=@debian /dev/mapper/root /mnt/debian

Checking:

ls /mnt/debian/home

showed:

ny2honolulu

Debian was intact.

From there, I could enter the Debian installation with chroot and repair it while Omarchy remained the operating system actually running the laptop.

Repairing the Debian User Account

One uncertainty was the Debian login account.

Inside the Debian chroot, I explicitly reset the password:

passwd ny2honolulu

Debian responded:

passwd: password updated successfully

I also verified the account:

id ny2honolulu

which returned:

uid=1000(ny2honolulu)
gid=1000(ny2honolulu)
groups=1000(ny2honolulu),27(sudo),100(users)

That established three things:

• the user existed;
• the password was known;
• the account had sudo privileges.

The repeated boot problem therefore wasn’t simply a broken user account.

The Breakthrough: Debian Wasn’t Actually Frozen

The next clue came from checking for a display manager.

From Omarchy, I examined:

/mnt/debian/etc/systemd/system/display-manager.service

It didn’t exist.

I then searched the Debian installation for common graphical login managers and desktop environments, including:

gdm3
lightdm
sddm
GNOME
Cinnamon
XFCE
Plasma

Nothing relevant appeared.

Then I checked Debian’s default systemd target:

systemctl get-default

It reported:

graphical.target

That exposed the contradiction.

Debian had been instructed to boot into graphical mode, but there was no graphical desktop/display manager available to start.

The mysterious tty2 screen wasn’t necessarily Debian freezing.

Debian had probably finished booting.

There simply wasn’t a graphical login screen waiting on the other side.

That changed the entire diagnosis.

Preparing a Proper Debian Chroot

Before installing the missing desktop, several virtual filesystems were mounted into Debian:

sudo mount --bind /dev /mnt/debian/dev
sudo mount -t proc /proc /mnt/debian/proc
sudo mount -t sysfs /sys /mnt/debian/sys

Then I entered Debian:

sudo chroot /mnt/debian /bin/bash

From there, Debian’s package manager worked normally.

A quick:

apt update

successfully reached:

https://deb.debian.org/debian trixie

That meant Debian could use Omarchy’s working network connection from inside the chroot.

Installing Cinnamon

I decided to use Cinnamon because I already know and like it on Debian.

Inside the Debian chroot:

apt install task-cinnamon-desktop

This was a substantial installation.

It pulled in the desktop environment and graphical infrastructure Debian had been missing.

Near the end, Debian regenerated its initramfs:

update-initramfs: Generating /boot/initrd.img-6.12.94+deb13-amd64

Then I checked the display manager:

ls -l /etc/systemd/system/display-manager.service

It now pointed to:

/lib/systemd/system/lightdm.service

Finally:

systemctl is-enabled lightdm

returned:

enabled

This was the point where the original “boot failure” had essentially been solved.

Debian now had something to launch when it reached graphical.target.

The First Successful Debian Desktop

After cleanly leaving the chroot, unmounting the Debian filesystem, and rebooting, Debian finally reached a graphical Cinnamon desktop.

That was a major milestone.

But there was another problem.

No Internet.

The Missing Intel Wi-Fi Adapter

Running:

ip link

showed only:

lo

There was no wireless interface such as wlan0 or wlp....

Hardware inspection identified the laptop’s wireless adapter as:

Intel Corporation Wireless 7265

The Intel 7265 is supported by Linux through the iwlwifi driver.

But checking Debian’s firmware directory revealed no corresponding Intel wireless firmware files.

This explained why Debian knew about the hardware at the PCI level but couldn’t create a usable wireless network interface.

Once again, Omarchy became the rescue system.

Installing Intel Wi-Fi Firmware From Omarchy

I booted back into Omarchy, mounted the Debian subvolume again, mounted /dev, /proc, and /sys, and entered the Debian installation with chroot.

Then:

apt install firmware-iwlwifi

Debian downloaded approximately 16.7 MB and installed:

firmware-iwlwifi 20250410-2

There were some locale warnings because the recovery chroot wasn’t a completely normal running Debian environment. There was also a /dev/pts logging warning.

Neither prevented the package from installing.

The important line was:

Setting up firmware-iwlwifi (20250410-2) ...

One More Initramfs Problem

I wanted to rebuild Debian’s initramfs after installing the wireless firmware.

Running:

update-initramfs -u

initially failed because the command wasn’t in the chroot’s current PATH.

Calling it explicitly:

/usr/sbin/update-initramfs -u

got further but produced:

mkinitramfs: not found

Again, the problem was the restricted PATH inside the chroot rather than necessarily a missing program.

The solution was to explicitly supply the standard administrative paths:

PATH=/usr/sbin:/usr/bin:/sbin:/bin /usr/sbin/update-initramfs -u

This time Debian successfully generated:

/boot/initrd.img-6.12.94+deb13-amd64

That was the final major repair.

Debian Boots — and Wi-Fi Works

After another clean unmount and reboot, I selected Debian 13 from Limine.

Cinnamon appeared.

This time, Wi-Fi networks appeared too.

I connected to the network and was online.

From the Debian terminal:

cat /etc/os-release | head -3

returned:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"

And:

uname -r

returned:

6.12.94+deb13-amd64

There was no longer any ambiguity.

The laptop was running Debian 13 on a genuine Debian kernel, with Cinnamon and working Intel Wi-Fi.

Why Does the Prompt Still Say “ommarchy”?

One amusing leftover remains.

The terminal prompt currently looks like:

ny2honolulu@ommarchy:~$

That does not mean Omarchy is running.

ommarchy is simply the machine’s hostname left over from the original installation.

The operating system itself confirms that it is Debian 13.

I can rename the hostname later, but for now I’m deliberately leaving the working configuration alone.

What Actually Went Wrong?

There wasn’t one single catastrophic failure.

There were several smaller problems stacked on top of each other.

The Debian Btrfs installation itself existed.

The bootloader could find Debian.

The encrypted filesystem could be unlocked.

The Debian kernel could boot.

But Debian lacked a graphical desktop/display manager, making a successful console boot look like a frozen graphical boot.

Once Cinnamon and LightDM were installed, Debian reached the desktop.

Then another independent problem appeared: the Intel Wireless 7265 required firmware that wasn’t installed.

Installing firmware-iwlwifi and rebuilding the initramfs solved that problem.

The final working chain became:

Limine
   ↓
LUKS
   ↓
Btrfs
   ↓
@debian
   ↓
Debian kernel
   ↓
systemd
   ↓
graphical.target
   ↓
LightDM
   ↓
Cinnamon
   ↓
ny2honolulu
   ↓
iwlwifi + Intel firmware
   ↓
Wi-Fi
   ↓
Internet

Lessons Learned

The biggest lesson from this overnight expedition is that a Linux machine apparently “hanging” during boot does not necessarily mean the kernel has crashed.

A TTY can actually be evidence of success.

The system may have booted perfectly well into a state that simply isn’t the state I expected.

Another major lesson was the value of Btrfs subvolumes.

Having Debian isolated in @debian meant I could access and repair an entire second Linux installation without destroying the working Omarchy system.

chroot was equally important.

Instead of treating Debian as an inaccessible operating system that had to boot before I could repair it, I could mount it and temporarily treat its filesystem as the root environment:

Omarchy
   │
   └── /mnt/debian
           │
           └── chroot
                  │
                  └── Debian

That allowed Debian’s own apt, passwd, dpkg, systemctl, and initramfs tools to repair Debian while Omarchy supplied the functioning kernel, network connection, and hardware environment.

There was also an important troubleshooting lesson in separating symptoms.

The graphical boot problem and Wi-Fi problem were unrelated.

Fixing Cinnamon didn’t magically fix Wi-Fi.

Fixing the Wi-Fi firmware wasn’t necessary to make Cinnamon work.

Treating each failure as a separate layer made the problem manageable.

Why I’m Keeping Omarchy

Originally, I thought Debian might simply replace Omarchy.

I’m not doing that yet.

Omarchy became the rescue environment that allowed me to repair Debian.

It could unlock the encrypted disk, mount the Btrfs filesystem, access the Debian subvolume, provide Internet connectivity, and host the Debian chroot.

That’s useful enough that I’m leaving both systems intact for now.

There is also something satisfying about the final arrangement.

One physical laptop now contains two very different Linux environments sharing an encrypted Btrfs foundation, with Limine providing access to both.

And after all that troubleshooting, Debian’s reboot is lightning fast.

Final State

The laptop now has:

Operating system: Debian GNU/Linux 13 (trixie)
Kernel:           6.12.94+deb13-amd64
Desktop:          Cinnamon
Display manager:  LightDM
User:             ny2honolulu
Privilege:        sudo
Wireless:         Intel Wireless 7265
Driver:           iwlwifi
Firmware:         firmware-iwlwifi
Filesystem:       Btrfs
Debian subvolume: @debian
Encryption:       LUKS
Bootloader:       Limine
Network:          Working
Internet:         Working

Omarchy remains available as the alternate boot environment.

What started as an experiment in installing Debian without reaching for another USB drive became something much more useful: a practical lesson in how modern Linux actually boots, how encrypted Btrfs systems can be repaired, and how one Linux installation can rescue another.

There were several moments during the night when starting over would have been easier.

I’m glad I didn’t.

The machine works — and now I understand considerably more about why it works.