sfdisk input parsing broken with 2.26.1
[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
Karel Zak
maintainerQuoted 4 lines · Thomas Bechtold
[please CC me - I'm not subscribed to the list]
Hi,
Quoted 8 lines
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
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 4 lines · Thomas Bechtold
[please CC me - I'm not subscribed to the list]
Hi,
Quoted 8 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Script header accepted.
Created a new DOS disklabel with disk identifier0xdf10c8b1.
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
Karel Zak
maintainerQuoted 2 lines · Ruediger Meier
BTW I've noticed that since 2.26 --dump produces incompatible dump files.
Yes, this is expected behavior.
Quoted 2 lines
Shouldn't we have at least backward compatibility, i.e. old dumps still work with new sfdisk?
yes
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Script header accepted.
Created a new DOS disklabel with disk identifier0xdf10c8b1.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
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com