sfdisk refuses to write GPT table between sector 34 and 2047

[Bill Yikes]

According to https://wiki.archlinux.org/title/GRUB#BIOS_systems, it's both legal and interesting to place the BIOS BOOT partition from sector 34 to sector 2047, as follows:

$ sudo sfdisk --no-act -f --label gpt /dev/sdb << EOF
start= 34, size=2013, name=bios, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /bios boot/{print $1}')
start= 2048, size=12582912, name=swap, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux swap/{print $1}')
EOF

The output is:

/dev/sdb1: Sector 34 already used.
Failed to add #1 partition: Numerical result out of range
Leaving.

It's a false error. As a workaround, users must use parted or sgdisk instead. (note fdisk & gdisk are also broken in the same way)

This bug was uncovered in 2015 and perhaps never reported to a bug tracker because it's still broken. See https://www.spinics.net/lists/util-linux-ng/msg11253.html

[Bill Yikes (yik3s)]

A secondary bug manifests from this, whereby sfdisk chokes on its own output and therefore cannot restore its own backup. E.g. suppose another tool is used to put a BIOS boot partition from sector 34 to 2047, as follows:

$ sgdisk --clear -a 1 --new=1:34:2047 -c 1:"BIOS boot" --typecode=1:$(sgdisk --list-types | sed -ne 's/.*\(....\).bios.*/\1/gip') /dev/sdb

That works fine, and from that we can run "sfdisk -d /dev/sdb > dump.txt". But when dump.txt is fed back into sfdisk, it pukes. Yet the docs claim "It is recommended to save the layout of your devices. sfdisk supports two ways." .. "Use the --dump option to save a description of the device layout to a text file." .. "This can later be restored by: sfdisk /dev/sda < sda.dump"

It's actually a security issue, because someone can make an non-restorable backup and have the false sense of security that it is restorable. They wouldn't necessary test restoration either because that's a destructive process.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.