which is a prep partition (type 4100) using 512b sectors (1M offset / 512)
== 2048
the end is 2048 + (8 * 1024 * 1024) / 512 - 1 sector)
2048 + (8388608 - 512) / 512
2048 + 16383
18431
And the second partition command:
previous partition number for 'sda-part2' found to be '1'
adding partition 'sda-part2' to disk 'sda'
Running command ['sgdisk', '--new', '2:18432:554272767',
'--typecode=2:8300', '/dev/sdd'] with allowed return codes [0]
(shell=False, capture=False)
This runs the same code which finds the previous partition, then reads size
and start from sysfs. It finds
the same 18431 ending sector, adds one and we start the new section with
18432.
On the failing node,
the default sector size is 4k, we take our 1M offset / 4096, and we get 256
on the offset.
But when calculating the second partition, somehow the logical_size is 512,
otherwise we'd
get a different starting sector.
18432 is correct for bs=512, but should be 2304 for 4k.
I confirmed the python math, /sys/block/sde/queue/logical_block_size is
returning 4096
then our initial offset is:
That's bizarre, and I'd think some sort of kernel bug unless there's some
setting that controlling that value.
And it's really odd to have it set that high but the other values in sysfs
returning based on 512 instead of 4096
On Fri, Apr 1, 2016 at 2:38 PM, Scott Moser <email address hidden> wrote:
> It's worth trying to recommission the node. Sorry if this is noise. But
> axew in that same maas send to do fine.
>
> --
> You received this bug notification because you are subscribed to curtin.
> Matching subscriptions: curtin-bugs-all
> https://bugs.launchpad.net/bugs/1564977
>
> Title:
> ppc64el 1.9.1 tries and fails sgdisk on the wrong device
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/curtin/+bug/1564977/+subscriptions
>
In particular, it's at least worth seeing if the block devices are also 64k
block_size as well.
Looking at axew, I wonder what the curtin storage config looks like, I see
this for the inital partition creation:
['sgdisk', '--new', '1:2048:18431', '--typecode= 1:4100' , '/dev/sdd'] with
allowed return codes [0] (shell=False, capture=False)
which is a prep partition (type 4100) using 512b sectors (1M offset / 512)
== 2048
the end is 2048 + (8 * 1024 * 1024) / 512 - 1 sector)
2048 + (8388608 - 512) / 512
2048 + 16383
18431
And the second partition command:
previous partition number for 'sda-part2' found to be '1' 554272767' , 2:8300' , '/dev/sdd'] with allowed return codes [0]
adding partition 'sda-part2' to disk 'sda'
Running command ['sgdisk', '--new', '2:18432:
'--typecode=
(shell=False, capture=False)
This runs the same code which finds the previous partition, then reads size
and start from sysfs. It finds
the same 18431 ending sector, adds one and we start the new section with
18432.
On the failing node,
the default sector size is 4k, we take our 1M offset / 4096, and we get 256
on the offset.
But when calculating the second partition, somehow the logical_size is 512,
otherwise we'd
get a different starting sector.
18432 is correct for bs=512, but should be 2304 for 4k.
I confirmed the python math, /sys/block/ sde/queue/ logical_ block_size is
returning 4096
then our initial offset is:
alignment_offset = (1 << 20) / logical_ block_size_ bytes block_size_ bytes = 4096 block_size_ bytes
logical_
(1 << 20) / logical_
256.0
However, when we read /sys/block/ sde/sde1/ start
we're getting start=2048 size=16384, 18432
That's bizarre, and I'd think some sort of kernel bug unless there's some
setting that controlling that value.
And it's really odd to have it set that high but the other values in sysfs
returning based on 512 instead of 4096
On Fri, Apr 1, 2016 at 2:38 PM, Scott Moser <email address hidden> wrote:
> It's worth trying to recommission the node. Sorry if this is noise. But /bugs.launchpad .net/bugs/ 1564977 /bugs.launchpad .net/curtin/ +bug/1564977/ +subscriptions
> axew in that same maas send to do fine.
>
> --
> You received this bug notification because you are subscribed to curtin.
> Matching subscriptions: curtin-bugs-all
> https:/
>
> Title:
> ppc64el 1.9.1 tries and fails sgdisk on the wrong device
>
> To manage notifications about this bug go to:
> https:/
>