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. ** Description changed: 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 omit the BIOS BOOT - partition then use gdisk to insert it manually. This 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 + 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 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1929087 Title: sfdisk refuses to write GPT table between sector 34 and 2047 Status in util-linux package in Ubuntu: New Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1929087/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
