Debian 11 LVM on Azure User Guide

Overview

This guide covers the deployment and configuration of Debian 11 with an LVM root layout on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

Debian 11, codenamed bullseye, is a past release of Debian whose free security support has ended — read the notice below before choosing this image. What makes this image different from the standard Debian 11 image is the disk layout: the root filesystem lives on an LVM logical volume (debian-vg/root, the same naming the Debian installer's own guided LVM option produces) on top of a physical volume partition, instead of on a fixed raw partition. That means you can grow the root filesystem online — on the running system, with no reboot and no unmount — and reshape storage later with standard LVM tooling.

End of free security support notice — read this first

Debian 11 bullseye left free Debian LTS on 31 August 2026. Three facts follow, and all three matter:

• This image is patched to the final free archive state for bullseye — every package Debian's own hosts still publish for bullseye, bullseye-updates and bullseye-security was applied at build time, and the image was captured with zero pending upgrades. bullseye's last point release was 11.11 and no further free security uploads are coming.
• Continued security coverage for bullseye exists, but only through Extended LTS (ELTS), a paid subscription from Freexian, the company that runs Debian LTS. ELTS packages are published to Freexian's own repository and are not redistributable, so this image contains no ELTS package, no ELTS repository and no ELTS key. That is verified rather than asserted: every repository the image ships reports origin Debian, and every installed package version is one those repositories still offer. If your workload needs ongoing fixes you can buy a subscription from Freexian yourself and add their repository after deployment.
• The bullseye package pool is being retired to archive.debian.org as this is written, and the mirrors are pruning at different rates. This image already ships apt sources pointing at Debian's own hosts, and Step 9 shows the one line change to make when bullseye finishes its move to the archive.

Choose this image when your estate is standardised on bullseye — a dependency pinned to Debian 11, a fleet mid migration, a vendor appliance certified against it — and you need the LVM layout underneath it. For a fresh deployment with no Debian 11 constraint, use Debian 12 LVM or Debian 13 LVM, both of which are inside their free support windows on exactly the same LVM layout.

What's included:

• Debian 11 (bullseye) with root on LVM: GPT disk with an EFI system partition, a 2 GiB /boot partition, and an LVM physical volume carrying volume group debian-vg with logical volume root as / (ext4)
• The full LVM and grow toolchain: lvm2, growpart, pvresize, lvextend, resize2fs — everything needed to grow or reshape storage, nothing removed from the standard package set
• Patched to the final free archive state for bullseye at build time, with exactly one kernel installed
• apt sources repaired to Debian's own hosts, so the machine still has a working package source (see Step 9)
• unattended-upgrades armed and verified against the Debian security suite — the timers keep running, and they will pick up anything the free archive ever publishes
• Azure Linux Agent (walinuxagent) and cloud-init for Azure integration
• chrony for NTP time synchronisation
• AppArmor in enforcing mode
• Only SSH reachable from off the machine
• Gen2 Hyper V virtual machine support
• 24/7 cloudimg support

Platform: Microsoft Azure (Gen2 Hyper V, x64) Default user: azureuser

Security posture

This image ships with no known credential. There is no default password and no baked in SSH key:

• The root account password is locked, so no one can log in as root with a password.
• PasswordAuthentication is disabled in the SSH daemon, so every login is by key.
• PermitRootLogin is set to prohibit-password, so root cannot be reached with a password even if one were later set.
• The only key that works is the public key you supply when you create the virtual machine. Azure injects it into azureuser at first boot, so no two machines you launch ever share a secret.
• The machine identity and the SSH host keys are regenerated uniquely on every instance, so no two machines share a host key either.
• AppArmor is enabled and enforcing.
• SSH on port 22 is the only service listening off the machine. Nothing else is reachable.

The end of free security support does not change any of the above, but it does change what "patched" can mean over time — see the notice at the top of this guide.

Prerequisites

Before deploying this image, ensure you have:

1. An active Microsoft Azure subscription
2. Access to the Azure Portal or Azure CLI
3. An SSH key pair for Linux VM access
4. Familiarity with Azure VM management

Recommended VM Size: Standard_B2s (2 vCPU, 4 GB RAM) or larger.

Disk size: the image ships as a 30 GiB OS disk with the root volume taking all of its LVM space. If you want a larger root, set a bigger OS disk size at create time (for example 64 GiB) and then grow the root volume online as shown in Step 7 — that is exactly what this image is for.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

1. Navigate to the Azure Marketplace and search for "Debian 11 LVM cloudimg"
2. Select the image and click Create
3. Configure the basics:
4. Subscription: Select your Azure subscription
5. Resource Group: Create new or select existing
6. Virtual Machine Name: Enter a name for your VM
7. Region: Select your preferred Azure region
8. Size: Standard_B2s recommended
9. Under Administrator Account, select SSH public key and enter your key
10. Under Inbound Port Rules, allow SSH (port 22)
11. On the Disks tab, set the OS disk size you want (larger than 30 GiB if you plan to grow the root)
12. Click Review + Create, then Create

Option B: Azure CLI

az vm create \
  --resource-group myResourceGroup \
  --name my-debian-11-lvm-vm \
  --image cloudimg:debian:debian11lvm:latest \
  --size Standard_B2s \
  --os-disk-size-gb 64 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

--os-disk-size-gb 64 deploys the 30 GiB image onto a 64 GiB disk. The extra space is claimed in Step 7 with four commands, online. The image ships no password and no authorized key of its own: the only credential that will ever work is the SSH public key you supply here.

Step 2: Connect via SSH

Run these on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-debian-11-lvm-vm --show-details --query publicIps -o tsv
ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks you for one, the key you supplied at create time is not the key your client is offering.

Step 3: Confirm the release and the LVM layout

Check that the machine is the Debian 11 release you expect:

grep -E '^(NAME|VERSION|ID|VERSION_ID|PRETTY_NAME)=' /etc/os-release
cat /etc/debian_version
uname -srm
dpkg --print-architecture

Expected output:

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
ID=debian
11.11
Linux 5.10.0-46-cloud-amd64 x86_64
amd64

11.11 is bullseye's final point release — there will not be a 11.12.

Then confirm the defining property of this image — the root filesystem on an LVM logical volume:

findmnt -no SOURCE,FSTYPE /
sudo pvs
sudo vgs
sudo lvs

Expected output on a fresh VM deployed with the default 30 GiB disk:

/dev/mapper/debian--vg-root ext4
  PV         VG        Fmt  Attr PSize   PFree
  /dev/sda3  debian-vg lvm2 a--  <27.50g    0
  VG        #PV #LV #SN Attr   VSize   VFree
  debian-vg   1   1   0 wz--n- <27.50g    0
  LV   VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root debian-vg -wi-ao---- <27.50g

/ on /dev/mapper/debian--vg-root is what the standard image cannot give you: a root volume you can extend online and a volume group you can reshape. The disk itself is GPT with a 512 MiB EFI system partition, a 2 GiB /boot partition (kept as a plain partition so the bootloader never depends on LVM activation), and the rest as the LVM physical volume. VFree 0 is deliberate: the image ships with the root volume taking every extent, and growth comes from enlarging the disk, not from space held back.

Step 4: Check the patch level

On a release past the end of free security support, "fully patched" means something narrower than it does on a supported release: the machine has everything the free bullseye archive will ever publish. Confirm that nothing is pending and that exactly one kernel is installed:

apt-get -s -o APT::Get::Always-Include-Phased-Updates=true dist-upgrade | grep -c '^Inst ' | sed 's/^/pending upgrades: /'
apt-mark showhold
dpkg -l | awk '/linux-image-[0-9]/{print $2, $3}'

Expected output shows pending upgrades: 0, no held packages, and exactly one installed Debian cloud kernel:

pending upgrades: 0
linux-image-5.10.0-46-cloud-amd64 5.10.262-1

Exactly one kernel package ships on purpose: a superseded kernel left installed would keep matching its own security advisories even though it never boots.

pending upgrades: 0 here does not mean the machine is patched against everything disclosed since 31 August 2026 — fixes for those exist only in Freexian's paid ELTS stream, which this image deliberately does not contain. The image still arms unattended-upgrades with the Debian security origin enabled, so the timers keep running against the free archive; they simply find nothing new. You can still run updates on your own schedule:

sudo apt-get update && sudo apt-get -y dist-upgrade

Reboot if a new kernel was ever installed:

sudo systemctl reboot

Step 5: Verify the security posture

Confirm AppArmor is enforcing, root is locked, and SSH is key only:

sudo aa-status --enabled && echo "apparmor: enabled"
sudo passwd -S root
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

Expected output:

apparmor: enabled
root L 12/22/2009 -1 -1 -1 -1
permitrootlogin without-password
pubkeyauthentication yes
passwordauthentication no

without-password is how OpenSSH reports the prohibit-password setting. Both names mean the same thing: root may not authenticate with a password. The L from passwd -S means the root account is locked; the date beside it is the epoch placeholder Debian ships, not a change you need to act on.

Step 6: Verify Azure integration and unattended updates

Confirm the Azure Linux Agent, cloud-init and time synchronisation are healthy, that unattended security updates are armed, and check your resources:

systemctl is-active walinuxagent 2>/dev/null || systemctl is-active waagent
cloud-init --version
systemctl is-enabled apt-daily-upgrade.timer
apt-config dump | grep -E 'APT::Periodic::(Update-Package-Lists|Unattended-Upgrade) '
systemctl is-active chrony
df -h /

Expected output:

active
/usr/bin/cloud-init 22.4.2
enabled
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
active
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/debian--vg-root   27G  1.2G   25G   5% /

The Azure Linux Agent is what lets Azure provision your SSH key, run extensions and report VM health, so it should always be active. apt-daily-upgrade.timer being enabled, together with Unattended-Upgrade "1" in the apt periodic config, keeps the update mechanism live against the frozen free archive as shipped — and it would start applying ELTS fixes automatically through the same mechanism if you ever added a Freexian subscription of your own.

Step 7: Grow the root filesystem online

This is the reason to choose the LVM image. If you deployed with an OS disk larger than 30 GiB (as in the Step 1 CLI example), the extra space is sitting unclaimed beyond the LVM partition, and you claim it on the running system — no reboot, no unmount, no downtime.

Two things to know first, both measured on this exact image:

• cloud-init does not claim the space for you. Its growpart module skips LVM roots by design — /var/log/cloud-init.log records '/' SKIPPED: Resizing mapped device (/dev/mapper/debian--vg-root) skipped as it is not encrypted. — so on first boot the partition, the physical volume and the root volume stay at their shipped 27.5 GiB.
• Nothing else grows it either. The stock Debian image's x-systemd.growfs mount option is deliberately absent from this image's /etc/fstab, and the cloud-initramfs-growroot hook in the initramfs leaves a mapped root device alone. Boot a 64 GiB VM and df -h / still reports 27G until you run the chain below.

That leaves you in control of when and how the space is used. The chain claims all of it into /; run it as is, or stop after pvresize if you would rather keep the space free in the volume group for other volumes.

DISK="$(readlink -f /dev/disk/azure/root)"
sudo growpart "${DISK}" 3
sudo pvresize "${DISK}3"
sudo lvextend -l +100%FREE /dev/debian-vg/root
sudo resize2fs /dev/debian-vg/root
df -h /
FREE=$(sudo vgs --noheadings -o vg_free_count debian-vg | tr -dc '0-9')
PVB=$(sudo pvs --noheadings --units b --nosuffix -o pv_size "${DISK}3" | tr -dc '0-9')
PARTB=$(( $(cat /sys/class/block/$(basename "${DISK}")3/size) * 512 ))
if [ "${FREE:-1}" -ne 0 ]; then echo "FAIL: ${FREE} free extents remain in VG debian-vg"; exit 1; fi
if [ "$(( PARTB - PVB ))" -gt 8388608 ]; then echo "FAIL: pvresize did not take - partition ${PARTB}B vs physical volume ${PVB}B"; exit 1; fi
echo "root volume fully extended: 0 free extents in VG debian-vg, and the physical volume fills the partition"

Expected output on a 64 GiB disk, exactly as produced by this image:

CHANGED: partition=3 start=5244928 old: size=57667584 end=62912512 new: size=128972767 end=134217695
  Physical volume "/dev/sda3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
  Size of logical volume debian-vg/root changed from <27.50 GiB (7039 extents) to <61.50 GiB (15743 extents).
  Logical volume debian-vg/root successfully resized.
resize2fs 1.46.2 (28-Feb-2021)
Filesystem at /dev/debian-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 8
The filesystem on /dev/debian-vg/root is now 16120832 (4k) blocks long.

Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/debian--vg-root   61G  1.2G   57G   2% /
root volume fully extended: 0 free extents in VG debian-vg, and the physical volume fills the partition

resize2fs says on-line resizing required and does it against the mounted root — the whole chain runs on the live system, and the machine's uptime is unbroken. The device shown by readlink may differ between boots (/dev/sda on one boot, /dev/sdb on another); the /dev/disk/azure/root link always points at the OS disk, which is why the chain uses it.

The two checks at the end are worth keeping in your own automation, because each catches a failure the other cannot see. vg_free_count at 0 proves lvextend claimed everything. The physical volume filling the partition, to within LVM's small metadata gap, proves pvresize actually took — and on this release it really is load bearing: bullseye ships growpart 0.31, which does not resize the physical volume for you, so skipping pvresize leaves a 36 GB gap between the grown partition and an untouched physical volume while vg_free_count still reads 0 and a single check would happily pass.

If the disk was already fully claimed, growpart reports NOCHANGE and exits non zero, lvextend reports the size already matches, and the final checks still pass — the chain is safe to re-run.

Growing an existing VM later: enlarge the OS disk first (deallocate the VM, az disk update --resource-group <rg> --name <os-disk-name> --size-gb <new-size>, start the VM — or use the portal's Disks blade), then run the same chain. The LVM layout also lets you go further than root growth: attach a data disk and add it to the volume group with sudo pvcreate on the new disk's partition and sudo vgextend debian-vg, then carve dedicated volumes for data or logs with sudo lvcreate — all without touching the root filesystem.

Step 8: Networking and the firewall

The Azure Network Security Group is the control plane for inbound and outbound traffic, and it is the first and usually the only place you need to open a port. The image advertises a single inbound port, SSH on 22, and that is also the only service listening off the machine:

sudo ss -tlnp

Expected output on a fresh machine — sshd on port 22, IPv4 and IPv6, and nothing else:

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=642,fd=3))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=642,fd=4))

