sgdisk - Unexpected Behavior with Decimal Point in Partition Size Specification

Bug #2039594 reported by adrya
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdisk (Ubuntu)
Status tracked in Mantic

Bug Description

When using the sgdisk command to create a new partition with a specified size, the tool behaves unexpectedly when a size is specified with a decimal point. Specifically, using a size like 7.5G results in the partition size being set to 3.5 KiB instead.

Steps to Reproduce:

    Run the following command to create a partition:

    sgdisk --new=1:0:+7.5G --typecode=1:8300 --change-name=1:boot /dev/sda

    Verify the size of the newly created partition using sgdisk --print /dev/sda.

Expected Behavior:
The partition size should be set to 7.5 gigabytes, as specified in the --new command.

Actual Behavior:
The partition size is set to 3.5 KiB.

Additional Information:

    The issue can be worked around by specifying the size in megabytes, such as 7500M.

System Information:

    Operating System: Ubuntu 22.04.3 LTS
    sgdisk Version: GPT fdisk (sgdisk) version 1.0.8

Tags: fdisk
Revision history for this message
Rod Smith (rodsmith) wrote :

This is fixed in an upstream commit:

This commit causes input to be truncated to the nearest whole value; e.g., "+7.5G" becomes "+7G". Decimal processing would be imprecise and/or would add code that might hide more bugs. If that level of precision is needed, then using a lower unit (e.g., M or K rather than G) is more appropriate.

The upstream commit will eventually be released, presumably as version 1.0.10, but it's not out yet. Note that the current released version of GPT fdisk is 1.0.9, released in April of 2022; version 1.0.8 is out of date, although it was current as of Ubuntu 22.04's release.

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Thanks for taking the time to report this bug.

I can confirm it on all supported Ubuntu releases (F/J/L/M). Here's the reproducer:

# fallocate -l 10G a.img
# sgdisk --new=1:0:+7.5G --typecode=1:8300 ./a.img
# fdisk -l ./a.img

I haven't tried the patch mentioned by Rod, but it does seem to address the issue.

I'll add this to our backlog.

Changed in gdisk (Ubuntu Focal):
status: New → Triaged
Changed in gdisk (Ubuntu Jammy):
status: New → Triaged
Changed in gdisk (Ubuntu Lunar):
status: New → Triaged
Changed in gdisk (Ubuntu Mantic):
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.