[01:38] <smoser> hm..
[01:38] <smoser> anyone still awake?
[01:39] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977
[01:39] <ubot2> Launchpad bug 1061977 in cloud-init "Machine fails to commission when console=ttyS0 is present on kernel opts" [Undecided,New]
[02:02] <smoser> smb`, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977 . i'd appreciate your input when you awake.
[02:02] <ubot2> Launchpad bug 1061977 in cloud-init "Machine fails to commission when console=ttyS0 is present on kernel opts" [Undecided,New]
[07:55] <rbasak> ikepanhc: around? May I have some help compiling a test highbank kernel please? With "fakeroot debian/rules binary-highbank" (cross compile), I get this: http://paste.ubuntu.com/1261463/ . A zImage does exist but it doesn't seem to work. How should I be building test kernels instead?
[07:56]  * ikepanhc reads
[07:57] <ikepanhc> rbasak: do you `fakeroot debian/rules clean` before fdr binary-highbank?
[07:57] <ikepanhc> `fdr clean` will generate changelog, control in debian folder
[07:57] <rbasak> ikepanhc: when I tried that it wouldn't even start a build. I'll do that now and paste the error.
[07:58] <ikepanhc> rbasak: you using cross-compiler?
[07:58] <rbasak> ikepanhc: yes
[07:59] <ikepanhc> rbasak: try `export $(dpkg-architecture -aarmhf)` then `fdr clean` then `CROSS_COMPILE=<toolchain prefix> fdr binary-highbank`
[08:00] <ikepanhc> alias fdr="fakeroot debian/rules" first
[08:00] <rbasak> Hmm.
[08:00] <rbasak> It seems to be working now
[08:00] <rbasak> I swear I got an error doing the clean step first yesterday
[08:01] <rbasak> So I tried using git clean only instead
[08:02] <ikepanhc> fdr clean is not only to clean those objects, but also generate control and changelog which we need for make
[08:02] <rbasak> I see
[08:03]  * rbasak waits for the build to finish
[08:58]  * ppisati needs to go out for ~30mins, brb
[11:17] <apw> henrix is having ISP issues
[11:43] <psivaa> when i run ubuntu-bug linux today, it's reports 'Problem in linux-image-3.5.0-16-generic
[11:43] <psivaa> The problem cannot be reported
[11:44] <psivaa> This is not an official Ubuntu package. Please remove any third party package and try again'
[11:44] <psivaa> message box is popping up
[11:47] <psivaa> this is a fresh install btw
[12:18]  * rtg thinks that was quite a large update for barely being post beta
[13:06] <smoser> smb, around ?
[13:07] <smb> smoser, yup
[13:07] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977
[13:07] <ubot2> Launchpad bug 1061977 in cloud-init "Machine fails to commission when console=ttyS0 is present on kernel opts" [Undecided,New]
[13:07] <smoser> you have any thoughts there?
[13:08] <smoser> i would really rather not take 'console=ttyS0' off the cmdline (as I really want output there by default rather than to any graphical console which has no chance of being logged), but that is about the only option i see.
[13:08]  * rtg uploaded  linux-lts-quantal 25 hours ago and it _just_ started building.
[13:09] <smb> smoser, well my first thought was that the first pastebin does not look like console output
[13:09] <smoser> smb, on random other note, i know in your cloud-images testing you've had to add ways to get into an image, and that is more involved than you'd like.
[13:09] <smoser> i put together http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/backdoor-image
[13:10] <smoser> that basically can mount an image, inject a user into it and then unmount it in one command. 
[13:10] <smoser> smb which pastebin ?
[13:10] <smb> smoser, By now I have made my scripts add a nocloud file for newer releaes
[13:11] <smoser> its not console output, its cloud-init output. he couldn't get console output as it is going to a video console.
[13:11] <smb> smoser, http://paste.ubuntu.com/1261109/ shows the cloud-init log.
[13:11] <smoser> oh, for "nocloud" there is a util in cloud-utils called 'cloud-localds' that will basically do it also.
[13:12] <smoser> this one actually modifies the image to add the user, so cloud-init isnt involved/required at all
[13:13] <smoser> let me see if i can get it, smb, but its not really important. (the output of running it)
[13:13] <smoser> it fails
[13:13] <smoser> and 'echo "hi" | sudo tee /dev/console' fails also
[13:13] <smoser> the issue is /dev/console writes fail
[13:13] <smoser> which causes all sorts of stuff to be unhappy
[13:14] <smb> smoser, I think I saw something for this nocloud thing and at least at that point in time it was still too complicated to get working. Still having run some of the cloud init code is usefull to find problems, so this is what gets done right now.
[13:15] <smb> smoser, Yeah I think it probably makes sense to move some of the info from later comments into the description. I think I just stopped somewhere at the top as I could not really guess what you/the report is up to
[13:17] <smoser> smb, well, run 'cloud-localds' it gives a full example of booting an image even.  iss simple for 12.04+.
[13:17] <smb> smoser, So for the question: as far as I remember everytime you do a console= the kernel assigns a console device, just the last one I believe is a bit different as there is one sort of preferred console
[13:17] <smoser> smb, well, comment 4 has just about everything you need.
[13:17] <smb> smoser, You assume I care to read that far
[13:18] <smoser> no, I SAY YOU CARE!
[13:18] <smoser> :)
[13:18] <smb> You *hope*
[13:18] <smoser> if you' dlike i can move the explanation up to the description.
[13:18] <smb> :)
[13:18] <smoser> but anwya.
[13:18] <smoser> yeah, each 'console=' ends up receiving kernel printk
[13:18] <smoser> which is good.
[13:19] <smoser> and it is good that 'console=ttyS0' when there is no serial device present does not stop the kernel from booting.
[13:19] <smoser> however.
[13:19] <smoser> the final console= parameter gets assigned to /dev/console
[13:19] <smoser> and init writes output to /dev/console, and cloud-init inherits that as its stdout
[13:19] <smb> the preferred console thing, yeah
[13:19] <smoser> and any writes to stdout then fail
[13:20] <smoser> which can cause problems :)
[13:20] <smoser> what i had *thought* (apparently wrong) the kernel did was assign /dev/console to the last *good* console= on the cmdline.
[13:20] <smoser> but i guess it only makes intelligent decisions if you give no console=
[13:21] <smoser> otherwise it does exactly what you tell it to do.
[13:21] <smoser> the basic problem is, then:
[13:21] <smb> Not sure it makes any great decisions on its own. 
[13:21] <smoser>  * if there is a serial device, i want output to go there (including /dev/console)
[13:22] <smoser>  * if there is no serial device, i would rather writes to /dev/console not give IO error.
[13:22] <smoser> smb, well  http://www.kernel.org/doc/Documentation/serial-console.txt says "If no console device is specified, the first device found capable of acting as a system console will be used."
[13:23] <smoser> "At this time, the system first looks for a VGA card and then for a serial port. So if you don't have a VGA card in your system the first serial port will automatically become the console."
[13:23] <smoser> i'd really just like that order switched.
[13:24] <smoser> and i kind of thought that is what i was getting by adding multiple console=. but i guess not.
[13:24] <smoser> so i think i understand the issue, and i'm just bothering you in a hope that you know something i do not.
[13:24] <smoser> and you can come up with a solution
[13:24] <smoser> and i have not read any kernel code, only doc.
[13:24] <smb> smoser, Really you want a decision about something the kernel does not know until it finds out done before it can find out. And then you cannot say if there is a serial port whether it is a serial console. So normal boot might siddenly go wrong
[13:24] <phillw> hi good people, I'm sorry to say that my suggested patch from RedHat does not seem to work on all Nvidia chipsets. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1043518 As the RC is up coming. PPC needs a bit of help. Arguing with 'X' does not solve the issue, it is a kernel change that was undertaken and has serious regression issues. My ask? please make it work, the PPC people are runnning around getting patches in. the kernel is where 
[13:24] <ubot2> Launchpad bug 1043518 in linux "live cd is unusable due to video degradation with the splash boot option enabled" [High,Fix released]
[13:25] <smoser> smb, right. i know its tricky.
[13:25] <smoser> but the doc says it already does such trickyness.
[13:25] <smoser> if you dont pass any console=
[13:26] <smoser> smb, the other option i considered was that I could have the initramfs notice that /dev/console was busted and "fix it". 
[13:26] <smb> Yeah, using a VGA (compatible) card which really is there most of the time and then try on serial (just in case)
[13:26] <smoser> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg246433.html discusses changing it
[13:26] <smoser> but i dont think it really seems to work.
[13:26] <smoser> at least it wasn't extremely simple to change the target device of /dev/console
[13:29] <smb> smoser, I think that part of the kernel "suffers" from not needing much special cleverness as long as you stick to a certain architecture. And it gets even more complicated when there are things like grub in between passing some information or setting up stuff
[13:29] <smoser> well, in this case the thing thats pasin the cmdline is pxe boot
[13:30] <smoser> and i really, *really* want a "one set reasonably fits all" solution.
[13:30] <smoser> as on the first pxe boot of a node, i know zero information about that node.
[13:30] <smoser> s/pasin/passed in/
[13:31] <smb> Yeah, I understand the issue. (btw grub seems to do the passing not by cmdline but directly transferring some structure). I just don't think it will be an easy solution.
[13:32] <smoser> smb, well, could you at least read a bit and see if there is a way i could change /dev/console during initramfs ?
[13:32] <smoser> that'd be sufficient for me, if i could recognize its busted and poke around to fix it.
[13:33] <smoser> before /sbin/init came up.
[13:34] <smoser> then, my solution would be to just do what i'm doing (multiple console= parms) and have initramfs walk them backwards until it finds one that does not give io error.
[13:34] <smoser> and then fix to that.
[13:35] <smb> smoser, I put it on my list but I cannot really say when I get to it. There are enough other things broken that take up time.
[13:36] <smoser> smb, well, at least read that thread on lkml, and tell me if it looks like it is possible or not.
[13:36] <smoser> because i came away with "um... maybe"
[14:15] <diwic> I'm trying to track down a regression between two ubuntu kernels, what's the easiest way to see what patches there are between two kernel versions?
[14:16] <henrix> diwic: git log?
[14:16] <rtg> diwic, it also depends on whether there has been a rebase between them.
[14:17] <diwic> the person claims "3.2.0.31" is not working and "3.2.0.30" is.
[14:18] <rtg> diwic, vanilla stable is linear. git log -p v3.2.0.30..v3.2.0.31
[14:19] <rtg> you can also restrict your search to just sound, e.g., 'git log -p v3.2.0.30..v3.2.0.31 -- sound'
[14:19] <diwic> rtg, should that be working on a precise tree? I get "unkown revision or path not in working tree"
[14:19] <rtg> diwic, lemme check
[14:20] <smb> smoser, Hm, *if* it is correct, I would think that it only will work when the current /dev/console driver is a pty. Which would need the console=tty0 last. And there can only be one re-assignment active and not sure whether it can be done when upstart already has changed its stdin and out there.
[14:20] <smoser> yeah. oh well.
[14:20] <rtg> diwic, oh, likely not since stables patches are rebased onto ubnutu. clone the real stable repo at git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
[14:20] <smoser> thanks for reading, smb. thanks for your time.
[14:20] <rtg> s/are/are not/
[14:22] <rtg> diwic, hmm, you're talking about Ubuntu versions, not stable versions, right ? i.e., Ubuntu-3.2.0-30.48
[14:23] <diwic> rtg, okay, so replacing v3.2.0 with Ubuntu tags should do it
[14:23] <diwic> Sometimes you just get unsure of what a command really does
[14:24] <rtg> so then you can get a list of patches by doing 'git log --reverse -p Ubuntu-3.2.0-30.48..Ubuntu-3.2.0-31.49'
[14:24] <rtg> diwic, you can also look in the changelog
[14:25] <diwic> hmm, it seems there are no relevant patches in the sound directory that could have caused this error AFAICS
[14:26] <diwic> I'm reassinging it to the linux package and let someone of you bisect it, chances are it's something completely unrelated
[14:27] <rtg> diwic, make sure jsalisbury is aware of the bug number. note that he's out today.
[14:28] <diwic> rtg, ack
[14:29]  * henrix -> brb
[15:24]  * henrix -> out for ~20mins
[15:38] <sconklin> apw: what triggers the CVE tracker to move a CVE from "triage needed"? I've looked at 1012-4467 and updated the break-fix. Do I need to nudge it in any other way?
[15:50] <hallyn> hi - bug 1057024, last comment - those messages about /dev/sda, are they serious?  serious enough to disregard other bugs from that system (when they can't be reproduced elsewhere)?
[15:50] <ubot2> Launchpad bug 1057024 in libvirt "internal error Process exited while reading console log output: char device redirected to /dev/pts/1 error when creating a vm" [High,Confirmed] https://launchpad.net/bugs/1057024
[15:51] <apw> sconklin, if its pushed to kernel it should be found in an hour sort of thing
[15:51] <hallyn> smb: ^ do you mind taking a quick look?
[15:51] <smb> hallyn, just opening
[15:51] <hallyn> thx!
[15:52] <apw> sconklin, the processing kicks off at :20 and if there is a change can take some time, when did you do the update
[15:53] <hallyn> (note the msgs go on, you can see more in the dmesg file in the tar.gz she appended)
[15:53] <smb> hallyn, serious in the sense that a write failed. not much more info info that piece of output. 
[15:53] <smb> hallyn, Let me check the full log
[15:54] <hallyn> smb: thanks.  (i also see kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround)
[15:55] <smb> hallyn, I think I see that in some of my machines too. Without any apparent effect. I would say it *does* us a work-around. :)
[15:57] <hallyn> smb: ok, thanks.  just making sure
[16:02] <smb> hallyn, But yeah, there seems to be quite a bit of trouble with that disk. Might be worth trying to check all cabling and maybe trying to limit the speed to 1.5G...
[16:04] <hallyn> smb: i think it's a laptop
[16:05] <smb> hallyn, Ok harder to check cables. But something is wrong even before
[16:05] <smb> [  975.481263] ata1.00: exception Emask 0x0 SAct 0x3f SErr 0x0 action 0x6 frozen
[16:05] <smb> [  975.481274] ata1.00: failed command: WRITE FPDMA QUEUED
[16:05] <sconklin> apw: I did the update around 30-40 mins ago I think
[16:06] <apw> so perhaps just missed it
[16:06] <apw> worst case delay
[16:06] <sconklin> probably. no worries, I'll wait
[16:06] <apw> bzr: ERROR: Invalid http response for https://xmlrpc.launchpad.net/bazaar/: Unable to handle http code 502: Bad Gateway
[16:06] <apw> or perhaps something bad happened
[16:07] <apw> i'll watch it for the next run
[16:07] <apw> is bzr down for maintenance perhaps
[16:08] <ogasawara> apw: I was hearing grumbling recently within the hour about LP issues
[16:08] <apw> could be that too
[16:10] <ogasawara> apw: in other news, I'm discovering that in order to use the --include-removal flag for packaging, we have to change our debian/source/format to 3.0 (quilt)
[16:11] <apw> ogasawara, thats not going to work well for us, as we have debian.* outside our debian directory
[16:11] <ogasawara> apw: yep, I'd then have to shove an --auto-commit flag in there as well, or it vomits because of that fact
[16:12] <hallyn> smb: dunno what that means
[16:12] <apw> ogasawara, i wish we had chose debian/branch not debian.branch ... with hindsight
[16:12] <smb> hallyn, Don't know in detail but looks like some dma write timed out
[16:13] <apw> apw@dm:~/git2/ubuntu-quantal$ cat debian/debian.env 
[16:13] <apw> DEBIAN=debian.master
[16:13] <apw> though as its encoded that way we ought to be able to move it, yeah right
[16:13] <apw> something to talk about at uds in teh bar
[16:13] <ogasawara> apw: indeed.  I think its harmless for now for us to leave things as they are for now.  that highbank clock.c file is never used, and the redundant firmware is not a huge issu
[16:14] <apw> its not ending up in the binaries which is mostly what we care about
[16:14]  * ppisati -> gym
[16:15] <smb> hallyn, Just one other note that apw recently had to reboot to get virt-manager working. We have not really found why that was
[16:16] <apw> indeed, logging out and in was not enough for sure
[16:16] <apw> as i tried that before giving up and doing a windoze on it
[16:17] <hallyn> smb: after installing libvirtd, you do have to log out and back in to be in the libvirtd group (or run newgrp).  had he tried that first?
[16:17] <hallyn> a reboot would of course effect the same thing :)
[16:17] <apw> yes logging out and in changed nothing
[16:17] <smb> hallyn, Yep.
[16:17] <hallyn> apw: hm
[16:17] <apw> i know i was pissed
[16:17] <smb> apw, Did you not also have the complaint about not being able to load the kvm module (though it was loaded)
[16:18] <hallyn> apw: can you reproduce that?  i've been doing these tests for awhile the last two days and haven't seen that
[16:18] <apw> that rings a bell but you test my memory
[16:18] <hallyn> so if you can reproduce, can you give as much detail as possible?
[16:18] <hallyn> apw: oh, hey, did you install kvm *after* installing libvirt by chance?
[16:18] <apw> hallyn, very possible yes
[16:20] <smb> hallyn, While I usually go for "apt-get install virt-host^" which takes care of those details
[16:20] <apw> i think i assumed kvm would be a dependancy
[16:20] <apw> though thinking about it clearly it will not be
[16:20] <apw> so i think i did do them in that order
[16:20] <hallyn> apw: ok, then that makes sense.  and iiuc 'restart libvirt-bin' wouldn't even work, you'd have to 'stop libvirt-bin; start libvirt-bin' to get it to work
[16:21] <apw> that i wouldn't have tried indeed
[16:21]  * smb cannot remember whether we tried the one or the other
[16:22] <apw> sconklin, this is not the right format:
[16:22] <apw>  break-fix: 644595f89620ba8446cc555be336d24a34464950 - ed6fe9d614fc1bca95eb8c0ccd0e92db00ef9d5d
[16:22] <apw> its a two field thing
[16:22] <sconklin> huh, ok. I copied what I found in another file.
[16:23] <sconklin> Oh wait. I'll bet the '-' was a placeholder for a nonexistent break
[16:23] <sconklin> I'll fic it
[16:25] <hallyn> perhaps upstart should warn you when it knows 'restart' won't restart
[16:26] <smb> Maybe restart should restart
[16:27] <sconklin> apw: pushed. Now we wait another cycle. I have to run a quick errand anyway
[17:19]  * apw is about done ...
[19:43]  * rtg -> EOW