DEV Community: Siddharth Magesh

Fixing Extremely Slow Debian Boot on a Windows Dual-Boot System

Siddharth Magesh — Fri, 06 Feb 2026 05:12:57 +0000

I dual-booted my laptop with Windows and Debian, and while Windows booted normally, Debian consistently took 2–3 minutes to reach the desktop. The boot process showed multiple “checking” messages and long pauses.

This post documents the exact debugging steps I followed and the single configuration change that fixed the issue permanently.

Problem Overview

Debian boot time was abnormally long:

Startup finished in 7s (firmware)
+ 5s (loader)
+ 4s (kernel)
+ 2min 41s (userspace)

The kernel loaded quickly. The delay was entirely in userspace, meaning system services were blocked waiting for something.

Step 1: Measure the boot process

The first step was to identify where the time was being spent:

systemd-analyze

This confirmed that userspace was responsible for the delay.

Next, I inspected which services were slow:

systemd-analyze blame

Several services appeared to take ~30 seconds, but this output is misleading because many services start in parallel.

To identify the real blocker, I used:

systemd-analyze critical-chain

Step 2: Identify the blocking dependency

The critical chain showed this:

dev-disk-by-uuid-1CEE-9C07.device @ 1min+
└─ systemd-fsck@...
└─ boot-efi.mount

This revealed that everything was waiting on a disk device, specifically the one used for /boot/efi.

Step 3: Identify the device

To find out what this UUID belonged to:

lsblk -f

Relevant output:

nvme0n1p7  vfat  UUID=1CEE-9C07  /boot/efi

The blocking device was the EFI system partition, formatted as VFAT and shared with Windows.

Root Cause

On dual-boot systems:

Windows frequently modifies the EFI partition
VFAT devices may take time to settle after firmware handoff
systemd treats /boot/efi as a critical mount
The default timeout is ~90 seconds

Because /boot/efi mounts very early, all other services were blocked until it became available.

This is not a Debian bug. It is a common dual-boot edge case.

Step 4: Apply the fix safely

The goal is not to remove /boot/efi, but to prevent it from blocking the entire boot process.

Edit /etc/fstab:

sudo nano /etc/fstab

Original entry:

UUID=1CEE-9C07  /boot/efi  vfat  umask=0077  0  1

Updated entry:

UUID=1CEE-9C07  /boot/efi  vfat  umask=0077,nofail,x-systemd.device-timeout=5s  0  1

What this change does

nofail Allows the system to continue booting even if EFI is slow
x-systemd.device-timeout=5s Limits how long systemd waits for the EFI device

The EFI partition still mounts normally, but it no longer blocks the boot.

Result

After rebooting directly into Debian:

Startup finished in 7.0s (firmware)
+ 4.7s (loader)
+ 4.2s (kernel)
+ 8.8s (userspace)
= ~25 seconds total

The issue was completely resolved.

Key Takeaways

Always start with systemd-analyze
Use critical-chain to find the real blocker
Dual-boot EFI partitions are a common source of boot delays
One targeted fstab change can fix multi-minute boot times
Avoid disabling fsck or core services blindly

Conclusion

This was not a performance issue, a kernel issue, or a broken install.
It was systemd correctly waiting for a shared EFI partition for too long.

Understanding what the system is waiting for is more effective than disabling random services.

If you are dual-booting Linux and Windows and experiencing long boot times, inspect /boot/efi first.

Secure Remote Access to a Windows Machine from Debian Using SSH and Tailscale

Siddharth Magesh — Tue, 13 Jan 2026 09:48:49 +0000

Introduction (Motive)

I wanted a reliable way to remotely access my Windows machine (with a dedicated GPU) from a Debian laptop, from anywhere in the world, without exposing ports, dealing with dynamic IPs, or relying on fragile tunneling tools.

The goal was:

Secure remote terminal access
Works across different networks
No router port forwarding
Stable and production-grade
Compatible with VS Code Remote development

This post documents the exact steps, pitfalls, and final configuration that worked.

System Setup

Remote machine: Windows 11 (Home/Pro), GPU-enabled
Client machine: Debian Linux
Remote access: OpenSSH
Networking: Tailscale (WireGuard-based mesh VPN)
Editor: VS Code with Remote SSH extension

