Comment 1 for bug 1929087

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.