[00:07] LocutusOfBorg: ^^ accepted; as far as future LTS syncing, the release schedule for the point releases is knowable in advance, you can always just pre-upload them and let them sit in dep-wait until the rest of the LTS stack is available [06:54] thanks slangasek, it has sit in my ppa in dep-wait for some time, and I though it was fine to upload when it was buildable... [06:54] next time I'll upload it before thanks [06:57] ^ libwfut and eris are syncs from Debian that used to be in Ubuntu before being removed as part of the GCC 5 transition. [06:57] now requested in the sponsoring queue === davmor2_ is now known as davmor2 [09:29] * apw is handling ^ [09:32] meh [09:33] https://launchpadlibrarian.net/276128735/buildlog_ubuntu-yakkety-amd64.adwaita-icon-theme_3.20-3ubuntu1_BUILDING.txt.gz -> gtk-3-examples -> libgtk-3-0 -> libgtk-3-common -> adwaita-icon-theme (>= 3.20) [09:34] I could build in a PPA without proposed and copy binaries over - it's arch:all [09:34] someone scream if that is terrible === pesari_ is now known as pesari [10:23] done, no point in screaming now [10:31] is there some GTK related issue with proposed, I'm getting https://launchpadlibrarian.net/276121156/buildlog_ubuntu-yakkety-amd64.uim_1%3A1.8.6+gh20160630.0.c408e95-1build1_BUILDING.txt.gz ? [10:32] just related to what Laney said and mentioning gtk [10:32] or is that adwaita fixing the issue? [10:32] i think so [10:32] wait for it to publish out [10:35] * Laney is running watch -n30 rmadison -s -Syakkety-proposed adwaita-icon-theme [10:35] great [10:35] s/-s -S/-S -s/ [10:36] sssssssSSSSSSSSSSsssssSSssssSssssSSSsssS [10:40] infinity: are we not working to a .5 release this week on the tracker? I assume we use daily for now right? [10:51] * Mirv fixes poppler in proposed [11:06] FYI I'm waiting for some investigation / whitelist of failing autopkgtests for a handful of KDE packages, and also waiting similarly for Unity 8, and then Qt 5.6 / KDE transition to release pocket should be possible (or at least nearer to possible) [11:09] davmor2, yes, there should be .5 this week [11:18] infinity: what was crufty with my xorg-lts-xenial upload? I don't see anything here [11:18] on my tree [11:21] infinity: oh the merge conflict stuff.. hmm maybe I cleaned those after upload then [11:23] don't see then on that upload though [11:23] them [11:24] tjaalton: I reuploaded... The one in the rejected queue is quite a bit different than the one I uploaded. [11:25] davmor2: Do some testing with dailies please, yes. I'll upload base-files (no need to file that bug :P), create the milestone and spin RCs after I've napped. [11:27] infinity: got it, didn't delete the unrenamed crap from the git tree once copying over the scripted result [11:27] pitti: Did you sprint take into account an attempt to clean up `reverse-depends -b src:upstart`? Would be nice to fix all that, so people stop doing misguided things like removing s390x binaries. :P [11:28] infinity: I decided to test the apps on the live session instead and makes sure they all open and close and save stuff :) go sleep dude [11:34] infinity: actually we have the opposite problem: many things depend on upstart without saying so [11:34] pitti: Well, both are bad, clearly. ;) [11:34] infinity: ah no, we didn't look at build deps [11:35] infinity: tedg and I looked at porting ubuntu-app-launch [11:35] so that is part of that [11:35] pitti: To be fair, I think we'll have to fix the "s390x" bugs at some point anyway, cause they're not s390x bugs, they're "upstart's testsuite fails on xenial kernel" bugs, and s390x just happened to be the only buildds running xenal during that cycle. [11:35] but https://code.launchpad.net/~ted/unity/systemd-unit./+merge/300584 does not yet drop the build dep [11:35] If we ever try to SRU upstart in xenial, it'll explode on all arches. [11:37] not funny [11:38] xnox: Not funny, but true. :/ [11:38] xnox: I can reproduce the testsuite failures on my laptop. Well, some of them. [11:39] infinity: but at least the libupstart-dev deps can't be dropped yet until we finish the transition [12:22] infinity: hey, any chance you'll get to take a look at those PRs? sorry for poking you, it would just be great to get it done and over with [12:23] tsimonq2: Perhaps after 14.04.5 happens. I have priorities. [12:23] infinity: alright, sounds good [13:49] pitti: If you're still around, a base-files landing in trusty that needs a quick review. [13:51] pitti: ^-- And there it is. [13:51] infinity: I wait a bit until it becomes diffy [13:52] pitti: Kay. I'm going on a coffee run, hoping it's built by the time I get back. ;) [14:03] infinity: (accepted) [14:07] pitti: Ta. [15:40] infinity: I found a couple issues with 14.04.5 regarding nvme drives as well as nvidia cards with the proprietary drivers [15:43] dmj_s76: Regressions? [15:43] infinity: bad ones [15:43] cyphermox: ^-- You know anything about changes to nvme handling between 14.04.4 and 14.04.5? [15:43] with the daily iso, after you install onto an nvme drive, you get dumped to an initramfs prompt [15:43] dmj_s76: proprietary drivers, we can do very little about. [15:44] dmj_s76: To be clear, that's *not* an issue with 14.04.4? [15:44] infinity: That's correct [15:44] dmj_s76: Kay. Is there a bug? [15:44] dmj_s76: If so, can we get some debugging info from .4 and .5? dmesg, lsmod, name of device it's installing to, blah blah? [15:45] infinity: Was just about to file bugs, but wanted to signal a heads up first [15:46] dmj_s76: Is this d-i (ie: server ISO) or ubiquity (desktop/live)? [15:49] dmj_s76, uefi or bios? [15:50] ubiquity. I haven't verified with server yet. [15:50] currently testing on uefi systems [15:50] may affect bios, but I haven't checked yet [15:54] separately, various (all?) versions of the nvidia proprietary driver result in an infinite login loop [15:55] that's a regression from 14.04.4 as well [15:56] hmmm.... does nvidia in 14.04.5 match the right x-server bits and kernel? [15:57] It's meant to. [15:57] Alberto claimed it works. [15:58] His claim may have been incorrect. :P [15:58] there are cirtainly dkms packages which at least build for that combination [15:58] dmj_s76, your efi systems, are they secure boot enabled ? [15:59] apw: We disable secureboot [15:59] are these the uber new nvidia ones ? though i thought we pulled in something for those for you [16:01] I'm testing on both nvidia 9 series (maxwell) and nvidia 10 series (pascal) [16:01] ...you did pull new nouveau support that fixes pascal [16:02] ...into 16.04.1 [16:03] What I'm seeing now, is that nouveau works fine on the maxwell systems (970M and 980), but the moment you install nvidia, you can't get past the login screen [16:10] dmj_s76: Disabled SB from the BIOS, you mean, or the module signature validation disabling thing? [16:10] apw: I assume that patchset it meant to ignore bad/no sigs if SB is entirely disabled. I hope. Did we test that? :P [16:10] s/it meant/is meant/ [16:11] apw: Or were we so focussed on MOK variables that we didn't think of that? [16:12] infinity, as i remember things they are both the same in the kernel both mean "off" [16:12] * infinity might need to slap some USB storage into his nvidia desktop to do some testing. [16:12] Though my card is ancient, so if it's a driver bug, I doubt I'll trip it. [16:12] But if it's something *we* broke.. [16:12] Oh. Wait. My desktop is also ancient and not EFI. [16:12] Derp. [16:13] Ahh, but my old laptop is EFI and nvidia. [16:14] infinity, hmm, when i select proposed in my snap builds i dont actually end up with proposed in the toplevel sources.list ... i assume lp-buildd somehow stores that in a different place ? [16:14] i was trying to add something like: [16:14] ifneq ($(shell grep $(RELEASE)-proposed /etc/apt/sources.list),) [16:14] ENV += PROPOSED=1 [16:14] endif [16:14] to my ubuntu-core makefile [16:14] ogra_: I don't know what "select proposed" means in this context. [16:14] (indeed that would have to be finer grained) [16:14] ogra_: Pointer to the UI you're looking at? [16:15] https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core [16:15] if you click "request builds" (at the bottom) there is an archive selection pulldown [16:15] ogra_: pocket for automatic builds? [16:15] defaulting to Updates [16:16] infinity: It's disabled from the BIOS [16:16] if i select Proposed there i assume that proposed shows up somewhere in my build env [16:16] infinity, jibel: good news I finished testing all the apps installed by default, they all open, close and do stuff as expected woohoo moving onto actual installs now [16:16] but grepping for it in the build logs there seems to be no trace unless i manually add PROPOSED=1 to my ENV var ... (then i get proposed only inside the live-build chroot [16:16] dmj_s76: Can you try running "sudo update-secureboot-policy" and see if that magically makes it happy after reboot and fiddling? [16:16] ) [16:17] ogra_: That sounds like a bug on Colin's part. [16:17] ah, right ... he seems to be off today (i pinged him in #snappy before) [16:17] ogra_: Oh, wait. Are you doing automatic builds, or one-off? [16:18] infinity, nowadays i do them through an lp-lib scripts, but they dont change no matter how i trigger them ... [16:18] proposed never shows up ... neither in manual, nor in automatic, nor in lp-lib triggered ones [16:18] ogra_: When you trigger via the API, it's like asking for a one-off build. You have to specify the right pocket. [16:18] right, i do that [16:18] ogra_: How? Show me the code. [16:19] infinity, ok, shade your eyes ... http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk/view/head:/cron-scripts/lp-build-ubuntu-core thats the api code [16:19] when i change line 68 to "Proposed" i dont see any change in the build logs [16:20] but it really doesnt matter how i trigger the build ... [16:20] they all behave the same [16:20] should launchpad-buildd actually mangle the sources.list ? [16:20] to add -proposed ? [16:21] Yes. [16:21] This is clearly a bug, if it's not working. [16:21] ok [16:21] For example, this is how I build a livefs in a PPA with proposed: lp.load("/~ubuntu-cdimage/+livefs/ubuntu/trusty/xubuntu").requestBuild(archive="/~adconrad/+archive/ubuntu/ppa",distro_arch_series="/ubuntu/trusty/amd64",pocket="Proposed") [16:21] Which is basically your code, but s/livefs/snap/ [16:22] So, if it's not making the outer chroot have proposed for you, someone screwed up. [16:22] Or you can't spell "proposed" [16:22] Pick one. [16:22] it works fine if i export PROPOSED=1 in the live-build call ... so i'll go with that for the moment ... it is just nasty having to change the tree every time i want to toggle it [16:22] Right, you shouldn't have to do that. ;) [16:22] Plus, you want proposed in the *outer* chroot if you're testing against a proposed livecd-rootfs, etc. [16:22] indeed, i was trying to get the info dynamically from the outer chroot [16:22] Which is the point of specifying the pocket. [16:22] Or, one point. [16:23] which is why i sumbled over the issue [16:23] *stumbled too [16:23] So, double-check all your spelling and make sure you're reading your build logs right, and when you're sure you're not doing something Colin will smack you for, report a bug and get grumpy. ;) [16:23] heh [16:29] ogra_, for cloud images i recall having to specify proposed multiple times, in json build config _and_ the target ppa [16:29] sources [16:29] infinity: no, running update-secureboot-policy from the root recovery terminal doesn't fix it (the nvidia issue)...nvme can't get to recovery mode [16:30] xnox, yeah, but then the GUI option in the lp page is pointless ... [16:30] xnox: That's patently untrue. cloud-images are just livefs builds. If you have to specify it more than once, it's because you specified it wrong the first time. :) [16:30] dmj_s76: Did that give you a mokutil thing on reboot, etc? [16:31] infinity, so if the target of the livefs build is a ppa, it must have proposed enabled. as far as i can tell, and then pocket=Proposed needs to be specified in the requestBuild too. [16:31] at least that did the trick for me, way back when i was fiddling with cloud images for s390x [16:32] xnox: Oh, yes. But no json needed there... [16:32] xnox: That's just about archives. [16:32] ogra_: xnox does make a point. The archive you're specifying, what pockets does it build against? [16:32] uh, main only i think [16:32] pockets... [16:32] true. json was for ext4 or some weird thing. all i remember it was annoying =) [16:32] Not components. :) [16:33] ogra_: If it's a PPA, they usually default to updates. [16:33] I think. [16:33] infinity: hrm...no, actually [16:33] "Default (security dependencies and recommended updates)." is checked [16:33] Right, updates. [16:33] ogra_: Change that to proposed and try again. [16:33] hmm, i dont really want the packages in there to build against proposed [16:34] ogra_: I know, just change it and do a test build and change it back. [16:34] i just want proposed packages in the resulting image [16:34] k [16:34] ogra_: If that test build does as you expect, then we at least understand the behaviour. And you can either do your builds in a proposed PPA versus an updates PPA, or we can figure out a way to poke the PPA deps via the API at build time. [16:35] https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/2263 ... [16:35] * ogra_ twiddles thumbs [16:36] i love doing test builds on ppc64el ... nobody uses them in snappy and they are faster than anything :) [16:36] Bah. Didn't see the apt output in the logtail. Now I have to wait. :) [16:36] it takes less than 10min [16:40] ogra_: Those IBM disk controllers are reasonably impressive (in response to your comment on speed) [16:40] I mean, the CPUs are no slouch either, but this is mostly disk. [16:40] yeah [16:40] infinity: There ought to be no secureboot anything going on here. [16:41] Entertaining side note, the storage subsystem of the s390x mainframes is just a POWER system with the same RAID controllers in it as those ppc64el machines. ;) [16:41] heh [16:41] well, i'd use s390x builds for testing if i had that arch in my snap setup yet :) [16:42] but ppc64el is equally good for that purpose [16:42] they are both exotic in the snappy world :) [16:42] and it is done ... [16:43] aaand i see proposed *everywhere* ! [16:43] infinity, so we can use our mainframe as ubuntu ppc64el builders too? [16:43] nice [16:43] so yeah ... obviously the PPA setup is at fault [16:43] ogra_, it works now? [16:44] xnox, well, the outer build chroot shows proposed on apt update ... so yeah ... that was what i was missing [16:44] my prob is that i dont want the packages in the PPA i use to build against proposed ... [16:44] xnox: Only if you can figure out how to install Ubuntu on the storage server and still have it serve slices to the mainframe. :P [16:45] ogra_: Right, so the quick fix is to have two PPAs. Build your packages in your updates PPA, copy them to the proposed PPA, and build updates snaps in A and proposed snaps in B. [16:45] ogra_: The better solution is asking William or Colin if there's a way to set PPA deps per-build via the API and, if not, if they can give us a way. [16:45] yeah, something like that ... but it is a bit sad ... the GUI option should actually override that imho [16:46] (and simply add proposed to the sources.list when i select it) [16:46] ogra_: And I agree, this misfeature is dangerously close to a bug. [16:46] i think there is json to enable arbitrary repos for the "inner build" [16:46] but i can't remember it anymore [16:46] ogra_: Building things this way isn't heavily tested yet, so it might just be a bug. [16:46] need to dig into livebuild lp:lp code [16:47] xnox, forcing the inner build to proposed isnt my issue ... i wanted to cleverly read the info from the outer build so i dont need to change the code every time [16:47] techincally i can build wnat i want today [16:47] ogra_: (ie: it's mostly just been used for one-off livefs testing, and the people who do that a lot probably have the "right" pockets in their PPA and never noticed the issue) [16:47] yeah [16:48] ogra_: So, yeah. File a bug, let's talk it over with the LP folks, but you have a workaround for now at least. [16:48] right [17:05] infinity: nvme: well we know dmj_s76 has filed a bug about nvme in general, which probably needs SRUing [17:06] cyphermox, but apperantely 14.04.5 regressed vs 14.04.4 and we did nothing there, no? [17:06] no [17:06] This is what he claims... [17:06] cyphermox: two separate issues [17:06] Would be nice to get to the bottom of this. [17:06] I wouldn't be able to tell if it regressed, I would expect not [17:06] Ideally today. [17:07] horum [17:07] i have nvme laptop. [17:07] cyphermox: the existing bug applies to bios installs and the ubiquity graphical installer [17:07] cyphermox: Can you work with him to get a bunch of debugging info from .4 and .5 and see WTF is going on, or at least try to make sense of it? [17:07] it's not full system backed up. I don't even know how to do that for a windows & ubuntu dual install. [17:07] xnox: dd [17:07] * xnox ponders if i can try tripple-boot [17:08] the issue in 14.04.5 is separate and applies to successful installs, which get past brub [17:08] *grub [17:08] infinity, that laptop's nvme is a handy 1TB drive =) so i need a spare 1TB somewhere else. [17:08] xnox: That must have cost a bit. [17:08] xnox: wow, that's a sweet nvme [17:08] 1 700 old pounds [17:09] Ouch. [17:09] Mine's a 512 GB [17:09] dmj_s76: please make sure you have a bug for each individual issue so we can make sense of it all [17:09] it has ininity tiny bazel 4k touch screen too, 17" [17:09] Yeah, I thought my 1TB SATA 850 Pro was expensive and fancy, but you've got me beat for extravagant spending. :P [17:09] well 1 700 is for the whole laptop. Just 1TB alone, i can't remember how much it was. [17:10] but then i blagged discount of dell.com/uk chat function (after abandoning shopping cart 3 days in a row) [17:10] (cause they track that) [17:10] Though, in real-world use (not synthetic benchmarks), I wonder how much your nvme really outperforms my sata SSD. [17:10] it doesn't feel any faster than server grade SSDs [17:10] but 1TB on a laptop is nice. [17:11] Yeahp, I enjoy my 1TB SSD. [17:11] Depends on if you're doing a bunch of IO intensive stuff [17:11] My data is goldfish-like, I never need the space, but as soon as I have it, it's full. :/ [17:11] It's nice for manipulating GB+ images for instance [17:13] Oh, FFS Lenovo. [17:13] I don't think my old Thinkpad can disable SB. [17:13] That has to be against spec. [17:13] infinity, really? i am supprised [17:13] which device? [17:13] t420s [17:14] Maybe they didn't think it necessary, since you can bypass it entirely by switching to Legacy BIOS mode. [17:14] weird. X230s could [17:14] where you disable SB, you can put it in Setup mode. [17:14] s/disable/configure/ [17:15] or enable CSM support, which can't allow SB. [17:16] I literally don't have the Secure Boot menu option that I see on screenshots from the **30 series. [17:16] well, it used to not be under Secure Boot specifically [17:16] And that's definitely against spec. [17:17] infinity, my old Gauja laptop hid the SB menu inside the "disk password" sub menu [17:18] cyphermox: do you expect this nvme->initramfs issue will be an ubiquity issue or another package? [17:18] if it's after you've installed, then it's another package [17:19] Oh, I wonder if it's the inverse, that it doesn't support SB at all. [17:19] * infinity tests theory. [17:19] The **30 series might have been the first that was SB-enabled. [17:20] If this experiment goes sideways, I guess I'll be stuck playing in qemu. [17:20] ovmf makes me want to stab myself. [17:23] * xnox derp. got +mac, not -amd64.iso [17:28] ok doing UEFI, no secure boot, trusty desktop install [17:28] with nvme [17:32] Doing the same, minus nvme. [17:32] Well, unsure about secureboot. Could be on, could be off, LENOVO WON'T TELL ME! [17:33] But the kernel will, later. :P [17:33] Maybe. [17:33] is your test machine with nvidia? [17:34] It is. [17:34] Pretty old, but nvidia nonetheless. [17:34] (Well, intel/nvidia optimus mojo, but I have it set to nvidia-only to avoid confusion) [17:35] xnox: nvidia shouldn't matter too much wrt the nvme issue [17:35] After typing on the new Lenovo keyboard for a couple of years, the old keyboard feels really weird. [17:36] install finished, restarting [17:36] omg upstart [17:36] dmj_s76, which kernel module supports your nvme drive ... [17:36] it may or may not restart =) it is ovmf after all [17:39] dmj_s76, confirming drops to initramfs [17:39] in kvm-qemu with uefi and ovmf [17:40] It's a samsung 950 pro... [17:40] i didn't bother seting up nvram storage for variables, but that should not matter, after manually selecting nvme drive in the uefi shell to boot grubx64 it drops to initramfs [17:41] apw, cyphermox - there is no nvme.ko in the initramfs [17:42] lspci reports that it uses the 'nvme' module [17:42] xnox: ok? [17:42] also [17:42] (initramfs) modinfo nvme [17:42] modinfo: cna't open '/4.4.0-31-generic/': No such file or directory [17:43] should't that be like -> /lib/modules/4.4.... ? [17:43] i recall we were patching something rather to include nvme by default [17:43] did that make it back to trusty? [17:43] xnox, well it worked in .4 i think we were told [17:44] apw, sure, but .5 installer is now built with xenial stack [17:44] no? hence it's all different again. [17:45] xnox, right but nvme in the initramfs is an initramfs-tools thing normally [17:46] I see copy_modules_dir kernel/drivers/nvme in xenial initramfs-tools [17:46] but not in trusty [17:47] xnox, indeed ... which would imply .4 would not have worked either [17:47] apw: Or maybe they used a different driver in 4.2 [17:47] apw, infinity - https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?id=fe30453892d21ed20014e48f597be2a79ac99d26 [17:47] infinity, i think at one point it changed to subdir from just nvme.ko [17:48] i do recall uploading that fix into initramfs-tools and saying we will have to backport that to "$foo" or some such [17:48] apw: We should probably sync the driver list from xenial back to trusty (or, rather, add any missing ones, not remove any). [17:48] apw: Any chance I could get you to look at that before you clock out? [17:48] can't remember if that $foo was trusty or $clear-linux [17:48] infinity, yeah will have a look if they are in the same form, if so then it should be easy [17:48] i guess i can boot that system as -sda [17:48] update initramfs with that one line in [17:49] reboot with nvme again to check it's all good [17:49] xnox: Yep. [17:49] because i need to run to beach volleyball in the rain soon [17:49] It was probable in the block subdir before. [17:49] Derpy derp. [17:50] ah comment is nice [17:50] nvme moves to its own directory in Linux 4.4, so include modules [17:50] from there. [17:50] Yep. [17:50] That explains the regression. [17:51] But worth a check of all changes to the module list between trusty and xenial to see if we're missing anything else too. [17:53] ugg they are in utterly differnt forms [17:55] apw: That one spot isn't. [17:55] apw: But yeah, the big lists might be problematic. [17:55] xnox: sounds like you have a fair handle on this, can I ignore that initramfs issue and focus on the other nvme bug with ubiquity? [17:55] with copy_modules_dir a following pokemon appeared in the initramfs [17:55] cyphermox: I think so, yeah. [17:55] kernel/drivers/nvme/host/nvme.ko [17:56] rebooting to test [17:56] umount: invalid option -- 'R' ->>>> argh! [17:56] xnox: you mean "Arrr!" [17:58] cyphermox: I've told you before Ubuntu-Pirate isn't an official release [17:58] killjoy. [17:59] it boots [18:00] xnox: \o/ [18:01] infinity, do i have a bug number for sru upload? [18:02] * xnox makes one [18:02] voila there is one [18:02] https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1608622 [18:02] Launchpad bug 1608622 in initramfs-tools (Ubuntu) "14.04.5 drops to initramfs prompt during boot with nvme drive" [Undecided,New] [18:03] xnox: I have apw trying to reconcile the whole module list, not just nvme. [18:03] xnox: If he fails at that, we'll just fix this one bug. :P [18:03] dmj_s76: What's the nvidia behaviour you see? [18:03] i recall that was the only thing i had to fix. [18:03] dmj_s76: I can confirm the driver sucking here, though not sure if it's the same as your suck. [18:04] could it be a SB issue? [18:04] xnox: The only thing you had to fix... In trusty? [18:04] xnox: Or xenial? [18:04] xnox: Cause they've diverged a lot. :P [18:04] trying to remember [18:04] cyphermox: module loads fine, so no. [18:04] kay, just checking [18:04] cyphermox: compiz explodes spectacularly on login. [18:05] ah [18:05] that's not a regression [18:05] infinity, ^ above is just cherrypick copy_modules nvme [18:05] well [18:05] cyphermox: It's not? [18:05] infinity: nevermind, I was thinking of something else [18:06] infinity: Are you getting a reboot loop? [18:06] *login loop [18:06] (not reboot) [18:06] dmj_s76: No, I'm getting compiz freezing hard after login. [18:07] dmj_s76: But could be the same thing, behaving differently on different cards. [18:07] dmj_s76: To confirm, X starts, lightdm is fine, you can login, then world explodes? [18:07] * xnox the world does not explode in kvm/qemu after fixed initramfs hook as per above sru [18:07] * xnox is out for volleyball [18:08] infinity: I suspect so...on mine, when I login, there's a yucky crashy behavior for a split second, then back to lightdm [18:08] dmj_s76: Right. So, yours might just recover better from the same thing. Maybe. [18:08] What driver are you using? [18:08] dmj_s76: That's the 352 driver? [18:09] I've experienced this issue with 352 and 367 [18:09] and 361 [18:09] Nothing newer than 352 exists in trusty, afaict. [18:10] infinity: We package 361 (and soon 367) for hardware compatibility. [18:11] tjaalton: Remember when tseliot told us that this HWE-X + nvidia thing was tested? Was that a lie? [18:11] ...at first I thought it might be some packaging quirk, but it's hitting 352 the same way. [18:12] infinity: I don't know? [18:12] tjaalton: Do you have nvidia hardware to help test and get to the bottom of this? [18:12] tjaalton: Cause it sure looks broken to two of us... [18:13] i have an old 8600gt somewhere [18:13] but a logfile would be nice to see [18:13] if it crashes back to lightdm [18:13] tjaalton: which logs would you like? [18:13] Mine hardlocks. But dmj_s76 gets a nice loop, so he might be helpful. [18:14] dmj_s76: /var/log/Xorg.0.log.old [18:14] pastebinit [18:14] And dmesg, perhaps. [18:14] I get the same breakage with 340 and 352. Highly suspect. [18:14] is the dkms built? [18:15] Built, and it loads. [18:15] Well, it loads manually. [18:15] Hard to say if it loads automatically, because locked computer. ;) [18:16] the system hangs hard? [18:16] With 352, I get the nvidia logo, though, which I'm pretty sure won't happen unless the module loaded. [18:16] And compiz draws a bit of purple. [18:16] yeah, think so [18:16] And then explodes. [18:16] Yeah, hung hard. Can't VT switch or anything. [18:16] Well. [18:16] Display hung hard. [18:16] I should install sshd to see if it's otherwise alive. [18:16] * infinity reboots again. [18:21] tjaalton: Alright, machine not hung, just display. [18:21] good [18:22] tjaalton: Xorg logs don't seem angry in any way. :/ [18:22]