The process ids differ on every boot; the two sshd rows are what matters. Debian 11 leaves systemd-resolved disabled, so unlike Debian 12 and 13 this release opens no resolver socket at all — not even on loopback. Name resolution goes through /etc/resolv.conf and Azure's platform DNS directly.

Debian ships no host firewall active by default, so your NSG rules take effect exactly as written with no second layer to keep in sync. If your policy requires a host firewall as well, bullseye's iptables is installed (backed by nftables) and ufw is one package away. Add the SSH rule first, before enabling, so you do not lock yourself out:

sudo apt-get install -y ufw
sudo ufw allow OpenSSH
sudo ufw enable

Once a host firewall is running, a port must be open in both the Azure NSG and the host firewall before traffic reaches your service.

Step 9: Package sources on a retired release

This is the step that is specific to a release past its free support window, and it is worth reading even if you never install another package.

The stock Debian 11 image for Azure points apt at a regional Azure mirror, debian-archive.trafficmanager.net. That mirror still serves the bullseye indexes but has already pruned its package pool, so apt can see 64 updates and download none of them. This image therefore ships sources pointing at Debian's own hosts instead, and it masks the waagent-apt.service unit that would otherwise rewrite them back to the pruned mirror on first boot. Check what you have:

grep -vE '^\s*#|^\s*$' /etc/apt/sources.list
systemctl is-enabled waagent-apt.service
sudo apt-get update

