Linux – Script partitioning fresh raw disk images with sfdisk (C/H/S ignored?)

disk-imagelinuxpartition

I'm trying to automate the process of creating raw disk images. I don't care so much about C/H/S, but that the block size should be a rough standard of 512 bytes. However, I'm having trouble specifying the correct dimensions for partitions so that sfdisk can import them.

I first created a 32MB blank file:

$dd if=/dev/zero of=disk.img bs=1M count=32

Then I partitioned it using cfdisk:

$cfdisk -h 255 -s 63 -c 4 disk.img
  • Verify that cfdisk sees the C/H/S switches (at the top of the screen)
  • Create new partition 32.5MB, end of disk (to leave space for the boot stuff later)
  • Write
  • Quit

Then I output an sfdisk dump:

$sfdisk -H 255 -S 63 -C 4 -d disk.img > disk.parts

and got the following (in disk.parts):

# partition table of disk.img
unit: sectors

disk.img1 : start=     1276, size=    64260, Id=83, bootable
disk.img2 : start=        0, size=        0, Id= 0
disk.img3 : start=        0, size=        0, Id= 0
disk.img4 : start=        0, size=        0, Id= 0

However, when I try to reload that back into the image (as a test), sfdisk seems to at first accept the C/H/S switches when reading the original partition table and then throw them away when it tries to calculate the new partition table:

$sfdisk -H 255 -S 63 -C 4 disk.img < disk.parts

Warning: disk.img is not a block device
Disk disk.img: cannot get geometry

Disk disk.img: 4 cylinders, 255 heads, 63 sectors/track
Old situation:
Warning: The partition table looks like it was made
  for C/H/S=*/21/16 (instead of 4/255/63).
For this listing I'll assume that geometry.
Units = cylinders of 172032 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
disk.img1   *      3+    195-    192-     32130   83  Linux
        start: (c,h,s) expected (3,16,13) found (0,20,17)
        end: (c,h,s) expected (195,0,16) found (4,20,16)
disk.img2          0       -       0          0    0  Empty
disk.img3          0       -       0          0    0  Empty
disk.img4          0       -       0          0    0  Empty
New situation:
Warning: The partition table looks like it was made
  for C/H/S=*/21/16 (instead of 4/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
disk.img1   *      1276     65535      64260  83  Linux
        start: (c,h,s) expected (3,16,13) found (0,20,17)
        end: (c,h,s) expected (195,0,16) found (4,20,16)
disk.img2             0         -          0   0  Empty
disk.img3             0         -          0   0  Empty
disk.img4             0         -          0   0  Empty
Warning: partition 1 does not end at a cylinder boundary
end of partition 1 has impossible value for cylinders: 4 (should be in 0-3)

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

It appears that these two sections are in conflict:

 Warning: The partition table looks like it was made
  for C/H/S=*/21/16 (instead of 4/255/63).
 For this listing I'll assume that geometry.
 Units = cylinders of 172032 bytes, blocks of 1024 bytes, counting from 0

and

 For this listing I'll assume that geometry.
 Units = sectors of 512 bytes, counting from 0

And it then reinforces it with:

 end of partition 1 has impossible value for cylinders: 4 (should be in 0-3)

I tried -f (force) and it gives exactly the same output. 🙁

Why would sfdisk not process it's own dump format correctly, particularly when I'm already giving it all the information it needs? Why would it process the C/H/S when reading but not when writing? The C/H/S is not in the file, so why would it say that it looks like it was made for */21/16?

More importantly, how do I get around this so I can generate a partition table in a script?

Best Answer

C/H/S is pretty much obsolete and shouldn't be used. I'm not very familiar with sfdisk specifically, but any recent partitioning tool should let you specify your partition boundaries in term of 512-byte sectors, and for performance reasons they should always be 4k-aligned (so divisible by 8).

The specific issue you seem to have is that sfdisk cannot detect C/H/S on the image file (since it's not a block device) and end up with bogus values.

Related Topic