[01:22] <blueyed> In case there's another upload for -meta, please include the fixes for bug 197632
[01:22] <ubotu> Launchpad bug 197632 in linux-meta "Error in linux-image-xen package description" [Medium,Triaged] https://launchpad.net/bugs/197632
[05:41] <tjaalton> Amaranth: actually, I've tried copying all the libs from an extracted installer, but it didn't help. So maybe the problem is somewhere else, but it's definately in our lrm
[05:44] <tjaalton> Amaranth: the pink-shadows bug already has a comment from me that using the installer fixes the shadows
[05:44] <Amaranth> ah
[05:44] <tjaalton> it could fix something else too..
[05:44] <Amaranth> well someone else filed the bug and pointed me to it, i just set the priority and such :)
[05:45] <tjaalton> but dropping dh_strip might be wise anyway.. there's not much saved by it
=== fabbione is now known as fabbione-away
=== asac_ is now known as asac
=== Whoopie_ is now known as Whoopie
[07:04] <hti_pro> need help building kerne
[07:04] <hti_pro> kernel
[07:05] <hti_pro> when i build the package it grows to about 2GB
[07:06] <hti_pro> anyone awake
[07:11] <hti_pro> i am using the following guide:    http://howtoforge.com/kernel_compilation_ubuntu_p2     If anyone wakes up and has an idea pm me
[09:00] <kraut> moin
[09:04] <mvo> hm, 2.6.24-15-386 does not boot on my test system (cant find the root fs), -generic does - any hints? should I file a bug?
=== jayc_ is now known as jayc
=== jayc__ is now known as jayc_
[13:04] <amitk> soren: could you have a look at what config you want for openvz
[13:17] <Ng> are there any more kernel rebuilds now before release?
[13:19] <amitk> Ng: there should be, but I am a awaiting some input from rtg or soren for the openvz failures.
[13:22] <Ng> amitk: thanks. I just checked shortlog and the patch I was wondering about has been reverted, so it's all good :)
=== jayc__ is now known as jayc_
[14:45] <soren> amitk: Is thiss still relevant?
[14:52] <prana> hello; triaging bug 213308...i believe it demonstrates a regression for perhaps a very small case of hardware...should I mark it confirmed and assign it to the kernel team?
[14:52] <ubotu> Launchpad bug 213308 in linux "Update from 2.6.24-12 to -14 or -15 results in ata SRST failed (errno=-16)" [Undecided,Incomplete] https://launchpad.net/bugs/213308
[14:53] <prana> when you read the bug report, you can ignore everything except the comments from the original reporter and Emil Sit (me).
[14:56] <Ng> prana: I see you're trying to get her to mount a USB device to get some debugging info out of the busybox shell she gets left in?
[14:57] <Ng> prana: it should be fixed for hardy, but at least as of daily hardy images a couple of days ago, the vfat module isn't in the initrd
[14:57] <prana> Ng:i did try to do that though i don't think itwas successful. i found a workaround to the specific problem that was causing the boot failure on the web that seems to work.
[14:57] <Ng> yeah, it wasn't successful because there's no vfat module :)
[14:57] <amitk> soren: fixed
[14:58] <Ng> I hit exactly the same situation on a server, but with a CDROM throwing the SRST error
[14:58] <prana> Ng: so i guess we don't have a dmesg trace from what the sys looked like in the bad state.  if a newer initrd includes vfat support, it might be possible to get the trace.  or we could perhaps store the output on one of her ntfs partitions.
[14:58] <Ng> prana: there's dmesg and lspci info on the one I found
[14:58] <hti_pro> any idea if this bug will be fixed in hardy release  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/110636
[14:58] <ubotu> Launchpad bug 110636 in linux-source-2.6.22 "hdparm - cannot set dma on IDE hard drive that works via pata" [Medium,Incomplete] 
[14:58] <prana> Ng: ah, but i think those are from the -12 kernel, not the -14 or -15 kernels.
[14:59] <soren> amitk: Cool, thanks.
[14:59] <Ng> prana: I hit the problem with the beta release and with daily images from earlier this week, which should have been -15
[14:59] <prana> Ng: anyway, it seems like the problem does exist so is marking it confirm and assigning to kernel team at this point reasonable? or would kernel team want more info first?
[14:59] <Ng> prna: it's Bug #210200 
[14:59] <Ng> pass
[14:59] <Ng> I'm not on the kernel team :)
[15:00] <prana> hm. ok, gotta rnu for a bit. will check back later.
[15:00] <hti_pro> or is there a kernel I can switch too that didn't have the prob
[15:01] <amitk> BenC: I've got classmate suspending with 2.6.24.2 + a patch but not with ubuntu tree + patch. This is going to require some time to bisect/debug. How long do I have?
[15:05] <hti_pro> nothin on #110636???
[15:05] <BenC> amitk: we're under freeze now, so you are very limited
[15:06] <BenC> amitk: likely wont make RC
[15:06] <amitk> BenC: i meant after rc
[15:11] <Ng> rtg: any idea what could be causing https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/215102?
[15:11] <ubotu> Launchpad bug 215102 in linux-ubuntu-modules-2.6.24 "switching from wireless to wired causes wireless confusion" [Undecided,Confirmed] 
[15:13] <Ng> I'm moderately sure I've not seen that before, but I don't switch between the two very much without suspending because I'm going home, and suspend means unloading the modules
[15:13] <rtg> Ng: when you do that, is the wireless interface (probably wlan0) UP or DOWN ?
[15:14]  * Ng plugs back into wired to test
[15:15] <Ng> rtg: UP
[15:15] <rtg> Ng: I assume this is a WPA enabled AP in the office?
[15:15] <Ng> wlan0 and wmaster0 are up, although there's no IPs and iwconfig suggests it's not on an ESSID, but is on an AP
[15:16] <Ng> yeah
[15:16] <rtg> Ng: OK, that is likely the cause. Please add that to the LP report and I'll forward it to Rolla.
[15:16] <Ng> k
[15:17] <BenC> rtg: I saw you on a linux.com report from the conference
[15:17] <rtg> Ng: I think NetworkManager should down the interface.
[15:17] <BenC> rtg: you were standing in the background talking to someone during the entire video
[15:17] <Ng> rtg: I kinda agree, or at least do iwconfig ap off
[15:17] <rtg> BenC: just by showing up :)
[15:17] <rtg> Ng: you could test the theory by DOWN'in the interface.
[15:18] <Ng> rtg: ok, will cycle again to test that shortly, I just tested iwconfig ap off and that's stopped the syslog messages
[15:21] <Ng> rtg: looks like ifconfig wlan0 down doesn't completely stop it
[15:21] <Ng> all added as comments
[15:22] <rtg> Ng: thanks. Maybe you should bug asac as well?
[15:22] <Ng> yeah, that was my next move :)
[16:03] <BenC> So was the openvz ftbfs fixed in 16.30 as well?
[16:05] <amitk> BenC: yes
[16:06] <BenC> commit cd5576d74945916aa88a0476fe07a059b2f24ceb
[16:06] <BenC> Author: Tim Gardner <tim.gardner@canonical.com>
[16:06] <BenC> Date:   Thu Apr 10 06:24:48 2008 -0600
[16:06] <BenC>     UBUNTU: Accidentally copied amd64 config over i386
[16:06] <BenC>     Ignore: yes
[16:06] <BenC>     
[16:06] <BenC>     Really fix openvz configs for virtio.
[16:06] <BenC>     Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
[16:06] <BenC> just wondering why the commit was ignored...would be useful info for the changelog
[16:08] <xivulon> cking hi
[16:08] <cking> xivulon: hi there
[16:08] <xivulon> thanks a lot for your help really appreciated
[16:09] <xivulon> added a comment to #204133
[16:09] <xivulon> what is your opinion on that?
[16:09] <cking> just a second..
[16:10] <lamont> xivulon: wondering if you can help with testing the fix for bug 206113
[16:10] <ubotu> Launchpad bug 206113 in util-linux "Wubi install cannot create swap space (8.04 Beta) [Regression from alpha 6]" [Undecided,New] https://launchpad.net/bugs/206113
[16:11] <xivulon> lamont can only do that tonight (am at work now), but I cannot reproduce that bug
[16:11] <xivulon> can only test if it works
[16:12] <cking> xivulon: not sure about it. Let me ponder on it for a few minutes over a strong cup of coffee. I was up until past midnight working on this one so head is a bit fuzzy. 
[16:13] <xivulon> cking, sure
[16:14] <lamont> xivulon: sure
[16:14] <lamont> I verified that mkswap works when there aren't any errors already... :-(
[16:14] <lamont> but more eyes would be wonderful
[16:15] <xivulon> lamont one potential issue wubi installations may have is that the swap file might be fragmented
[16:15] <xivulon> not sure about the implications of that
[16:15] <cking> xivulon: I need to play with the remount options and see if this works. I will keep the bug report updated with my findings
[16:15] <lamont> xivulon: that could possibly make for short reads, I suppose
[16:15] <lamont> which we should handle now
[16:16] <xivulon> cking as mentioned 186117 and 186114 are the related bugs in this case
[16:17] <cking> xivulon: perhaps a sync is required before / is remounted r/o. 
[16:17] <xivulon> cking adding syncs shouldn't be problematic, see last comment in 186117 though
[16:17] <cking> will do
[16:19] <cking> ..ah ntfs remount r/o was broken and so the regression is not really a regression - just stops one from cutting off a branch while standing on it type of safeguard
[16:21] <cking> ..no way of using a memory based file system for some of this so that we can umount the ext3 fs cleanly and not have it as / ? 
[16:26] <xivulon> do you mean we should have the remaning sysvinit in a memory fs, and unmount ext3 and host completely?
[16:31] <xivulon> cking I wouldn't know how to implement that in a non invasive way, I'd think that the easiest root might be to apply the patch in #186114
[16:31] <xivulon> but I am not sure about the implications mentioned by Szaka in 186117
[16:38] <cking> xivulon: the worst case scenario is screwing up somebody's NTFS filesystem - which is something that must be avoided. It's kind of chicken and egg here.
[16:41] <cking> mmmm.  / is dependant on /home, and /home must not be umounted. Is the remount of / ro causing the problem or is /home being umounted?
[16:41] <xivulon> do you mean /host?
[16:42] <cking> ...oops yes /home ---> /host my mistake - need more coffee
[16:43] <xivulon>  / is in a file inside /host. During initramfs first we mount /host, then /root then mount move /host to /root/host
[16:44] <xivulon> so after run-init /root -> / and /root/host -> /host
[16:45] <xivulon> in umountroot we make everything r/o again (/ and /host)
[16:45] <cking> ok.. and in umountroot what happens - does /host get umounted before / ? 
[16:45] <xivulon> except that now /host is excluded because I was scared by szaka 
[16:45] <xivulon> nothing is unmounted only remounted r/o
[16:46] <cking> OK: .. remount / ro is OK, but then /host needs umounting before shutdown.
[16:47] <xivulon> hmm no I do not unmount /host because that is equivalent to unmount /
[16:47] <cking> ..well I think remouting / is OK :-)
[16:48] <cking> maybe I'm missing something fundamental here, but something needs to sync and umount the NTFS filesystem (surely?)
[16:49] <xivulon> well in a normal installation / is never really unmounted right?
[16:49] <xivulon> so why is it required to unmount /host as opposed to remounting it ro?
[16:50] <cking> ..yes but / is not normally loop'd back.
[16:50] <xivulon> cking I do not think it is possible to unmount /host, at most you can remount /host and / r/o and then reboot
[16:51] <xivulon> unless you use a memory fs
[16:52] <cking> I could be wrong here, but I believe one needs to flush the ext3 file back to the ntfs filesystem otherwise one will see / getting corrupted. The blocks are still in memory and need to be written back before the ntfs filesystem is unounted
[16:52] <cking> unounted --> umounted
[16:52] <cking> ..the alternative is, as you say, use a memory fs.
[16:53] <xivulon> making / (ext3) ro + sync would not ensure that?
[16:53] <xivulon> and then making /host ro + sync
[16:56] <cking> xivulon: I think making / (ext3) ro + sync may be enough.. but I am now 5% worried it may not be enough for a looped back file on ntfs - I've never toyed around with this before.
[16:57] <cking> xivulon: It's worth tinkering with anyway. I think making sure the ext3 file on the ntfs partition is written back is more important than any of the vm dirty page hacks
[16:58] <xivulon> absolutely
[16:58] <xivulon> you can emulate without XP, by creating an ntfs partition and putting a file conating ext3 /
[16:59] <xivulon> then add grub and boot using the ROOT=/dev/sdX LOOP=/path/to/loopfile arg
[17:00] <cking> xivulon: perhaps you can write these notes in the bug report as a reference for anyone else facing this problem in the future.
[17:00] <xivulon> that is in lower-case
[17:00] <xivulon> will do
[17:01] <cking> ..indeed. I've faked up some of that today and realised that one can umount the ntfs /host with the / still busy - hence screwing up / good and proper. 
[17:02] <xivulon> you mean by manually unmounting /host or when rebooting? in the latter case I'd expect / to be ro reducing risks
[17:03] <cking> ...manually forced umount of /host  which made me wonder what was happening in the real reboot scenario.
[17:04] <cking> ..that is, it made me wonder if the loop mounted / was being screwed up because the blocks in the buffer cache were not being written back to /host when the system shut down.
[17:05] <cking> xivulon: I need to go in 5 mins or so.. I have an somebody picking me up to fly some model planes..
[17:05] <houdini> I've got what I think is a bug in the x64 builds of Ubuntu 7.10 and 8.4, but I'd like some help making sure it's not just me.  anyone willing to help for a few minutes?
[17:05] <xivulon> cking sure
[17:05] <xivulon> umounting host manually though will create problems
[17:06] <xivulon> at the moment we have an obfuscation method
[17:06] <houdini> the bug reporting guidelines suggest filing it as a kernel bug, so that's why I'm here
[17:06] <xivulon> not in /media not in fstab only visible in /proc/mounts
[17:06] <cking> xivulon:  is that enough to work on though? Do you think it helps enough to maybe get a little further?
[17:06] <xivulon> yes ntfs + nested root file + grub is enough
[17:07] <xivulon> for testing
[17:07] <cking> OK. keep us posted! :-)
[17:07] <cking> xivulon: I'm especially keen to know if one can actually get rid of the vm dirty hacks if the umount can be sorted out 
[17:08] <cking> ..anyway. I need to go.
=== ogasawara__ is now known as ogasawara
[18:53] <blueyed> linux-server triggers the nvidia black window bug for me. Is this a bug with package "linux" or "linux-restricted-modules-2.6.24"? The different kernel config settings should be this: http://pastebin.com/m89666bc (no problems with linux-generic)
[18:53] <blueyed> (using nvidia-glx-new)
[19:44] <blueyed> Might be bug 214836
[19:44] <ubotu> Launchpad bug 214836 in linux-restricted-modules-2.6.24 "lrm incorrectly installs nvidia-glx-new" [High,Triaged] https://launchpad.net/bugs/214836
[20:14] <rtg> tjaalton: I finally have a kernel for -16. Can you upload LRM?
[20:33] <tjaalton> rtg: sure, I'll do a couple of fixes too. stripping fglrx/nvidia seems to be pointless, since there's not much space saved and it could cause issues
[20:34] <rtg> tjaalton: be very conservative, 'cause this is about the last upload for Hardy.
[20:34] <Nafallo> :-)
[20:34] <tjaalton> haven't yet found out why the lrm version of nv_new is broken compared to installing it by hand..
[20:35] <tjaalton> rtg: of course :)
[20:37] <rtg> tjaalton: thanks. 
[20:37] <tjaalton> hmm, shouldn't envy be in universe?
[20:38] <tjaalton> I mean, it's not in the archive
[20:39] <tseliot> tjaalton: not yet but it should be there soon
[20:40] <tseliot> in the meantime you can use my repository to install it:
[20:40] <tseliot> http://albertomilone.com/wordpress/?p=185
[20:40] <tjaalton> tseliot: ah right. does it use the upstream installer scripts?
[20:40] <tjaalton> ok, I'll just try it out later today
[20:40] <tjaalton> ..to find out if the pink-shadows issue is fixed with it
[20:41] <tseliot> tjaalton: it uses a customised version of the l-r-m with DKMS, CUDA, etc.
[20:42] <tseliot> tjaalton: improvements which we can talk about in Prague
[20:42] <tjaalton> yeah
[21:08] <Nafallo> aaaaaaaaaaaaaaaa/win 30
[21:08] <Nafallo> oops
[21:34] <xivulon> Hi all, have a question
[21:35] <xivulon> in a nested filesystem (loopfile) when I mount it with the sync option how does it work exactly?  
[21:35] <xivulon> I mean if set sync for the nested filesystem does that also apply to the host filesystem?
[21:36] <xivulon> so that the data actually hits the metal?
[22:39] <tjaalton> tseliot: how do I make sure that I'm using the envyng-version of the kernel module?
[23:36] <tseliot> tjaalton: if nvidia-new-kernel-source is installed then EnvyNG's module will be loaded.
[23:38] <tjaalton> tseliot: where does it load the module from?
[23:39] <tseliot> tjaalton: /sbin/lrm-video makes sure that EnvyNG's module is loaded
[23:39] <tjaalton> I mean where can I find the module :)
[23:41] <tseliot> tjaalton: it's in /lib/modules/$kernel/updates/dkms/
[23:41] <tseliot> tjaalton: it's the module which was built and installed by DKMS
[23:41] <tseliot> tjaalton: problems?
[23:42] <tjaalton> tseliot: no, I just wanted to see where it came from
[23:43] <JanC> DKMS = the Dell tool?
[23:43] <tseliot> JanC: yep