High-Level Architecture

Debian Laptop
   |
   |  (Encrypted Tailscale tunnel)
   |
Windows PC (sshd running)

Tailscale provides a private network (100.x.x.x) between devices. SSH runs inside this network, so nothing is exposed to the public internet.

Step 1: Enable OpenSSH Server on Windows

1.1 Install OpenSSH Server (manual MSI method)

On recent Windows builds, the optional feature install may hang. The reliable approach is to install OpenSSH manually.

Download the Win64 OpenSSH MSI from:

https://github.com/PowerShell/Win32-OpenSSH/releases

Install it, then verify binaries exist at:

C:\Program Files\OpenSSH\

1.2 Create and start the sshd service

Open PowerShell as Administrator:

sc.exe create sshd binPath= "C:\Program Files\OpenSSH\sshd.exe" start= auto
sc.exe description sshd "OpenSSH SSH Server"
Start-Service sshd

Verify:

Get-Service sshd

Expected:

Status : Running
StartType : Automatic

1.3 Allow SSH through Windows Firewall

New-NetFirewallRule `
  -Name sshd `
  -DisplayName "OpenSSH Server" `
  -Enabled True `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 22 `
  -Action Allow

Step 2: Configure SSH Authentication

2.1 Generate SSH key on Debian

On Debian:

ssh-keygen -t ed25519

Public key location:

~/.ssh/id_ed25519.pub

2.2 Add public key to Windows

On Windows, create:

C:\Users\JohnDoe\.ssh\authorized_keys

Paste the entire public key line into this file.

2.3 Fix permissions (important)

Run in PowerShell (Admin):

cmd /c 'icacls "C:\Users\JohnDoe\.ssh" /inheritance:r'
cmd /c 'icacls "C:\Users\JohnDoe\.ssh" /grant JohnDoe:(F)'
cmd /c 'icacls "C:\Users\JohnDoe\.ssh\authorized_keys" /inheritance:r'
cmd /c 'icacls "C:\Users\JohnDoe\.ssh\authorized_keys" /grant JohnDoe:(R)'

Incorrect permissions will cause SSH login failures.

2.4 If you don’t have a Windows password

SSH requires a Windows account password.

Set one:

net user JohnDoe *

Step 3: Install Tailscale on Windows

3.1 Install via MSI (recommended)

Download:

https://pkgs.tailscale.com/stable/tailscale-setup-<version>-amd64.msi

Install normally.

Verify service:

Get-Service Tailscale

3.2 Login to Tailscale

Use the system tray icon to log in.

Check status:

& "C:\Program Files\Tailscale\tailscale.exe" status

You should see:

100.xxx.xxx.xxx  windows-machine-name  windows

Step 4: Install Tailscale on Debian

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Authenticate using the same account.

Verify:

tailscale status

Both machines should appear.

Step 5: SSH Over Tailscale (Global Access)

From Debian:

ssh JohnDoe@100.xxx.xxx.xxx

or using hostname:

ssh JohnDoe@windows-machine-name

This works from:

Different Wi-Fi
Mobile hotspot
University or office networks
Anywhere in the world

No port forwarding required.

Step 6: VS Code Remote SSH (Optional but Recommended)

6.1 Install extension on Debian

Remote - SSH (ms-vscode-remote.remote-ssh)

6.2 Add SSH host

Command Palette:

Remote-SSH: Add New SSH Host

ssh JohnDoe@100.xxx.xxx.xxx

Config file:

~/.ssh/config

Example entry:

Host windows
    HostName 100.xxx.xxx.xxx
    User JohnDoe
    IdentityFile ~/.ssh/id_ed25519

6.3 Connect and open a specific folder

Command Palette:

Remote-SSH: Connect to Host
Remote-SSH: Open Folder

Example Windows path:

D:\projects\my_project

VS Code now runs fully remote on Windows.

Common Pitfalls and Fixes

SSH asks for password repeatedly

Check authorized_keys permissions
Ensure key is one single line
Verify correct Windows username

VS Code `code .` doesn’t open over SSH

SSH sessions are headless
Use VS Code Remote SSH, not GUI commands

SSH doesn’t work after reboot

You must log in once after boot
Sleep/hibernate disables networking

Power and Boot Behavior (Important)

This setup works if:

Windows is powered on
You have logged in after boot
Tailscale and sshd services are running

It does not work if the system is:

Shut down
Sleeping
Stuck at login screen

Auto-login and Wake-on-LAN can be added later if needed.

Conclusion

With OpenSSH and Tailscale, it’s possible to build a secure, production-grade remote access setup without exposing ports or relying on third-party tunneling services.

This approach is stable, scalable, and ideal for:

Remote development
GPU workloads
Cross-platform workflows

I plan to extend this setup further with stricter SSH policies and automated boot-time connectivity.

Remote SSH Access to Windows from Debian: Complete Setup and Fixes

Siddharth Magesh — Fri, 12 Dec 2025 06:18:36 +0000

Remote SSH Access to a Windows Machine from Debian: Full Setup, Fixes, and Lessons Learned

I wanted to remotely access my Windows laptop (with GPU) from my Debian machine using SSH. However, Windows 11 (especially Insider/Canary builds) often breaks or removes the built-in OpenSSH Server capability. This article documents every step needed to get SSH working correctly: installation, service creation, firewall rules, password setup, configuration fixes, and overcoming common errors.

This guide uses JohnDoe as the Windows username. Replace it with your own.

System Setup

Client machine: Debian Linux
Remote machine: Windows 11 (Canary build)
Goal: SSH from Debian into Windows using password authentication

1. Problem: OpenSSH Server Optional Feature Fails to Install

On Windows Canary builds, installing OpenSSH Server via:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

often hangs indefinitely.
To avoid this issue, install OpenSSH manually.

2. Manual Installation of OpenSSH (MSI Method)

Download the official MSI:

OpenSSH-Win64-v10.0.0.0.msi

Source: https://github.com/PowerShell/Win32-OpenSSH/releases/latest

Install it normally. After installation, binaries are located in:

C:\Program Files\OpenSSH\

3. Create the SSH Service Manually

On some Windows builds, the MSI installs binaries but does not register the sshd service.
Create it using sc.exe.

Open PowerShell as Administrator:

sc.exe create sshd binPath= "C:\Program Files\OpenSSH\sshd.exe" start= auto
sc.exe description sshd "OpenSSH SSH Server"
Start-Service sshd

Verify service state:

Get-Service sshd

Verify startup:

Get-CimInstance -ClassName Win32_Service -Filter "Name='sshd'" | Select-Object Name, StartMode, State

Expected:

Name   StartMode  State
sshd   Auto       Running

4. Allow SSH Through Windows Firewall

New-NetFirewallRule -Name sshd -DisplayName "OpenSSH Server" -Enabled True -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow

5. Determine Windows Local IP Address

ipconfig

Look for the IPv4 address of the active adapter, for example:

IPv4 Address: 192.168.68.103

Use this IP when connecting from Debian.

6. Set a Password for the Windows User (Required for SSH)

If your account only uses PIN/face/fingerprint, SSH cannot authenticate.
A real password must be set.

net user JohnDoe *

Enter a password when prompted.
This is the password that SSH will use.

7. SSH Configuration Fixes (Optional but Recommended)

Open:

notepad "C:\Program Files\OpenSSH\sshd_config"

Ensure the following lines exist and are not commented:

PasswordAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

If this block exists, comment it out to avoid override issues:

#Match Group administrators
#    AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Restart the service:

Restart-Service sshd

8. (Optional) Add SSH Key Authentication

On Debian:

ssh-keygen -t ed25519 -C "debian-client"
cat ~/.ssh/id_ed25519.pub

On Windows:

mkdir $env:USERPROFILE\.ssh -Force
notepad $env:USERPROFILE\.ssh\authorized_keys

Paste the key and save.

Set valid ACL permissions:

cmd /c 'icacls "C:\Users\JohnDoe\.ssh" /inheritance:r'
cmd /c 'icacls "C:\Users\JohnDoe\.ssh" /grant JohnDoe:(F)'
cmd /c 'icacls "C:\Users\JohnDoe\.ssh\authorized_keys" /inheritance:r'
cmd /c 'icacls "C:\Users\JohnDoe\.ssh\authorized_keys" /grant JohnDoe:(R)'

9. SSH From Debian (Same Local Network Only)

ssh JohnDoe@192.168.68.103

When prompted for host authenticity, enter:

yes

Then provide the password created via net user.

10. Notes and Hurdles Encountered

OpenSSH capability installation hanging

The built-in feature installer may freeze on Canary builds.
The MSI avoids this entirely.

Service missing after reboot

If the service shows “marked for deletion”, reboot and recreate using sc.exe.

Important Limitation: Same-Network Requirement

The SSH setup described in this article works only when both the Debian and Windows machines are connected to the same local network.

This is because the connection uses a private IPv4 address (for example 192.168.x.x), which is not routable over the public internet. When the machines are on different networks, the SSH client will not be able to reach the Windows host due to NAT and firewall isolation.

To enable remote access across different networks, additional networking solutions such as VPNs, tunneling tools, or overlay networks would be required. These approaches are outside the scope of this article.

Authentication failures

If SSH keeps asking for a password, ensure:

The Windows user has a real password
PasswordAuthentication yes is set
sshd is restarted

Public key not accepted

Verify:

The file is named authorized_keys (no extension)
ACL permissions are correct
AuthorizedKeysFile path matches

Also, All my accounts on the browser were logged out.

Conclusion

SSH access from Linux to Windows is entirely possible, even on unstable Windows builds, but may require manual installation steps and fixes. Following the process above provides a stable, repeatable configuration with accurate commands and known troubleshooting solutions.

This article may be updated later to include additional remote access enhancements such as Parsec, TeamViewer, RustDesk, and Wake-on-LAN.

DEV Community: Siddharth Magesh

Fixing Extremely Slow Debian Boot on a Windows Dual-Boot System

Problem Overview

Step 1: Measure the boot process

Step 2: Identify the blocking dependency

Step 3: Identify the device

Root Cause

Step 4: Apply the fix safely

What this change does

Result

Key Takeaways

Conclusion

Secure Remote Access to a Windows Machine from Debian Using SSH and Tailscale

Introduction (Motive)

System Setup

High-Level Architecture

Step 1: Enable OpenSSH Server on Windows

1.1 Install OpenSSH Server (manual MSI method)

1.2 Create and start the sshd service

1.3 Allow SSH through Windows Firewall

Step 2: Configure SSH Authentication

2.1 Generate SSH key on Debian

2.2 Add public key to Windows

2.3 Fix permissions (important)

2.4 If you don’t have a Windows password

Step 3: Install Tailscale on Windows

3.1 Install via MSI (recommended)

3.2 Login to Tailscale

Step 4: Install Tailscale on Debian

Step 5: SSH Over Tailscale (Global Access)

Step 6: VS Code Remote SSH (Optional but Recommended)

6.1 Install extension on Debian

6.2 Add SSH host

6.3 Connect and open a specific folder

Common Pitfalls and Fixes

SSH asks for password repeatedly

VS Code code . doesn’t open over SSH

SSH doesn’t work after reboot

Power and Boot Behavior (Important)

Conclusion

Remote SSH Access to Windows from Debian: Complete Setup and Fixes

Remote SSH Access to a Windows Machine from Debian: Full Setup, Fixes, and Lessons Learned

System Setup

1. Problem: OpenSSH Server Optional Feature Fails to Install

2. Manual Installation of OpenSSH (MSI Method)

3. Create the SSH Service Manually

4. Allow SSH Through Windows Firewall

5. Determine Windows Local IP Address

6. Set a Password for the Windows User (Required for SSH)

7. SSH Configuration Fixes (Optional but Recommended)

8. (Optional) Add SSH Key Authentication

9. SSH From Debian (Same Local Network Only)

10. Notes and Hurdles Encountered

OpenSSH capability installation hanging

Service missing after reboot

Authentication failures

Public key not accepted

Conclusion

VS Code `code .` doesn’t open over SSH