sfdisk gets cylinder calculation wrong when using sectors

Bug #1481158 reported by Ian Wienand
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Fix Released
High
Unassigned
Trusty
Triaged
High
Unassigned

Bug Description

If you try and specify the starting offset for the partition in sectors and ask sfdisk to use the rest of the disk (with "+"), sfdisk will incorrectly calculate the end cylinders and not create the partition. For example

---

# dd if=/dev/zero of=/tmp/disk.img bs=1M count=10
# losetup -f /tmp/disk.img
# sfdisk -uS /dev/loop1 <<EOF
2048 + L *
0 0;
0 0;
0 0;
EOF
Checking that no-one is using this disk right now ...
BLKRRPART: Invalid argument
OK
Disk /dev/loop1: cannot get geometry

Disk /dev/loop1: 1 cylinders, 255 heads, 63 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
 /dev/loop1: unrecognized partition table type
Old situation:
No partitions found
New situation:
Warning: The partition table looks like it was made
  for C/H/S=*/71/5 (instead of 1/255/63).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0

   Device Boot Start End #sectors Id System
/dev/loop1p1 * 2048 20479 18432 83 Linux
  start: (c,h,s) expected (5,54,4) found (0,32,33)
  end: (c,h,s) expected (57,48,5) found (1,70,5)
/dev/loop1p2 0 - 0 0 Empty
/dev/loop1p3 0 - 0 0 Empty
/dev/loop1p4 0 - 0 0 Empty
Warning: partition 1 does not end at a cylinder boundary
end of partition 1 has impossible value for cylinders: 1 (should be in 0-0)

sfdisk: I don't like these partitions - nothing changed.
(If you really want this, use the --force option.)

---

Using the --force flag writes out the correct partitions. I also note this is fixed in 2.26, which has a large rewrite of sfdisk and uses sectors by default

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

I've hit this as well. 2.26 is available in Wily, so any fixes here would be to trusty. It seems like a major rewrite wouldn't be backported in the SRU process though. So this might have to remain unfixed in the LTS unless somebody wants to ferret out the problem and make a smaller patch just for 2.20.

Changed in util-linux (Ubuntu):
status: New → Confirmed
importance: Undecided → High
status: Confirmed → Fix Released
Changed in util-linux (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → High
Revision history for this message
Peter D. (0123peter) wrote :

I suspect that this causes a problem that later versions do not clean up. In this case the sequences was (probably) partition with Trusty, install Trusty, delete Trusty, .... , install Wily (without re-partitioning). The current partition table as displayed by fdisk on Trusty is clearly wrong for partition three (the one with Wily installed on it).

It is not obvious how to fix this without repartitioning, and re-installing. Neither is it obvious how much (if any) real trouble it has caused.

There has been persistent non-sense CHS and Disk-ID values on my phone's micro SD card, as well as some reliability trouble. It was partitioned and formatted under Trusty.

$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.26.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): x

Expert command (m for help): v
Remaining 54093 unallocated 512-byte sectors.

Expert command (m for help): p

Disk /dev/sda: 298.1 GiB, 320068705792 bytes, 625134191 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x25f55d02

Device Boot Start End Sectors Id Type Start-C/H/S End-C/H/S Attrs
/dev/sda1 * 2048 21655619 21653572 83 Linux 0/33/32 1023/63/254 80
/dev/sda2 21659646 600000511 578340866 5 Extended 1023/63/254 1023/63/254
/dev/sda3 600000512 625088511 25088000 83 Linux 484/42/77 1021/55/244
/dev/sda4 625121280 625133567 12288 83 Linux 1023/63/254 1023/63/254
/dev/sda5 21659648 42125311 20465664 83 Linux 1023/63/254 1023/63/254
/dev/sda6 42127360 62590975 20463616 83 Linux 1023/63/254 1023/63/254
/dev/sda7 62593024 83071538 20478515 82 Linux swap / Solaris 1023/63/254 1023/63/254
/dev/sda8 83073024 102602751 19529728 83 Linux 1023/63/254 1023/63/254
/dev/sda9 102604800 122134096 19529297 83 Linux 1023/63/254 1023/63/254
/dev/sda10 122136576 141666303 19529728 83 Linux 1023/63/254 1023/63/254
/dev/sda11 141668352 161197648 19529297 83 Linux 1023/63/254 1023/63/254
/dev/sda12 161200128 599994367 438794240 83 Linux 1023/63/254 1023/63/254
/dev/sda13 599996416 600000511 4096 83 Linux 1023/63/254 1023/63/254

Partition table entries are not in disk order.

Expert command (m for help): q

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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