Expected output:

deb https://deb.debian.org/debian bullseye main
deb https://deb.debian.org/debian bullseye-updates main
deb https://security.debian.org/debian-security bullseye-security main
deb https://deb.debian.org/debian-security bullseye-security main
masked

bullseye-security is listed twice on purpose. While bullseye is being retired, deb.debian.org and security.debian.org carry different subsets of the security pool, and listing both lets apt fall back to the second when the first returns a 404. Masking waagent-apt.service does not affect the Azure Linux Agent itself, which stays enabled and active.

When bullseye completes its move to archive.debian.org, replace the file with the archive form. Debian stops signing a retired suite's Release file afresh, so check-valid-until=no is required:

deb [check-valid-until=no] https://archive.debian.org/debian bullseye main

and drop the bullseye-updates and bullseye-security lines, which do not exist on the archive host. Then sudo apt-get update. Nothing new will appear — the archive is a frozen copy — but apt-get install for packages that were in bullseye keeps working.

If you buy Extended LTS from Freexian, add their repository and key alongside these lines following Freexian's own instructions. cloudimg does not ship, resell or support ELTS, and this image contains none of it.

Step 10: Install software

The Debian archive carries the application packages. Search it, then install what you need:

apt-cache search nginx 2>/dev/null | sed -n '1,5p'

