[01:06] <mdz> bjf[afk], I think this script may be getting false positives: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904025/comments/2
[01:06] <ubot2> Launchpad bug 904025 in linux "lxc-start intermittently fails" [Undecided,Incomplete]
[01:06] <mdz> AFAIK there's nothing apport-collect would add which isn't already on that bug
[04:50] <RAOF> Bah!  Is aufs deliberately gone from the Precise kernel?
[04:51] <ohsix> wasn't it out of tree anyways? afaik it was used a long time ago to try upgrades but that hasn't worked since 9.10 or something
[04:51] <RAOF> Well, it's been the default overlay filesystem forever; schroot uses it.
[04:52] <stgraber> RAOF: yeah, my understanding is that we had both aufs and overlayfs in Oneiric with overlayfs being the default for the live environment, now in Precise aufs has been dropped completely
[04:52] <ohsix> yea it's still out of tree
[04:53] <stgraber> RAOF: "forever" being not that long ago ;) I can quite clearly remember unionfs :)
[04:53] <RAOF> Ah.  That's unfortunate.  It seems that overlayfs doesn't support hardlinks in the same way that aufs does, and so mesa no longer builds in my sbuilder.  Hawkward.
[04:55] <stgraber> RAOF: I know we found some overlayfs weirdness at the release sprint (inotify not working as it should) which was a kernel bug, you may want to check with the kernel guys if what you see is a difference in behaviour or a bug that'd need fixing
[04:55] <RAOF> stgraber: Yeah, I guess that's the next step.
[04:59] <ohsix> anyone know why aufs was rejected anyways? were there concerns about proliferation or something?
[05:07] <bucky> I'm trying to compile a patched kernel with fakeroot make-kpkg and it dies with "dpkg-gencontrol: error: package linux-image-2.6.17-om not in control info", how can I get around this?
[05:08] <ohsix> it doesn't know what to do with that EXTRAVERSION, i think
[05:08] <bucky> right
[05:09] <ohsix> the debian/control and debian/* in general has all the metafiles that control the build process, and they're text
[05:09] <bucky> I edited the debian/control file
[05:09] <ohsix> you might get away with -generic-om or one of the existing packages, but i don't know
[05:10] <RAOF> bucky: That was a known-bug with older make-kpkges; there's a workaround on the wiki page.
[05:10] <bucky> hmm... it seems that debian/control keeps getting over written
[05:10] <RAOF> Also, 2.6.17?  Kicking it olndschool!
[05:10] <bucky> lol
[05:13] <bucky> I guess make-kpkg had a problem with the '+' character in git 
[05:18] <bucky> I don't even have a debian/scripts/setlocalversion file
[06:12] <court_jester> There is a ppa for the last kernel?
[06:17] <bjf[afk]> mdz, the bot checks to see if dmesg and lspci are attached to the bug
[06:18] <bjf[afk]> mdz, that might not be correct for a virtual kernel though, i'll look into it, thanks
[07:28] <bucky> I finally found "KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)-om" and took the -om off and then just used --revision=om.1.0 so I could identify the package
[07:28] <bucky> ended up with ../linux-image-2.6.17_om.1.0_amd64.deb
[07:29] <bucky> thanks for the help RAOF and ohsix ...you guys were all over it
[07:29] <ohsix> why did you need .17?
[07:29] <bucky> oh.. it was in the top level Makefile
[07:30] <bucky> ohsix, i'm messing aroung with linuxPMI which was the continuation of openMosix
[07:31] <bucky> the other patch was for linux-2.6.28.7 and I'm getting a compilation error about termios.h
[07:34] <bucky> anyway.. nite all
[11:19] <akgraner> apw, ping
[13:50]  * cking orders some spare cables and solder...
[13:51] <tgardner> cking, have you ever messed with CONFIG_LOCKUP_DETECTOR ?
[13:51] <cking> tgardner, nope, didn't even know it existed.
[13:51]  * cking has a peek
[13:54] <cking> seems that we need CONFIG_HARDLOCKUP_DETECTOR configured too
[13:54] <tgardner> thats what I'm just looking at
[13:55] <tgardner> CONFIG_HARDLOCKUP_DETECTOR appears to be x86 only
[13:55]  * cking nods
[13:55] <tgardner> I think we should give it a try for awhile
[13:56] <cking> yep, I can't see any reason not too. looks useful 
[14:03] <cking> tgardner, so you think of enabling that asap?
[14:04] <tgardner> cking, just pushed it and am doing a  test build
[14:04] <cking> cool
[14:04] <tgardner> looks like it might be an ABI bumper
[14:05] <cking> well, if it works then you made jmp happy
[14:06] <tgardner> cking, why is that ?
[14:07] <cking> tgardner, just that he's got some users who have lockups, so it may be useful feature for similar bugs in the future.
[14:07] <tgardner> cking, there were som panic reboot options that I chose not to enable lest a machine get in a perpetual cycle of reboots
[14:08] <cking> tgardner, make sense. are the hang timeouts tweakable?
[14:08] <tgardner> cking, at runtime
[14:08] <cking> nice
[14:08] <tgardner> sysctl's
[14:08] <tgardner> default to 60 secs
[14:09] <cking> fair enough 
[14:14] <tgardner> cking, its pretty tough to enter power stats when the wiki won't let me login.
[14:14] <tgardner> SSO appears to be having issues
[14:15] <tgardner> ah, finally. taht took 5 minutes
[14:19] <ronj_> Hi. After yesterday's i686-pae oneiric kernel update, my Dell XPS 1645 laptop is no longer able to resume from suspend. Reproduced: always. Is this a known issue? If not, could somebody point me to a proper way to report the bug? Thanks.
[14:21] <tgardner> ronj_, try 'ubuntu-bug linux' from within a terminal
[14:23] <ronj_> Thanks tgardner, I thought reporting kernel bugs could have been more exotic; glad to hear ubuntu-bug works. Will do it this evening.
[15:00] <brendand> cking - i ran the power test, but my standard deviation was quite high, i guess cause i was using the system while testing. should i redo it?
[15:02] <cking> brendand, yep, if the std.dev. is high then I suggest re-running rather than submitting dubious data
[15:06] <brendand> cking - and best to just leave the system be while it's running?
[15:06] <cking> yep, the test disables cron, so just leave it alone 
[15:09] <cking> if the data is too variable and std.dev. is still high, then don't worry about adding the data to the wiki
[15:25] <brendand> is anyone here from the SRU team? herton, bjf[afk]?
[15:27] <hggdh> bjf[afk]: any problems if I start testing bug Bug 903188 now? I will be away from this Friday to Jan 2
[15:27] <ubot2> Launchpad bug 903188 in linux "linux: 3.0.0-15.24 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/903188
[15:35] <herton> brendand, yes, came back from lunch now
[15:35] <brendand> herton - i need to let you know that if we wait for the Oneiric kernel to be verified then we will not get enough time to test it before the holidays
[15:36] <brendand> seems a lot of bugs to verify
[15:36] <herton> hggdh, I think there isn't any problem, if all bugs are verified then it'll be ok
[15:38] <herton> brendand, I and bjf were talking, and probably we shouldn't have released the oneiric kernel, because of the holidays. It seemed not much bugs would need verification, but that was not the case
[15:40] <herton> brendand, you may test it now I think too, in the hope everything will get verified
[15:41] <hggdh> herton: perfect, thank you
[15:41]  * ogasawara back in 20
[15:43] <brendand> herton - wouldn't you rather wait a couple of weeks to be safe?
[15:43] <brendand> herton - if we wait then we can probably have it tested by the 5th-6th of January
[15:44] <brendand> and be sure of it
[15:44] <brendand> herton - i tell you what, why don't we revisit this on friday or monday and see how things are going with verification?
[15:45] <herton> brendand, doesn't change anything, just it'll be extra work if in the end some bug is not verified. In january we would like to start with a new update on oneiric. Next wee we will be on holidays too until end of the year
[15:45] <herton> *week
[15:46] <brendand> herton - as i said, let's see how things are in a couple of days
[15:46] <brendand> herton - thanks
[15:59] <aquarius> I installed a mainline kernel build (3.2.0-030200rc5-generic) to test suspend as per https://wiki.ubuntu.com/Kernel/MainlineBuilds. It didn't help, so I've just removed it (with sudo apt-get remove linux-image-3.2.0-030200rc5-generic) and apt said the following: The link /vmlinuz is a damaged link
[15:59] <aquarius> Removing symbolic link vmlinuz 
[15:59] <aquarius>  you may need to re-run your boot loader[grub]
[15:59] <aquarius> The link /initrd.img is a damaged link
[15:59] <aquarius> Removing symbolic link initrd.img 
[16:00] <aquarius>  you may need to re-run your boot loader[grub]
[16:00] <aquarius> I'm not sure how to rerun grub... and should I report that happening as a bug in its own right?
[16:00] <tgardner> aquarius, its benign. you can run 'sudo update-grub' if you're paranoid.
[16:01] <aquarius> tgardner, ok, thanks. I get a bit twitchy when stuff like that happens in case it means "ha ha no more booting for you ever" or something unpleasant :)
[16:02] <tgardner> well, its not _quite_ that brittle, though we did have some weird update issues on a server yesterday.
[16:18] <jsalisbury> herton, bjf, possible regression from 3.0.0-13 to 3.0.0-14: bug 902491
[16:18] <ubot2> Launchpad bug 902491 in udev "Severe regression with latest kernel update: 3.0.0-14.23 takes an unreasonable amount of time to boot due to udev" [Undecided,Confirmed] https://launchpad.net/bugs/902491
[16:19] <jsalisbury> herton, bjf, it may be a udev issue, but wanted to run it by you.
[16:20] <bjf> jsalisbury: ok, on it
[16:20] <jsalisbury> bjf, thanks
[16:21] <bjf> jsalisbury: looks like precise has the same issue
[16:22] <tgardner> wow, 90 seconds
[16:22] <jsalisbury> bjf, yes, as well as the mainline kernel
[16:27] <tgardner> gema, do you have any test configurations that use LVM ?
[16:27] <gema> tgardner: yes, there are some jobs that use it
[16:27] <tgardner> gema, would you notice a boot delay ?
[16:27] <gema> here they are: https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/?
[16:28] <gema> tgardner: no, I don't think we are particularly looking at timings in this case
[16:28] <gema> tgardner: but you probably can get an idea based on the logs , if you were looking for something in particular
[16:30] <tgardner> gema, its something to think about. we're looking at a udev/kernel issue where the boot is delayed by 90 seconds.
[16:31] <gema> tgardner: I will think about it, it is still not clear how we are going to display the dashboard info, maybe not just boot time but overall execution time and have a flag if it fluctuates too much
[16:32] <tgardner> gema, how about looking for big time gaps in dmesg for the first 30 seconds or so? if there is a gap of more then 10 seconds, then soemthing is likely wrong.
[16:32] <gema> tgardner: I will look into the details on how to implement that
[18:42]  * tgardner -> lunch
[19:38] <psusi> can someone explain to me what mutex_lock_nested does?  specifically the nested part
[19:41] <kiko> let's see if somebody has a clue on a funny problem I have
[19:41] <kiko> I have a server hosted at serveraxis
[19:41] <kiko> when I apt-get upgrade and a new kernel comes in
[19:41] <kiko> the new package installs fine
[19:41] <kiko> but update-grub isn't getting run
[19:41] <kiko> it's a natty server
[19:41] <kiko> any idea what normally triggers update-grub
[19:41] <cyphermox> apw; sent an email with my patch to kernel-team@, who can I ask to moderate it so it reaches the list?
[19:42] <kiko> and why it's not being triggered?
[19:42] <tgardner> kiko, update-grub should be run by update-initramfs
[19:42] <kiko> gotcha
[19:43] <kiko> let's look at that then
[19:43] <tgardner> which in turn is launched by the kernel post-inst
[19:44] <tgardner> cyphermox, I can. in the meantime you should subscribe to the list.
[19:45] <kiko> tgardner, can I trigger that action manually to see if it's actually failing or just not getting run?
[19:46] <tgardner> 'update-initramfs -u' should do it
[19:47] <tgardner> kiko, its interesting that you have this problem. I updated a kernel build server yesterday in the Boston DC and it did not get update-grub run either.
[19:48] <tgardner> though Im'm sure update-initramfs ran 'cause the bits were there in /boot
[19:49] <kiko> so if I run update-initramfs manually it runs and does /not/ update grub
[19:49] <kiko> kiko@dragon:/var/lib/dpkg/info$ sudo update-initramfs -u
[19:49] <kiko> update-initramfs: Generating /boot/initrd.img-2.6.38-13-generic
[19:49] <kiko> tgardner, this is a server hosted in a DC as well
[19:49] <kiko> it is a virtual server
[19:50] <tgardner> kiko, I guess you should hassle slangasek. that package is maintained by foundations
[19:50]  * slangasek waves
[19:51] <kiko> help :)
[19:51] <slangasek> kiko: does /etc/kernel/postinst.d/zz-update-grub exist, do you have grub (grub1) or grub-pc (grub2) installed, are /boot/grub/{grub.cfg,menu.lst} timestamps updated when you run it?
[19:52] <kiko> so /etc/kernel/postinst.d/zz-update-grub does not exist
[19:52] <kiko> kiko@dragon:/etc/kernel/postinst.d$ dpkg -l | grep grub
[19:52] <kiko> ii  grub                                       0.97-29ubuntu61.1                          GRand Unified Bootloader (Legacy version)
[19:52] <kiko> ii  grub-common                                1.99~rc1-13ubuntu3                         GRand Unified Bootloader, version 2 (common files)
[19:52] <kiko> weird versions
[19:53] <kiko> menu.lst is not updated when I run update-initramfs
[19:53] <kiko> slangasek, ^^
[19:53] <slangasek> weird but expected versions
[19:53] <kiko> so why's my file missing?
[19:54] <slangasek> that version of grub seems not to have ever installed the hook script
[19:55] <slangasek> does /etc/kernel-img.conf contain an 'postinst-something-something = update-grub' line?
[19:55] <kiko> no
[19:55] <slangasek> ok
[19:55] <kiko> it contains nothing related to grub
[19:55] <kiko> it says "do_bootloader = no" though
[19:55] <kiko> weirdly
[19:55] <slangasek> yeah, that flag doesn't mean what it probably ought to ;)
[19:56] <slangasek> so, you can run 'update-grub' by hand and that should take care of it
[19:56] <tgardner> kiko, does /etc/kernel-img.conf have 'postinst_hook = update-grub' ?
[19:56] <kiko> no
[19:56] <kiko> I do run it by hand, slangasek 
[19:56] <kiko> but I forget
[19:56] <slangasek> ah
[19:56] <kiko> and then I get kernel xpl0its
[19:57] <kiko> :)
[19:57] <slangasek> you want the actual bug fix, not a workaround ;)
[19:57] <slangasek> so you can add the line tgardner mentions
[19:57] <kiko> a real workaround is okay :)
[19:57] <slangasek> or you can switch to grub-pc
[19:57] <kiko> will that work in this weird virtual server setup?
[19:57] <slangasek> what kind of weird is it?
[19:57] <slangasek> if it's Xen, then... no
[19:57] <kiko> I don't know
[19:57] <kiko> yeah, it's xen
[19:58] <slangasek> yeah, you'll have to add the postinst_hook line then
[19:58] <kiko> and then update-initramfs will dtrt?
[19:58] <slangasek> yes
[19:58] <kiko> testing testing 123
[19:59] <kiko> kiko@dragon:/boot/grub$ sudo update-initramfs -u
[19:59] <kiko> update-initramfs: Generating /boot/initrd.img-2.6.38-13-generic
[19:59] <kiko> kiko@dragon:/boot/grub$ 
[19:59] <kiko> kiko@dragon:/boot/grub$ ls -l  menu.lst
[19:59] <kiko> -rw-r--r-- 1 root root 6405 2011-12-14 06:48 menu.lst
[19:59] <kiko> kiko@dragon:/boot/grub$ grep postinst_hook /etc/kernel-img.conf 
[19:59] <kiko> postinst_hook = update-grub
[19:59] <kiko> LIES!!!
[19:59] <cyphermox> tgardner: thanks
[19:59] <kiko> slangasek, for some reason it don't
[20:00] <slangasek> hmm
[20:01] <slangasek> kiko: oh - the hook is actually triggered from the kernel package's maintainer script, not from update-initramfs
[20:01] <kiko> that's what I thought
[20:01] <slangasek> so 'dpkg-reconfigure linux-image-2.6.38-13-generic' would do it
[20:01] <kiko> okay, so a dpkg-reconfigure maybe
[20:01] <kiko> aha!
[20:01] <kiko> trying!
[20:05]  * tgardner wonders how long that should take 
[20:07] <kiko> it worked
[20:07] <kiko> you guys are DA BOMB
[20:07] <kiko> woot
[20:07] <tgardner> kiko, that is weird. has this been updated from prior installs ?
[20:07] <kiko> yes, definitely
[20:07] <kiko> it's an old image
[20:07] <tgardner> must have if it had grub1
[20:07] <kiko> upgraded upgraded upgraded
[20:08] <tgardner> kiko, pre-lucid ?
[20:08] <kiko> quite possibly, let me ask johan
[20:08] <tgardner> kiko, it just about have to have been jaunty or karmic
[20:08] <kiko> yeah, something like that
[21:10] <psusi> can anyone explain what mutex_lock_nested does, and why you would want to use it instead of the non nested version?
[22:15] <hggdh> bjf: EC2, Oneiric, found today while opening a kernel bug -- the apport hook is erroring out: http://pastebin.ubuntu.com/770588/
[22:15] <hggdh> bjf: want a bug on it?
[22:16] <bjf> hggdh: looking
[22:16] <bjf> hggdh: yes, bug please
[22:16] <hggdh> bjf: roj
[22:23] <alexbligh1> LP886521 - I don't suppose there is an installer CDROM built with this is there? It's (slightly) hard to test this with a previous kernel on Oneiric under Xen for obvious reasons. Or failing that how do I find a URL for a .deb so we can downgrade Precise?
[22:23] <hggdh> bjf: bug 904489
[22:23] <alexbligh1> LP #886521
[22:23] <ubot2> Launchpad bug 904489 in apport "kernel apport hook error on EC2 Oneiric" [Undecided,New] https://launchpad.net/bugs/904489
[22:23] <ubot2> Launchpad bug 886521 in linux "CONFIG_XEN_PLATFORM_PCI should be "y" when building 3.1 kernel" [Medium,Fix committed] https://launchpad.net/bugs/886521
[22:25] <bjf> alexbligh1: https://launchpad.net/ubuntu/+source/linux/3.0.0-15.24  ?
[22:31]  * tgardner -> EOD