[03:22] hrm, someone from vmware requested dropping vmwgfx from the kernel config [03:44] Sarvatt: from the main one yes. [03:44] Sarvatt: John or Thomas? [03:46] Its not really ready to be used as default, but I think we are fine with user being able to get it from the ppa. [03:48] Dr_Jakob: from the kernel, it wont be available in the ppa because it's dropped already but it sounds like its in vmware tools anyway [03:49] https://bugs.edge.launchpad.net/ubuntu/+bug/606139 [03:49] Launchpad bug 606139 in linux (Ubuntu) "Request to disable vmwgfx driver in default config (affects: 1) (heat: 8)" [Medium,Fix released] [03:52] Sarvatt: don't you compile your own kernel for the ppa? [03:53] nope, I copy the ones from the latest dev release back to the last stable release and 2.6.35-9 that i just copied to lucid already has it disabled [03:53] ah [03:54] i should probably start though I guess [04:45] hmm, plymouth in maverick is all kinds of busted for me as well from the last few days worth of updates [04:45] looks like grubs doing it's gfxpayload=keep thing again [04:46] [ 3.119637] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver [04:46] [ 3.119709] Console: switching to colour dummy device 80x25 [04:46] [ 3.120478] Console: switching to colour frame buffer device 128x37 [04:46] screen stays off, cant boot unless i press escape to remove the broken splash before X starts [04:47] guess this is what dupondje and ricotz were hitting this morning [04:49] efifb that grub was using before was fixed last time it was using gfxpayload=keep but looks like its using vesa now and that doesn't work - [ 0.430032] fb0: VESA VGA frame buffer device [05:00] well if anyone comes in saying they are unable to boot maverick tell them to use the vesafb=sucks kernel parameter :) === yofel_ is now known as yofel === Amaranth_ is now known as Amaranth === Amaranth_ is now known as Amaranth [18:51] hi, anyone an idea what would cause bug 605837 ? [18:51] Launchpad bug 605837 in linux (Ubuntu) "After recent updates, X will no longer start with the Nvidia driver on maverick (affects: 2) (heat: 1581)" [Undecided,New] https://launchpad.net/bugs/605837 [21:55] yofel: try booting with vesafb=sucks added to grub? or change gfxpayload=keep to gfxpayload=text [22:47] Sarvatt: already found out in what part the bug is exactly ? is it in the drivers itself ? or in drm ? [22:49] its vesafb not handing over to the kms fb right for some people on intel at least, for nouveau its udev not loading the nouveau module and you're getting the normal drm not ready stuff from the ddx trying to load it [22:51] so for nouveau its an udev bug ? [22:51] looks like it doesn't load nouveau before x starts if you use vesafb [22:52] plus plymouth is just plain busted with vesafb + kms [22:53] not sure, i'm saying what it looks like to me [22:54] vesafb=sucks or gfxpayload=text works fine here [22:54] it'll probably be busted for a long time btw so you might want to use one of those for now :) [22:56] héhé i'll do that :) [22:58] I tought you would have fixed it by monday ;) [22:59] no way, he wants to collect data on it and its far from trivial to fix :) [23:01] i mean it can be fixed trivially but he wants to actually fix it instead of just disabling the option again [23:01] well yea indeed [23:01] better fix it good then use a workaround [23:02] and of course his machine is fine with it like last time it was enabled and all of mine are broken :( [23:03] laptop is broken here also :( [23:03] anyway ;) workaround is activated :) [23:03] did it work? [23:04] dunno :) need to reboot for that, but i'm @ work atm [23:07] removing /var/lib/ureadahead/pack and the nreboot was also a workaround :p [23:07] its a bug with alot of workarounds it seems :) [23:08] vesafb=sucks + FRAMEBUFFER=Y is my favorite, dont need no stinkin vesafb when you have kms [23:10] maby we should make a wiki page with the workarounds :) [23:10] as alot of bugs are created with same issue now