sfdisk input parsing broken with 2.26.1

sfdisk input parsing broken with 2.26.1

[Thomas Bechtold]

[please CC me - I'm not subscribed to the list]

Hi,

the following worked fine with 2.20 (tested on Ubuntu):

sfdisk $IMAGE_BLOCK_DEVICE << EOF
1 - - *
0 0;
0 0;
0 0;
EOF


Same code doesn't work with 2.26.1 (tested on openSUSE Tumbleweed).
First line can't be parsed:

line 1: unsupported command


I recognized that while testing OpenStack's diskimage-builder[1]. Seems
there is also a bugreport from an Arch user[2].

Tom


[1] https://bugs.launchpad.net/diskimage-builder/+bug/1444496
[2] https://bugs.archlinux.org/task/44349

Re: sfdisk input parsing broken with 2.26.1

[Karel Zak]

On Thu, Apr 16, 2015 at 11:59:01AM +0200, Thomas Bechtold wrote:
> [please CC me - I'm not subscribed to the list]
> 
> Hi,
> 
> the following worked fine with 2.20 (tested on Ubuntu):
> 
> sfdisk $IMAGE_BLOCK_DEVICE << EOF
> 1 - - *
> 0 0;
> 0 0;
> 0 0;
> EOF

I have doubts that '-' is documented somewhere, but you're right that
this feature is supported by the old version. I'll fix the problem in
v2.26.2.

If the goal is to set bootable flag then you can use

 echo ",,,*' | sfdisk -N1 $IMAGE_BLOCK_DEVICE

or 
 
 sfdisk --activate ...


Note that there was another problem with boot flag if you resize
partition (commit 4d156d92eb538f9dbc077a2dd181a48d8fdc65cd), will be
also in 2.26.2.


    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: sfdisk input parsing broken with 2.26.1

[Ruediger Meier]

On Thursday 16 April 2015, Thomas Bechtold wrote:
> [please CC me - I'm not subscribed to the list]
>
> Hi,
>
> the following worked fine with 2.20 (tested on Ubuntu):
>
> sfdisk $IMAGE_BLOCK_DEVICE << EOF
> 1 - - *
> 0 0;
> 0 0;
> 0 0;
> EOF


BTW I've noticed that since 2.26 --dump produces incompatible dump 
files. Shouldn't we have at least backward compatibility, i.e. old 
dumps still work with new sfdisk?

If you dump the above example with sfdisk 2.23.2 then 2.26 cant't use 
it.

## Dump with old sfdisk:

$ sfdisk -d /tmp/image > /tmp/p1
$ cat /tmp/p1
# partition table of /tmp/image
unit: sectors

/tmp/image1 : start=    16065, size=209696445, Id=83, bootable
/tmp/image2 : start=        0, size=        0, Id= 0
/tmp/image3 : start=        0, size=        0, Id= 0
/tmp/image4 : start=        0, size=        0, Id= 0
----------------

## Write back with new sfdisk:

$ ./sfdisk /tmp/image < /tmp/p1
Checking that no-one is using this disk right now ... OK

Disk /tmp/image: 100 GiB, 107374182400 bytes, 209715200 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: 0x00000000

Old situation:

Device      Boot Start       End   Sectors  Size Id Type
/tmp/image1 *    16065 209712509 209696445  100G 83 Linux

>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0xdf10c8b1.
Created a new partition 1 of type 'Linux' and of size 100 GiB.
Start sector 0 out of range.
Failed to add partition: Numerical result out of range
/tmp/image2: Leaving.
-------------

cu,
Rudi

Re: sfdisk input parsing broken with 2.26.1

[Karel Zak]

On Thu, Apr 16, 2015 at 01:51:22PM +0200, Ruediger Meier wrote:
> BTW I've noticed that since 2.26 --dump produces incompatible dump 
> files. 

Yes, this is expected behavior.

> Shouldn't we have at least backward compatibility, i.e. old 
> dumps still work with new sfdisk?

yes

> >>> Script header accepted.
> >>> Created a new DOS disklabel with disk identifier 0xdf10c8b1.
> Created a new partition 1 of type 'Linux' and of size 100 GiB.
> Start sector 0 out of range.
> Failed to add partition: Numerical result out of range
> /tmp/image2: Leaving.

This is bug introduces probably later when I learned libfdisk to
accept zero size/offsets. 

Fixed, will be in v2.26.2 (probably next week).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com