Comment 7 for bug 1564977

Revision history for this message
Ryan Harper (raharper) wrote : Re: [Bug 1564977] Re: ppc64el 1.9.1 tries and fails sgdisk on the wrong device

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'
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:

alignment_offset = (1 << 20) / logical_block_size_bytes
logical_block_size_bytes = 4096
(1 << 20) / logical_block_size_bytes
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
> 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
>