Debian 11 LVM

Option A: Azure Portal

• Go to the Azure Marketplace and search for "Debian 11 LVM SecureAnyCloud".
• Select the image and click Create.
• Configure the basics:
  • Subscription: select your Azure subscription.
  • Resource Group: create a new one or select an existing one.
  • Virtual Machine Name: enter a name for your VM.
  • Region: select your preferred Azure region.
  • Size: Standard_B2s is recommended.
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22).
• On the Disks tab, set the OS disk size you want. Choose more than 30 GiB if you plan to grow the root.
• Click Review + Create, then Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:debian-11-lvm:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-debian-11-lvm-vm \
  --image sac1647283583153:debian-11-lvm:default: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. You claim the extra space online in Step 7 with four commands.

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.

Run these commands 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, your client is not offering the key you supplied at create time.

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 an 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 and the LVM physical volume in the rest. The /boot partition is a plain partition, so the bootloader never depends on LVM activation. 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.

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 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

If a new kernel was ever installed, reboot:

sudo systemctl reboot

Confirm that 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 date that Debian ships. You do not need to act on it.

Confirm that the Azure Linux Agent, cloud-init and time synchronisation are healthy and that unattended security updates are armed. Then check your disk 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 lets Azure provision your SSH key, run extensions and report VM health, so it should always be active.

With apt-daily-upgrade.timer enabled and Unattended-Upgrade "1" in the apt periodic config, the update mechanism stays live against the frozen free archive as shipped. It would also start applying ELTS fixes automatically if you ever added a Freexian subscription of your own.

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 sits unclaimed beyond the LVM partition. You claim it on the running system, with no reboot, no unmount and 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. 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 runs 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.

Keep the two checks at the end 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.

On this release the second check is essential. bullseye ships growpart 0.31, which does not resize the physical volume for you. Skipping pvresize leaves a 36 GB gap between the grown partition and an untouched physical volume, while vg_free_count still reads 0. A single check would pass.

If the disk was already fully claimed, growpart reports NOCHANGE and exits non-zero, lvextend reports that 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, run az disk update --resource-group <rg> --name <os-disk-name> --size-gb <new-size>, then start the VM. You can also 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. None of this touches the root filesystem.

The Azure Network Security Group is the control plane for inbound and outbound traffic. 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 is 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. 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 active host firewall 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 you enable the firewall, 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.

This step is specific to a release past its free support window. Read it 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. It also masks the waagent-apt.service unit, which would otherwise rewrite the sources 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. 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

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

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

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. The support notice at 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 on the file and mode 700 on the .ssh directory, both owned by that user.

The image ships with no human accounts at all, so azureuser is the only login until you add one. Check the sudo group:

getent group sudo

Expected output:

sudo:x:27:azureuser