[04:47] (ScottK/#ubuntu-kernel) That's my guess.
[04:52] <ThrobbingBrain66> ok, that's done.  i also subscribed the kernel team to my bug, i dunno if that's frowned upon or not.  anything else i need to do?
[04:58] <ScottK> Actually, IIRC the kernel team prefers to be assigned, not subscribed.
[05:05] <ThrobbingBrain66> yeah, i figured that.  oops.
[05:11] <ThrobbingBrain66> thanks for the help
[09:23] <kraut> moin
[01:35] <doko> please see bug 116648; did we have problems building madwifi in feisty and/or gutsy?
[02:28] <Kano> BenC: added a new fetch script: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/128297
[04:05] <mikepj> I have a kernel update question.  Recently I came across a blog entry noting a data corruption problem on machines with over 4Gb of memory.  This was due to a kernel bug.  I was wondering if the patch for this has been merged into the 6.06 LTS version of Ubuntu.  The blog entry is here:  http://blogs.smugmug.com/don/2007/07/25/silent-data-corruption-on-amd-servers/
[06:28] <bdmurray> mikepj: one thing you could do is look for a launchpad bug linked to the kernel.org bug
[06:31] <bdmurray> mikepj: I think it is safe to say it has not been merged
[06:35] <bdmurray> BenC: are you familiar with that at all? it is commit cf6387daf8858bdcb3e123034ca422e8979d73f1 I think.
[06:36] <BenC> bdmurray: looks to be in our gutsy tree
[06:37] <bdmurray> Right I was thinking about dapper
[06:37] <BenC> Sounds pretty serious, probably mark it for dapper-6.06.2 milestone and we can look at it in the next week
[06:38] <BenC> really simple patch too, so definitely should be easy :)
[06:38] <bdmurray> I don't think there is an lp bug yet though.  Is there a preferred way to make a new for this?
[06:38] <zul> BenC: do you guys need any help for 6.06.2 from the "community" side?
[06:38] <BenC> zul: basically going to need a lot of testing from anyone with the target hardware
[06:39] <BenC> if you check the dapper-6.06.2 milestone tagged bugs, you can get a glimpse at what we're hoping to fix/support
[06:39] <zul> ah ok im running gutsy now
[06:39] <zul> url?
[06:41] <bdmurray> https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2
[06:42] <zul> htanks
[09:08] <mikepj> sorry, I was away.  Thanks for the info.  Glad to hear the patch might make it into 6.06.2.
[09:12] <bdmurray> mikepj: I submitted a bug about it but seem to have misplaced it.  It should be listed in the milestoned bugs though.
[09:12] <mikepj> Yeah, I found it here:  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/128568
[09:13] <mikepj> I thought it was effecting all AMD processors though.  Must have missed something in one of the other bug reports
[09:37] <IntuitiveNipple> I saw a related bug in launchpad earlier searching for "iommu=soft" (2 bugs; only 1 is using >=4GB RAM) but got side-tracked checking for patches to 6.06, and there is a debian bug #404148 with fix for 2.6.18.
[10:41] <bdmurray> BenC: Could you look at bug 47768?
[10:46] <BenC> bdmurray: the original report appears to be an ordering problem
[10:47] <BenC> bdmurray: do you know if we used UUID in dapper? I can't seem to recall, and don't have a dapper system handy
[10:51] <doko> are kyle and lamont on vacation?
[10:51] <BenC> doko: kyle was hung up returning from UbuntuLive
[10:52] <bdmurray> kees's UsingUUID page says since Edgy
[10:52] <BenC> I wonder if we should backport UUID stuff to 6.06.2
[10:53] <ScottK> BenC: I have a dapper system.  Checking
[10:53] <ScottK> BenC: No UUIDs in /etc/fstab.
[10:54] <ScottK> It sounds invasive/risky/dangerous to backport to me.
[10:55] <bdmurray> That's what I would think too - quite the "surprise"
[10:56] <BenC> actually it's not dangerous at all
[10:56] <BenC> we've been upgrading people to UUID since edgy
[10:56] <BenC> the main purpose of 6.06.2 is for people that can't install 6.06{,.1} anyway
[10:57] <ScottK> Yes, but dapper-updates will get it all too, right?
[10:57] <BenC> right, but then anyone running dapper right now will eventually be pushed to UUID no matter what
[10:57] <BenC> unless they want to stay with dapper forever
[10:57] <ScottK> Well just 5 years.
[10:57] <BenC> then they'll be pushed into the UUID upgrade then
[10:58] <ScottK> Yep.
[10:58] <ScottK> Exactly.
[10:58] <BenC> either way, not putting it into 6.06.2 is just deferring it, not making it any less dangerous
[10:58] <ScottK> At the end of a stable series, not in the middle.
[10:58] <BenC> so that argument is pointless
[10:58] <ScottK> I'd put it the other way around.
[10:59] <BenC> ok, so we'll just leave people with no sure way to install a system because of a feature that we've tested over a year now isn't going to be backported :)
[10:59] <ScottK> Deferring the upgrade puts the change where it would be expected, not where it would be unexpected (~ 20% of the way into a stable LTS baseline's life).
[10:59] <BenC> same could be said for some of the things we're already doing for 6.06.2
[11:00] <BenC> UUID usage is stable, it's the non-use of it that is unstable
[11:00] <BenC> especially with SATA and SCSI drives
[11:01] <ScottK> It seems like a significant design change to me.  If you did it and broke my LTS server, I'd be pretty annoyed.
[11:01] <BenC> I mean, the upgrade is a single shell script
[11:01] <BenC> and it's very well written to avoid breakage...any problems, and it leaves the fstab/menu.lst alone
[11:02] <ivoks> i wouldn't do that in LTS :/
[11:02] <BenC> guess we'll just have people installing and not being able to boot then :/
[11:02] <ScottK> Why?
[11:03] <BenC> read bug #47768
[11:03] <BenC> and maybe you'll have some context
[11:03] <ivoks> people are unable to install cause of missing drivers :)
[11:03] <BenC> ivoks: this is a case of people being able to install, and then not being able to boot it afterwards
[11:04] <ivoks> i heard about that problem
[11:04] <BenC> ScottK: so the alternate installer loads the drivers in a different order than the installed system (which is ok, because driver load order shouldn't matter and can't be enforced)
[11:04] <ivoks> right
[11:04] <ivoks> i2o and stuff
[11:04] <BenC> as such, they install and on boot, sda becomes sdb, and sdb becomes sda
[11:04] <BenC> blammo
[11:04] <BenC> no, nothing to do with i2o
[11:04] <BenC> this could be onboard SATA == sda, scsi controller == sdb
[11:05] <BenC> load the drivers in different order, and you no longer have a bootable system
[11:05] <ivoks> yes, that happend to me once
[11:05] <ivoks> i upgraded to feisty then :D
[11:05] <BenC> hehe
[11:06] <ivoks> ok, you got my vote, since this will personaly help me in some cases
[11:06] <ivoks> (not that it matters :)
[11:07] <ivoks> are there plans for new version of e1000, 3w-9xxx and some IDE controlers for 6.06.2?
[11:07] <BenC> e1000 I believe so, I'd have to check 3w-9xxx, but there's a good chance of it
[11:07] <IntuitiveNipple> Hmmm, UUID install-and-not-boot occurs for kernel upgrades even for Feisty/Gutsy, when you've got one boot partition and 2+ root partitions on the boot disk (multiple distro's) the menu.lst UUIDs are always set to the last root partition UUID, regardless of what they were set to already. Should I post it as a bug?
[11:08] <ScottK> What about using UUID for new installs and not "upgrading" something that's already working.
[11:08] <ScottK> Personally, I've had a lot more trouble with the UUID transition than I've had with not having UUID.
[11:08] <BenC> IntuitiveNipple: sounds like an update-grub issue
[11:09] <BenC> IntuitiveNipple: not a kernel issue
[11:09] <BenC> ScottK: that's possible too
[11:09] <ivoks> then go with that... only for new installs
[11:09] <BenC> ScottK: I can't see how anyone could not be using UUIDs to be honest
[11:09] <ScottK> That would not place existing working installs at risk and so would be a lot more consistent with the LTS guarantee in my book.
[11:09] <BenC> things were so broken before that
[11:09] <IntuitiveNipple> BenC: I'll do some digging, if necessary post a bug against update-grub then
[11:10] <ScottK> Well I'm typing this on a Dapper desktop that's never had troubles and has no UUID.
[11:10] <BenC> IntuitiveNipple: just 'grub', the script is part of that package
[11:10] <BenC> ScottK: and has one disk, right? :)
[11:10] <ScottK> Ah.
[11:10] <ivoks> ScottK: i had scsi and sata controller
[11:10] <IntuitiveNipple> BenC: ok :)
[11:10] <ScottK> It has two, but they're RAIDed.
[11:10] <ivoks> depending on moon and sun, once scsi was sda, and in other cases sata was sda
[11:11] <BenC> yeah, if the OS only sees one disk, you'd never have to concern yourself
[11:11] <ScottK> Right.
[11:11] <BenC> but think if you have a SATA, and boot with a USB disk plugged in
[11:11] <BenC> SATA or SCSI
[11:11] <ScottK> Yeah.
[11:11] <BenC> it might not be a problem, but it could
[11:11] <BenC> ScottK: I think you're right about the UUID upgrade part
[11:12] <BenC> just leaving it for new installs is a safe bet, since it targets the people we're concerned about
[11:12] <ScottK> That sounds quite sane to me.
[11:12] <ScottK> You might also have it so someone that wanted to could run the upgrade script manually, just don't do it automagically.
[11:12] <ScottK> If that's feasible.
[11:13] <ivoks> additional complication and my guess is that no one would do that on working system
[11:14] <ScottK> Yeah, but someone who has been having trouble would do that over a re-install.
[11:14] <ivoks> don't fix if it isn't broken
[11:14] <ScottK> That's the least important part.
[11:14] <ScottK> Absolutely not.
[11:15] <ivoks> well, i would love to see uuid on new installs, but i wouldn't touch running servers
[11:15] <ivoks> i'm just happy cause of e1000 and probably 3w-9xxx :)
[11:17] <ivoks> what about support for ICH8 IDE?
[11:55] <JanC> hm, someone I know complains that grub sees his internal hard disk as hd 2 and sometimes as hd 0, depending on whether his USB disk is connected...
[11:56] <JanC> AFAIK grub doesn't understand GUIDs ?