[14:10] <Odd_Bloke> smoser: I'm looking at switching MBR disk setup to use sectors (rather than MB), because sfdisk in wily has dropped support for units other than sectors.
[14:11] <smoser> yes please.
[14:11] <Odd_Bloke> smoser: How would you suggest I test this?  I've done [33, [66, 82]], which is the canonical example we use.
[14:11] <Odd_Bloke> But I don't really know what corner cases we might have that I should look at.
[14:11] <smoser> mainly i think you dont have to care.
[14:11] <smoser> CHS is garbage.
[14:12] <smoser> thats waht you're asking about, right?
[14:12] <smoser> what did '33, 66, 82' mean ?
[14:13] <Odd_Bloke> smoser: No, at the moment we do (essentially) 'cat <list of partitions> | sfdisk -uM <device>'.
[14:13] <Odd_Bloke> smoser: But sfdisk no longer supports megabytes as units, so I'm switching to using sectors as the units.
[14:13] <Odd_Bloke> smoser: This is https://bugs.launchpad.net/cloud-init/+bug/1460715
[14:14] <smoser> ah. ok.
[14:14] <smoser> what did you mean 33, 66, 82 ?
[14:14] <Odd_Bloke> smoser: So I've tested using 'layout: [33, [66, 82]' (i.e. one-third ext4, two-thirds swap), but I don't really know what else to try to check that it works in practice.
[14:19] <smoser> Odd_Bloke, ok. now reading code and understand more.
[14:20] <smoser> well you basically have to turn everything into sectors.
[14:20] <smoser> now, to deal with sfdisk
[14:21] <Odd_Bloke> smoser: Yeah, it's actually surprisingly painless.
[14:21] <Odd_Bloke> smoser: I've got a branch prepped, I'm just trying to test it before pushing it up for review.
[14:21] <smoser> i've never really used that code.
[14:22] <smoser> in the future the plan is to support the disk layout settings taht curtin can do.
[14:22] <Odd_Bloke> smoser: OK, I'll just push this up for review then.
[14:22] <Odd_Bloke> I've done some basic testing.
[14:40] <Odd_Bloke> smoser: That's https://code.launchpad.net/~daniel-thewatkins/cloud-init/lp1460715/+merge/274897
[14:41] <smoser> Odd_Bloke, it'd be good to know if this code runs on old sfdisk
[14:42] <Odd_Bloke> smoser: Ah, good point.
[14:55] <Odd_Bloke> smoser: The existing trusty code doesn't work even without my changes. /o\
[14:56] <Odd_Bloke> Ah, I'm hitting https://bugs.launchpad.net/cloud-init/+bug/1311463.
[14:59] <smoser> Odd_Bloke, added a review
[15:06] <Odd_Bloke> smoser: Thanks!  Replied to the inline comment.
[15:07] <smoser> i've always been confused by sfdisk also
[15:08] <smoser> lets find the real ansewr.
[15:08] <smoser> but i suspect it is 512
[15:09] <Odd_Bloke> smoser: I've been poking around in that code; let me have a dig before you switch to this.
[15:09] <Odd_Bloke> (As in, I've been poking in the sfdisk code)
[15:10] <smoser> reading http://karelzak.blogspot.com/2014/10/new-sfdisk.html
[15:12] <Odd_Bloke> smoser: So my code doesn't backport to trusty nicely, because old 'sfdisk -l' output is different.
[15:13] <smoser> yeah. i'm aware of such pain .
[15:13] <smoser> from growpart
[15:13] <smoser> it does support both. but its a pita
[15:14] <smoser> http://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/view/head:/bin/growpart
[15:14] <smoser> Odd_Bloke, the thing is that if we update to only supporting new, then anyone who picks this up is busted on old sfdisk
[15:15] <smoser> in growpart, SFDISK_VERSION madness.
[15:16] <Odd_Bloke> smoser: ;.;
[15:19] <Odd_Bloke> smoser: So libfdisk definitely supports variable sector sizes; I don't know if we'd ever see them in practice.
[15:20] <smoser> but then its not clear to me if it woudl be used anyway.
[15:20] <smoser> logical sector size versus physical sector size
[15:22] <Odd_Bloke> smoser: Right.
[15:22] <Odd_Bloke> smoser: I have a meeting coming up, but I'll pick this up after that.
[16:56] <smoser> Odd_Bloke, so.
[16:56] <smoser> through some experimentation, i can verify that sfdisk uses 512 byte sectors
[16:59] <Odd_Bloke> smoser: You're sure we won't hit funky hardware somewhere where it doesn't?
[16:59] <smoser> i dont think so
[16:59] <smoser> http://paste.ubuntu.com/12863364/
[17:00] <smoser> Odd_Bloke, ^ that boots a guest with 4096 physical size and 512 logical (interestingly, it wont boot if you set logical to 4096).
[17:01] <smoser> verified that the kernel says my physical size is 4096
[17:01] <smoser> and that size reported (in your 'sfdisk --list') is in 512
[17:12] <smoser> Odd_Bloke,  http://paste.ubuntu.com/12863544/
[17:16] <harlowja> smoser https://github.com/openstack/cloud-init
[17:16] <harlowja> guess now cloud-init == openstack
[17:16] <harlowja> lol
[17:17] <harlowja> Odd_Bloke ^  claudiupopa
[17:17] <smoser> oh well. it is. as it is.
[17:17] <harlowja> :-P
[17:17] <natorious> oh wow
[17:17] <natorious> did they merge the stackforge org into openstack?
[17:17] <natorious> I suppose
[17:17] <harlowja> yup
[17:17] <harlowja> stackforge gone...
[17:18] <harlowja> and/or retired
[17:18] <natorious> fwiw, I report cloud-init hours worked as openstack dev hours
[17:18] <harlowja> nice
[17:18] <harlowja> well now u can do that without feeling bad, ha
[17:19] <natorious> lol, no bad feelings here :P
[17:19] <Odd_Bloke> smoser: So looking at the util-linux code; sector size defaults to 512, but it does do an 'ioctl(fd, BLKSSZGET, sector_size)' call to actually query the device (https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/lib/blkdev.c#n193).
[17:20] <Odd_Bloke> smoser: But that does mean that a `blockdev --getss $DEVICE` is definitely going to return the same answer, which would save on parsing sfdisk output.
[17:21] <Odd_Bloke> Let me check that makes sense on trusty.
[17:50] <smoser> ok. i'm wrong
[17:50] <smoser> http://paste.ubuntu.com/12864078/
[17:51] <smoser> your'e right about blockdev --getss
[17:51] <smoser> but i think thats the same as woudl be returned by *logical*
[17:52] <smoser> http://paste.ubuntu.com/12864114/
[17:52] <smoser> ^--
[17:53] <smoser> so reading logical in sys shoudl give you what sfdisk does.
[17:53] <smoser> i managed to create a device with 4096 logical
[17:54] <smoser> so ... sfdisk uses logical sectors. not physical sectors.