Install a package and enable it in the usual way, for example sudo apt-get install -y nginx followed by sudo systemctl enable --now nginx. Remember the support posture from the top of this guide applies to everything you install from the archive: those package versions are frozen where free security support ended.

To add another administrator, create the account with sudo adduser <name>, add it to the sudo group with sudo usermod -aG sudo <name>, then copy your public key into /home/<name>/.ssh/authorized_keys with mode 600 and the .ssh directory mode 700, owned by that user. The image ships with no human accounts at all, so azureuser is the only login until you add one:

getent group sudo

Expected output:

sudo:x:27:azureuser

Common Use Cases

• Estates standardised on Debian 11 that need the LVM layout under an existing, certified stack
• Workloads mid migration off bullseye that need a like for like base with room to grow storage
• Servers that will gain dedicated volumes later, for data, logs or applications
• Teams whose build standard requires LVM managed disks on every server

Troubleshooting

Cannot connect via SSH

1. Verify the VM is in Running state in the Azure Portal
2. Check that port 22 is allowed in the Network Security Group
3. Ensure you are using the correct username: azureuser
4. Verify your SSH key matches the one you supplied at create time. Password login is disabled by design, so a wrong key cannot fall back to a password prompt.

To see which key your client is actually offering, run ssh -v azureuser@<vm-ip> from your workstation and look for the Offering public key lines.

