[12:57] <smoser> utlemming, could you on that bug also verify yakkety and zesty ?
=== rangerpbzzzz is now known as rangerpb
[14:13] <utlemming> smoser: done
[14:43] <smoser> thanks
[15:28] <smoser> blackboxsw, if you're wanting something to do before rharper comes around https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323420
[15:29] <smoser> id' like your input there
[15:29] <blackboxsw> looking now. just SRU-ing have some interesting questions on nova-lxd creation from lxc image export .
[15:30] <smoser> ok. if you want to chat, we coudl do that to wait also :)
[15:30] <blackboxsw> I'm just hanging out in the standup channel
[15:30] <blackboxsw> for whenever rharper and smoser join
[15:31] <smoser> k
[15:34] <rharper> smoser: in the standup now
[15:35] <smoser> joiing
[15:35] <smoser> 2 min
[15:38] <rharper> it's now 3 minutes past ...
[15:38] <rharper> =P
[15:41] <blackboxsw> ack he hid that from comments so it's no longer public
[15:41] <blackboxsw> just a heads up on that it was "released" to people who subscrived to the bug
[16:00] <mikec_64> is it possible to prevent an ssh authorized key from being added to root?  I only want the key added to the normal user
[16:54] <rharper> AFAICT no ssh keys are added to root; but we'd need to see the user-data
[16:55] <rharper> ssh-import-id or other ssh key settings are done against the 'default' user;  in ubuntu images, this is the user ubuntu
[16:55] <rharper> ubuntu user is also in the sudo group, so one can get root on the instance but it won't append ssh keys to the root user
[16:55] <rharper> mikec_64: ^^
[17:58] <smoser> mikec_64, well, cloud-init adds the keys to root, but does so with a command that says 'hey, log in with other user'
[17:58] <smoser> end result is that you cannot log in as root with those keys.
[18:06] <mikec_64> ahh the issue I am running into is that puppet does not like keys that have the exact same content & name
[18:07] <mikec_64> I am changing my puppet setup to disallow root login and then just skip managing the root user
[18:08] <rharper> smoser: huh, I didn't know that
[18:11] <smoser> $ ssh root@10.5.0.12
[18:11] <smoser> Warning: Permanently added '10.5.0.12' (ECDSA) to the list of known hosts.
[18:11] <smoser> Please login as the user "ubuntu" rather than the user "root".
[18:11] <smoser> Connection to 10.5.0.12 closed.
[18:12] <smoser> http://paste.ubuntu.com/24562286/
[18:13] <smoser> rharper, can you mark 'approved' on the azure mp ? https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323420
[18:13] <smoser> and give me links to anything you want me to look at right now
[18:13] <rharper> smoser: I can. but one item I asked about was the extra os.path.realpaths()
[18:15] <smoser> yeah... the callers will all have 'realpath' already resolved.
[18:26] <rharper> ack
[19:47] <blackboxsw> whew, finally down to the last xenial, yakkety zesty sru verification https://bugs.launchpad.net/cloud-init/+bug/1684869
[19:47] <ubot5> Ubuntu bug 1684869 in cloud-init "growing root partition does not always work with root=PARTUUID=" [Medium,Confirmed]
[20:14] <smoser> blackboxsw, \o/
[20:14] <smoser> thank you!
[20:52] <blackboxsw> smoser: so I'm on the last one
[20:52] <blackboxsw> xenial of the above mentioned bug
[20:52] <blackboxsw> aw=xenial-server-cloudimg-amd64-proposed.img
[20:52] <blackboxsw> csmith@fringe:~$  ptuuid=$(sfdisk --part-uuid $raw 1)
[20:52] <blackboxsw> sfdisk: xenial-server-cloudimg-amd64-proposed.img: no partition table found
[20:52] <blackboxsw> sfdisk worked for both yakkety and zesty raws
[20:54] <blackboxsw>  file $raw
[20:54] <blackboxsw> xenial-server-cloudimg-amd64-proposed.img: QEMU QCOW Image (v3), has backing file (path xenial-server-cloudimg-amd64.raw), 2361393152 bytes
[20:55] <rharper> v3 ?
[20:55] <blackboxsw> strange as zesty is zesty-server-cloudimg-amd64.raw: DOS/MBR boot sector, extended partition table (last)
[20:55] <blackboxsw> same w/ yakkety
[20:56] <rharper> file says that everywhere , strange
[20:56] <rharper> so, so you have a backed image
[20:56] <blackboxsw> whoops
[20:57] <blackboxsw> bah
[20:57] <rharper> basically someone built a qcow file on top of the original
[20:57] <rharper> for proposed, which makes sense
[20:57] <blackboxsw> I grabbed xenial-server-cloudimg-amd64-proposed.img instead of xenial--server-cloudimg-amd64.raw
[20:57] <rharper> ah
[20:57] <rharper> there you go
[20:57] <blackboxsw> PEBKAC
[20:57] <rharper> it's Friday
[20:57] <blackboxsw> not for loooooong ;)
[21:01] <rharper> LOL
[21:01]  * rharper checks watch
[21:01] <rharper> hrm, looking a lot like beer-thirty
[21:18] <blackboxsw> hmm yeak just confirming, same issue w/ the raw file
[21:19] <blackboxsw> https://www.irccloud.com/pastebin/Xilq7ov2/
[21:19] <blackboxsw> something xenial specific it seems
[21:25] <blackboxsw> the xenial image doesn't have an extended partition table definition like the zesty and yakkety raw images
[21:26] <rharper> hrm
[21:27] <rharper> oh, that's because it's not GPT based
[21:27] <rharper> yakkety and newer are unified (uefi + legacy)
[21:27] <rharper> which requires GPT (uefi does)
[21:27] <rharper> not sure why the zesty image showed msdos though
[21:32] <rharper> blackboxsw: yeah, yak and zesty have GPT based partitions, xenial has ms/dos ;  I think that;s the difference
[21:34] <rharper> blackboxsw: you may need to use blkid -o export on a kpartx mounted image file
[21:35] <rharper> sudo kpartx -va path/to/image; (will print which mapper device) then you can sudo blkid -o export /dev/mapper/loopNp1
[21:35] <rharper> it should print a PARTUUID= value
[21:39] <blackboxsw> thanks rharper. til about kpartx hadn't used it before
[21:39] <rharper> yeah, so -va (verbose add) and -vd (verbose delete) are most helpful
[21:39] <rharper> especially with dealing with GPT images which have 2 partitions which you can't mount before your get to the rootfs
[21:40] <rharper> it just reads pt , calculates offsets and auto configures a loop devivce with the offsets
[21:40] <rharper> helps for LVM devices as well
[22:21] <blackboxsw> ok yakkety and zesty are done. xenial is a bit locked up because I don't know the qemu foo to get and boot off the xenial partition