** Description changed:
This command should non-interactively obliterate whatever partition
table is on /dev/sde, and create a new table with a linux partition that
spans the whole disk:
- $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label
+ $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label
gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')"
Sometimes it works correctly; sometimes not. It seems to work correctly
as long as the pre-existing partition table does not already contain a
linux partition. E.g. if the existing table just contains an exFAT
partition, there's no issue. But if there is a linux partition, it
gives this output:
-----
Old situation:
Device Start End Sectors Size Type
/dev/sde1 2048 1953525134 1953523087 931.5G Linux root (x86-64)
>>> Created a new GPT disklabel (GUID: <redacted>).
/dev/sde1: Sector 2048 already used.
Failed to add #1 partition: Numerical result out of range
Leaving.
-----
sfdisk should *always* overwrite the target disk unconditionally. This
is what the dump of the target drive looks like in the failure case:
$ sfdisk -d /dev/sdd
label: gpt
label-id: <redacted>
device: /dev/sdd
unit: sectors
first-lba: 34
last-lba: 1953525134
grain: 33553920
sector-size: 512
/dev/sdd1 : start= 2048, size= 1953523087,
type=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, uuid=<redacted>, name="Linux
x86-64 root (/)"
$ sfdisk -v
sfdisk from util-linux 2.36.1
Even the workaround is broken. That is, running the following:
$ wipefs -a /dev/sde
should put the disk in a state that can be overwritten. But whatever
residual metadata it leaves behind still triggers the sfdisk bug:
$ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T
| awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')"
Checking that no-one is using this disk right now ... OK
Disk /dev/sde: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
- Disk model: Disk
+ Disk model: Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
>>> Created a new GPT disklabel (GUID: <redacted>).
/dev/sde1: Sector 2048 already used.
Failed to add #1 partition: Numerical result out of range
Leaving.
+
+ Workaround 2 (also fails):
+
+ $ dd if=/dev/zero of=/dev/sde bs=1M count=512
+
+ $ sfdisk -d /dev/sde
+ sfdisk: /dev/sde: does not contain a recognized partition table
+
+ ^ the nuclear option did the right thing, but sfdisk still fails to
+ partition the drive (same error).
+
+ The *only* workaround that works is an interactive partitioning with
+ gdisk.
--
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/1940691
Title:
sfdisk fails to overwrite disks that contain a pre-existing linux
partition
Status in util-linux package in Ubuntu:
New
Bug description:
This command should non-interactively obliterate whatever partition
table is on /dev/sde, and create a new table with a linux partition
that spans the whole disk:
$ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk
--label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print
$1}')"
Sometimes it works correctly; sometimes not. It seems to work
correctly as long as the pre-existing partition table does not already
contain a linux partition. E.g. if the existing table just contains
an exFAT partition, there's no issue. But if there is a linux
partition, it gives this output:
-----
Old situation:
Device Start End Sectors Size Type
/dev/sde1 2048 1953525134 1953523087 931.5G Linux root (x86-64)
>>> Created a new GPT disklabel (GUID: <redacted>).
/dev/sde1: Sector 2048 already used.
Failed to add #1 partition: Numerical result out of range
Leaving.
-----
sfdisk should *always* overwrite the target disk unconditionally.
This is what the dump of the target drive looks like in the failure
case:
$ sfdisk -d /dev/sdd
label: gpt
label-id: <redacted>
device: /dev/sdd
unit: sectors
first-lba: 34
last-lba: 1953525134
grain: 33553920
sector-size: 512
/dev/sdd1 : start= 2048, size= 1953523087,
type=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, uuid=<redacted>,
name="Linux x86-64 root (/)"
$ sfdisk -v
sfdisk from util-linux 2.36.1
Even the workaround is broken. That is, running the following:
$ wipefs -a /dev/sde
should put the disk in a state that can be overwritten. But whatever
residual metadata it leaves behind still triggers the sfdisk bug:
$ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T
| awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')"
Checking that no-one is using this disk right now ... OK
Disk /dev/sde: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
>>> Created a new GPT disklabel (GUID: <redacted>).
/dev/sde1: Sector 2048 already used.
Failed to add #1 partition: Numerical result out of range
Leaving.
Workaround 2 (also fails):
$ dd if=/dev/zero of=/dev/sde bs=1M count=512
$ sfdisk -d /dev/sde
sfdisk: /dev/sde: does not contain a recognized partition table
^ the nuclear option did the right thing, but sfdisk still fails to
partition the drive (same error).
The *only* workaround that works is an interactive partitioning with
gdisk.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1940691/+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