df shows 27G on a bigger disk

That is the expected state before Step 7 has been run: nothing on this image grows an LVM root automatically, so a VM deployed on a 64 GiB disk boots with the shipped 27.5 GiB root volume until you claim the space. Run the Step 7 chain — it is online and takes seconds.

growpart says NOCHANGE

The partition already fills the disk. growpart exits non zero on NOCHANGE, which is informational, not an error — if you expected new space, confirm the OS disk resize actually happened (az disk show --query diskSizeGb) and that the VM was restarted after an offline disk resize.

apt reports 404 Not Found on a package

This is the retirement of bullseye showing through, not a broken machine. The indexes for a suite and the .deb files behind them are pruned at different times and on different mirrors. Try the other security host first, then the archive host:

sudo apt-get update
sudo apt-get -o Acquire::Retries=3 install <package>

If it still 404s, switch to archive.debian.org as shown in Step 9. Note that apt-get update succeeding against the free archive is the expected state — it simply no longer receives new uploads.

Azure agent not running

sudo systemctl status walinuxagent
sudo systemctl enable --now walinuxagent

Package manager issues

Refresh the metadata cache first:

sudo apt-get update

If repositories are unreachable, check DNS resolution. getent is always present and resolves through the same system resolver:

getent hosts deb.debian.org

Error priority journal lines at boot

One error priority journal line appears on every boot of a Debian 11 image on Azure and is expected and harmless: dhclient ... Timeout too large reducing to: 2147483646 (TIME_MAX - 1) — the ISC DHCP client clamping an infinite lease timer during cloud-init's short lived first boot DHCP probe. It does not affect the address the machine ends up with. Beyond that, a healthy machine has no AppArmor denials in the kernel log at all:

sudo journalctl -k --no-pager | awk '/apparmor/ && /DENIED/{n++} END{print "apparmor denials: " n+0}'

Expected output:

apparmor denials: 0

Important Notes

Debian is free and open source. It is not covered by a single licence: it is a distribution assembled from thousands of independently packaged components, each carrying its own terms, including the GPL, LGPL, MIT, BSD and Apache 2.0. Every package's terms are readable under /usr/share/doc/<package>/copyright. This image enables only Debian's DFSG-free main component. No subscription or licence key is required to run this image.

Debian 11 bullseye left free Debian LTS on 31 August 2026, and this image is patched to the final free archive state for that release. Extended LTS (ELTS) is a paid subscription from Freexian, not from cloudimg: its packages are not redistributable, so this image ships none of them, and buying a subscription is entirely your own decision to make with Freexian. For a deployment with no Debian 11 constraint, choose a release that is still inside its free support window.

Debian is a trademark of Software in the Public Interest, Inc. The name is used here nominatively, only to identify the distribution this image contains. Freexian is named only to identify the independent vendor of the Extended LTS subscription. cloudimg is not affiliated with, endorsed by or sponsored by the Debian Project, Software in the Public Interest, Inc. or Freexian.

Support

For assistance with this image, contact cloudimg support:

• Website: www.cloudimg.co.uk
• Product Catalogue: www.cloudimg.co.uk/products
• User Guides: www.cloudimg.co.uk/guides
• SLA: 24 hour response guaranteed