Sector Sizes and Imaging¶

Every disk reports two sector sizes: a logical sector size (the unit the
operating system reads and writes in) and a physical sector size (the unit
the drive actually stores data in). For imaging, the one that matters is the
logical sector size.

512n — 512-byte logical, 512-byte physical. Traditional drives.
512e — 512-byte logical, 4096-byte physical. Most current SATA/SAS drives.
As far as FOG is concerned these behave exactly like 512n: the logical size is
512.
4Kn — 4096-byte logical, 4096-byte physical. Common on enterprise NVMe and
some large SAS drives.

You can read a disk's logical sector size from a FOS shell (or any Linux host)
with blockdev --getss /dev/sdX, which prints 512 or 4096.

Important

512n and 512e mix freely. An image captured on a 512e disk deploys fine to
a 512n disk and the reverse, because both use a 512-byte logical sector. The
problem described below is only between 512-byte-logical disks and 4Kn
(4096-byte-logical) disks.

Why a mismatch breaks imaging¶

FOG captures partition contents with partclone and captures the partition table
with sfdisk. Both record geometry in the source disk's logical sectors:

the partition table stores each partition's start and length in LBA units
(logical sectors), and
each filesystem's own metadata bakes in the sector size it was created with.

On deploy, FOG restores that table and those filesystems verbatim — it does
not, and cannot safely, translate the numbers from one sector size to another. So
if you capture on a 4Kn disk and deploy to a 512-byte disk (or the reverse), the
partition offsets land in the wrong place and the filesystems describe a geometry
the disk doesn't have. The result is an unmountable, unbootable disk — often with
no obvious error at deploy time.

There is no reliable way to convert an image between logical sector sizes after
capture. The image has to be deployed to a disk with the same logical sector
size it was captured on.

What FOG does about it¶

FOS checks for this before it touches the target disk. This is part of the FOS
imaging engine, so it applies to any FOG server version running a FOS build that
includes it. When FOS begins a partition-table restore it compares:

the image's sector size, read from the stored sfdisk dump's sector-size:
line, against
the target disk's logical sector size from blockdev --getss.

If both are known and they differ, FOS stops the deploy rather than write an
unbootable disk. The message names both sizes, for example:

Sector size mismatch
   Image was captured on a disk with 4096-byte logical sectors, but /dev/nvme0n1
   uses 512-byte logical sectors.
   Partition-table and filesystem geometry cannot be translated between logical
   sector sizes, so this image cannot be deployed to this disk.
   Deploy this image only to a disk with 4096-byte logical sectors, or capture a
   new image on a disk with 512-byte logical sectors.

This is a refusal, not a corruption — nothing has been written to the disk at
this point.

NVMe targets can be reformatted to match¶

NVMe namespaces can often be low-level reformatted to a different logical
sector size, because the drive exposes one or more selectable "LBA formats." When
the target is an NVMe device and it exposes an LBA format that matches the image's
sector size, FOS reformats it to match instead of simply refusing:

 *** Logical sector-size mismatch on /dev/nvme0n1 ***
   This image was captured with 4096-byte logical sectors.
   /dev/nvme0n1 is an NVMe device that exposes a matching 4096-byte LBA format (lbaf 1).
   FOS will LOW-LEVEL REFORMAT this namespace to 4096-byte sectors so the image can deploy.
   This ERASES the drive (the deploy would erase it regardless) and cannot be undone.

 You have 60 seconds to power off this computer to cancel!

FOS counts down for 60 seconds. To cancel, power the machine off during
the countdown — nothing has been changed yet.
If you let it run, FOS reformats the namespace with nvme format, confirms the
new logical size by re-reading the disk, and then continues the deploy. If the
reformat doesn't take, FOS refuses instead of proceeding.
The reformat erases the namespace. This is not extra data loss — a deploy
overwrites the disk anyway — but it does mean there is no "undo."

Note

This only applies to NVMe. Some NVMe drives are 4Kn-only and expose no
512-byte LBA format; those can only receive 4Kn images. No other device type
can be re-sectored — see the per-type breakdown below. In every case where the
geometry can't be matched, FOS refuses rather than produce a bad disk.

Sector sizes by device type¶

"Can't FOG just reformat it like NVMe?" is a fair question for every kind of
disk, so here is the whole landscape. The short answer: NVMe is the only
device type with a safe, standard way to switch its logical sector size, which
is why it's the only one FOS reformats automatically.

Target type	Logical sector size	Can it be changed?
NVMe (`/dev/nvmeXnY`)	512 or 4096, per LBA format	Yes — if the drive exposes an LBA format at the needed size, FOS reformats it automatically (see above)
eMMC / SD (`/dev/mmcblkX`)	512, always	No — fixed by the MMC/SD specification
UFS (appears as `/dev/sdX`)	4096 on most modules	No — set when the module is provisioned at the factory and not changeable in the field
SATA / SAS (`/dev/sdX`)	512 on most drives (512n/512e), 4096 on 4Kn drives	No — a small number of enterprise drives support vendor "FastFormat" re-sectoring, but it generally needs a power cycle to take effect, so FOG does not attempt it
USB-attached (`/dev/sdX`)	whatever the enclosure's bridge chip reports	No — the bridge decides, not the drive or FOG
Virtual disk (`/dev/vdX`, or `sdX` in a VM)	set by the hypervisor	Not from inside FOS — but you can change it yourself in the VM's disk configuration (e.g. the `logical_block_size` disk property in QEMU/libvirt/Proxmox)

Two practical consequences of that table:

eMMC and SD targets (tablets, thin clients, some mini PCs) can only ever
receive images captured on 512-byte-logical hardware. A 4Kn image will
never deploy to them; recapture on 512-byte hardware is the only fix.
UFS-based machines (many recent thin-and-light laptops and tablets)
capture 4096-byte images. Those deploy fine to 4Kn disks and to NVMe
targets (the automatic reformat above handles NVMe) — but never to 512-byte
SATA, eMMC, or USB targets.

When FOS refuses a mismatch on one of these device types, the refusal message
names the device type and says whether its sector size is fixed, so you know
which side of the mismatch can actually be fixed.

When the check does and doesn't apply¶

It applies to normal partition-image deploys — single-disk and
multi-partition, resizable and non-resizable — in both directions (512 ↔ 4Kn).

It does not apply to:

Raw / dd whole-disk images. These store no sfdisk geometry, so there is
nothing to compare. A raw image is a byte-for-byte copy and will only work on a
disk of matching size and geometry regardless.
Single-partition restores (the "no partition table" / nombr path). These
deliberately skip the partition-table rewrite, so the sector-size check is
skipped with it.
Images captured by very old FOS versions. sfdisk did not record a
sector-size: line until util-linux 2.35 (around 2020). An image captured by a
FOS older than that carries no recorded source size, so FOS allows the deploy
rather than guess and risk a wrong refusal. Every image current FOS produces
records the line, so recent captures are checked in both directions.

What to do about a mismatch¶

Preferred: capture your golden image on hardware with the same logical
sector size as the machines you deploy to. If your fleet is 512-byte disks,
capture on a 512-byte disk; if it's 4Kn, capture on 4Kn.
NVMe fleets: if your targets are NVMe, let FOS reformat them to match (see
above), or pre-format them yourself to the needed LBA format.
Mixed fleets: if you deploy the same OS to both 512-byte and 4Kn hardware,
keep two images — one captured on each geometry.