Package: fdisk Version: 2.40.4-3 Severity: normal Tags: upstream X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
Summary: When using sfdisk's script mode to create a GPT partition with a value
for last-lba smaller than the maximum applicable value, the extra space becomes
unavailable. If this is done by accident, it's hard to learn about it, and also
to fix this: The various "verify" commands do not report such a situation, and
AFAICS there is no option to repair this either. Workarounds exist, see
below.
While having a partition table smaller than the disk size might be a feature
for some (possibly exotic) use cases, it's more likely this happens in error.
Therefore the various verify methods should report such a situation, and there
should be a way to edit the last-lba value.
Long story: When replacing a disk, I often clone the partition table to ease
partitioning of the new one[1]. So I do something like:
* sfdisk --dump /dev/old >dump
* $EDITOR dump
* sfdisk /dev/new <dump
where in the editor I remove some information that is not needed for the job,
mostly uuids and "label-id:".
This time however, the new disk was somewhat bigger, and I just did not think
of removing the "last-lba:" line - only to find later that in the various
*fdisk programs the new disk has the same logical size as the old one, and the
new space is not available. Checking with "sfdisk --verify" shows no errors or
warnings of that kind. And it seems there is no option to correct the error.
Workaround:
* Either: Use gdisk[2], "extra functionality (experts only)" -> "relocate
backup data structures to the end of the disk".
* Or run "sfdisk --dump /dev/new" on that device, drop the "last-lba:" line
from the output, and feed the result to another "sfdisk /dev/new".
In either way, a reboot will likely be required if the disk is in use.
How to repeat:
Run that little script to create an image where last-lba is smaller then it
could be, the maximum acceptable value was 4194270.
==========================================================
fallocate --length=2G blob.img
sfdisk blob.img <<__EOS__
label: gpt
unit: sectors
first-lba: 2048
last-lba: 2097135
sector-size: 512
/dev/sdx : start= 2048, size= 2095088,
type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
__EOS__
==========================================================
Run "sfdisk --verify blob.img"
Expected: A warning like "Block device is bigger than the last LBA value,
2097119 sectors are unavailable".
Got: Nothing of that kind.
It seems there is no item in the "expert" or "recovery" menus of fdisk/cfdisk
to handle that situation.
Related, using "cfdisk blob.img" to see the partition table shows the real
device size (4194304 sectors) in the title bar, but in the main table there is
no "Free Space" that might be allocated for another partition. Well, given the
last-lba definition the latter is correct - still it might be worth an idea to
show a line like "Inaccessible".
Regards,
Christoph
[1] I learned no earlier than today the *gdisk programs have an options for
that.
[2] gdisk is a different package and upstream. FYI, this issue has been
reported there earlier:
https://sourceforge.net/p/gptfdisk/mailman/message/58852757/
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.10 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages fdisk depends on:
ii libc6 2.40-6
ii libfdisk1 2.40.4-3
ii libmount1 2.40.4-3
ii libncursesw6 6.5+20250125-2
ii libreadline8t64 8.2-6
ii libsmartcols1 2.40.4-3
ii libtinfo6 6.5+20250125-2
Versions of packages fdisk recommends:
ii sensible-utils 0.0.24
fdisk suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
