=== owlman_ is now known as owlman
=== gerald is now known as Guest186
=== swordsma- is now known as swordsmanz
=== chiluk` is now known as chiluk
=== ara is now known as Guest1907
[10:18] <genkgo> apw: i am really sorry to bother again, but i just wont succeed in installing cloud tools generic for 3.19. apt only wants to install 3.13 cloud tools. what ppa or source should i add to install this package http://packages.ubuntu.com/vivid/main/linux-cloud-tools-generic.
[10:18] <genkgo> the one i added now is ppa:canonical-kernel-team/ppa
[10:27] <infinity> genkgo: You're running utopic, right?
[10:27] <infinity> Err, trusty.
[10:28] <infinity> Brain not here.
[10:28] <apw> genkgo, yes they are deffo not well, i have submitted fixes for
[10:28] <infinity> genkgo: If you're running the lts-vivid kernel on trusty, you shouldn't be adding vivid sources to your sources.list.
[10:28] <genkgo> infinity: yes, i am running trusty with 3.19 (installed by ppa:canonical-kernel-team/ppa)
[10:29] <genkgo> apw: ok, so that means, at the moment I have to wait for the release of those fies, right?
[10:29] <genkgo> *fixes
[10:29] <infinity> One would think, with the current state of things, "apt-get install linux-cloud-tools-lts-vivid-generic linux-cloud-tools-common" would do the trick.
[10:29] <infinity> Or is that generic-lts-vivid?  Whatever.
[10:29]  * infinity looks.
[10:30] <rbasak> apw, smoser: could it be a udev hook somewhere that has a partition device file open in that case?
[10:30] <infinity> Yeah, linux-cloud-tools-generic-lts-vivid
[10:31] <genkgo> infinity: linux-cloud-tools-generic-lts-vivid : Depends: linux-cloud-tools-3.19.0-12-generic but it is not installable
[10:31] <genkgo> infinity: i guess that is what apw means with broken
[10:31] <infinity> Er, wat?
[10:31] <infinity> No, that's not what he meant by broken.
[10:31] <infinity> That's your sources.list being broken.
[10:31] <infinity> Since you should be at -17, not -12
[10:33] <genkgo> infinity: you are right
[10:33] <infinity> genkgo: If you have any vivid sources in your sources.list, you really shouldn't.  It should all be trusty.
[10:34] <genkgo> infinity: i removed the ppa:canonical-kernel-team/ppa before and replaced it with ppa:canonical-hwe-team/ppa to see what happened
[10:34] <genkgo> infinity: now I reverted it that
[10:34] <infinity> Bad things, I assume. :P
[10:34] <genkgo> and it will be installed
[10:35] <infinity> So, yeah.  You want linux-cloud-tools-generic-lts-vivid and linux-cloud-tools-common
[10:35] <infinity> The bug apw was referring to is that linux-cloud-tools-generic-lts-vivid doesn't depend on linux-cloud-tools-common, but installing it manually should work.
[10:35] <genkgo> infinity: what ppa should i use anyway? the hwe-team or the kernel-team? is there a difference?
[10:35] <infinity> genkgo: You shouldn't use either, ideally.
[10:36] <infinity> genkgo: But if you must use one, the kernel team's PPA is the source of goodness and light, and it's what feeds the Ubuntu archive.  The HWE PPA has no such guarantees.
[10:36] <genkgo> infinity: ok, i will use the kernel team then
[10:41] <genkgo> infinity: still things go wrong
[10:41] <genkgo> /var/cache/apt/archives/linux-cloud-tools-common_3.13.0-53.88_all.deb
[10:41] <genkgo> apt still tries to install some 3.13 packages 
[10:41] <infinity> genkgo: It's supposed to.
[10:42] <infinity> genkgo: 3.13 (or, rather, the master branch, which is 3.13 in trusty) provides the One True tools-common package.  Everything else is meant to depend on it.
[10:42] <infinity> genkgo: That's why I told you to explicitly install it, because tools-lts-vivid doesn't currently depend on it, like it should.
[10:43] <infinity> genkgo: If that's all that went wrong, then everything went right.
[10:43] <genkgo> infinity: ok :)
[10:46] <genkgo> cool, now my hyperv daemon are running
[10:46] <genkgo> daemons
[10:49] <genkgo> hmm, they were, i rebooted to see if they would start automatically
[10:52] <genkgo> apw: no i am back to where i was yesterday: my hv daemons are not running
[10:52] <genkgo> initctl list | grep hv is empty
[10:53] <genkgo> there is no /etc/init/hv*
[10:54] <infinity> genkgo: Did you at any point delete them by hand?
[10:54] <genkgo> nope
[10:54] <genkgo> infinity: i just feel my cloud tools generic is still not installed right
[10:54] <infinity> Are you positive?  Cause linux-cloud-tools-common ships them.
[10:54] <infinity> But they're conffiles.
[10:54] <infinity> So, if you delete them, they don't come back.
[10:55] <genkgo> infinity: i never deleted those files
[10:55] <infinity> genkgo: dpkg -l linux-cloud-tools-common && dpkg -L linux-cloud-tools-common
[10:55] <infinity> genkgo: pastebin those for me.
[11:08] <genkgo> infinity: dpkg-query: package 'linux-cloud-tools-common' is not installed
[11:08] <infinity> genkgo: ...
[11:08] <infinity> genkgo: apt-get install linux-cloud-tools-common
[11:08] <infinity> genkgo: That was the 3.13 package you complained about apt trying to install.  It really should be installed.
[11:09] <infinity> genkgo: Install it, verify that /etc/init/hv* are there, reboot, and rejoice.
[11:11] <genkgo> infinity: i just remove everything related to cloud tools, run sudo aptitude purge '~c', now my systems looks as follows http://paste.ubuntu.com/11129000/
[11:11] <genkgo> now i repeat the steps you told me
[11:11] <infinity> genkgo: Not sure why you did that, but okay...
[11:11] <genkgo> infinity: because I was pretty lost
[11:12] <infinity> genkgo: "apt-get install linux-cloud-tools-generic-lts-vivid linux-cloud-tools-common"
[11:12] <infinity> genkgo: That's all it should take.  Those two packages installed.
[11:12] <infinity> (And whatever deps they pull in)
[11:12] <genkgo> Errors were encountered while processing: /var/cache/apt/archives/linux-cloud-tools-common_3.13.0-53.88_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
[11:13] <genkgo> same as last time
[11:13] <infinity> I'll need more than that line.
[11:13] <genkgo> it just wont install
[11:13] <genkgo> trying to overwrite '/usr/share/man/man8/hv_kvp_daemon.8.gz', which is also in package linux-lts-vivid-cloud-tools-common 3.19.0-17.17~14.04.1
[11:13] <infinity> Ah-ha.
[11:13] <infinity> apw: Okay, remove my ACK from your patch.  Your lts packages are NOT empty. :P
[11:14] <infinity> apw: You need a Conflict/Replace on them from the master one.
[11:14] <infinity> genkgo: dpkg -i --force-overwrite /var/cache/apt/archives/linux-cloud-tools-common_3.13.0-53.88_all.deb
[11:14] <infinity> genkgo: Should get you going for now.
[11:14] <infinity> genkgo: We'll fix things up here for the next versions.
[11:14] <apw> infinity, bah what is in them
[11:14] <infinity> apw: Looks like manpages, at least.  See above.
[11:15] <apw> and the patch for those is right no?  it is linux which needs to fix them
[11:15] <infinity> apw: Your patch for lts-* is right, yes, just incomplete without also fixing master.
[11:15] <infinity> apw: In the same SRU cycle, being the important part.  So the upgrade is smooth.
[11:15] <apw> yep
[11:16] <apw> gotcha
[11:16] <genkgo> infinity: rebooted, and see the daemons running :)
[11:17] <genkgo> wonderful: now hopefully, 3.19 wont get my system in read-only during vss snapshot
[11:17] <genkgo> infinity: thanks a lot for the help
[11:18] <genkgo> apw: and of course your help too, much appreciated
[11:30] <genkgo> infinity: during boot i still see these message [storvsc] Sense Key : Illegal Request [current] and [storvsc] Add. Sense: Invalid command operation code.
[11:30] <genkgo> any idea what that means?
[11:31] <apw> genkgo, i think those are pretty normal on there
[11:32] <genkgo> apw: ok, thanks
[11:33] <genkgo> apw: just to be sure, my boot process also contains init: plymouth-upstart-bridge respawning too fast, stopped and scsi 3:7:1:1: scsi scan: INQUIRY result too short (5), using 36
[11:33] <genkgo> i just want to see as less errors as possible to just mitigate every possibility that it can cause the read-only problem
[11:38] <genkgo> hm  there is already a bug report for plymouth error: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1309617
[11:38] <ubot5> Ubuntu bug 1309617 in plymouth (Ubuntu) "plymouth-upstart-bridge main process (189) terminated with status 1 at boot" [Medium,Confirmed]
[11:39] <infinity> Yeah, the plymouth thing isn't anything to worry about.
[11:40] <apw> the inquiry too short is also common on those images
[11:42] <genkgo> apw infinity: ok i will stop worrying :) and just hope hyperv vss problems are resolved with the 3.19 kernel. i will report back to you, if you are interested
[11:43] <apw> infinity, ok those package _should_ be empty, but an interaction with another bug fix has made them contain something .... bah
[11:43] <apw> infinity, so at least i know why now ...
[11:44] <infinity> apw: Ahh, well.  Comedy of errors.  Keeps us employed, right? :P
[11:44] <apw> infinity, yeah i guess it does that ... 
[11:44] <infinity> apw: Just make common Conflicts/Replaces lts-{utopic,vivid}-common, and life's good.
[11:45] <apw> infinity, and i am going to fix the bug that prevents the packages being empty like they should have been, ie preventing puking lots of errors about unknow packages
[13:33] <smoser> apw, http://paste.ubuntu.com/11130592/
[13:33] <smoser> does that seem sane? as i'm seeing failures in it.
[13:59] <apw> smoser, what failure are you seeing with it though
[14:03] <smoser> BLKRRPART: Device or resource busy
[14:03] <smoser> failed[1]: ptwrite/blockdev: partition 1
[14:03] <smoser> [90432.37]
[14:04] <smoser> more commonly i think i'm seeing the partition 2 blockdev failing
[14:04] <smoser> but that one just failed
[14:04] <smoser> it runs seemingly forever on utopic
[14:04] <smoser> i'm pretty sure its udev thats letting go early.
[14:08] <rbasak> smoser: just been looking at the udev source. I'm pretty sure it's racy. Not sure if what we're trying to do is supported behaviour.
[14:09] <rbasak> I believe there's a race in that "udevadm settle" can return before udevd sees an event that the kernel has queued.
[14:10] <smoser> rbasak, continue in #ubuntu-server. apw you too if interested. as strikov and i talking there too.
[14:10] <rbasak> ack
[14:10] <apw> smoser, right that just tells you you oculdn't change the partitiont table because one of the parititons was busy
[14:11] <smoser> apw, right.
[15:23] <cmagina> question: what is the best way to get an upstream commit cherry-picked into an ubuntu kernel version? i have a couple upstream commits with SRU bugs already created in lp, one I submitted a request-pull for, but that doesn't seem like the correct way to handle this.
[15:29] <apw> cmagina, submitting them to the kernel-team@ list is the right way to do it
[15:30] <cmagina> apw: is there any special format for that e-mail? i've been using request-pull for my own submissions, but those are modified upstream commits or applied patches type deal
[15:31]  * cmagina just submitted an upstream commit in that manner, thus the question of how i should do this properly :)
[15:32] <apw> i'd just send the upstream patch from format-patch
[15:32] <cmagina> ok
[15:32] <cmagina> thanks
=== pgraner is now known as pgraner-lunch
=== pgraner-lunch is now known as pgraner
=== pgraner is now known as pgraner-afk