[09:54] mpt: we have a keyboard bug for every step of the installer [09:54] https://wiki.ubuntu.com/Ubiquity/KeyboardBug#preview [09:54] https://wiki.ubuntu.com/Ubiquity/KeyboardBug [10:35] joy [10:39] Yeah, it's like christmas came early =) [10:40] The best bit is when people need/want to switch to English after booting in e.g. russian locale at every single step. [11:06] xnox, do you happen to have a screenshot of the 12.10 installer with the wi-fi spinner at the bottom left? [11:08] mpt: no, as I failed to type my 63 character long WiFi correctly to trigger the spinner. [11:08] s/WiFi/WiFi password/ [11:08] * xnox can fake a screenshot for you though. [11:42] mpt: https://picasaweb.google.com/105922848292507689403/February182013#5846255791327235314 [11:42] nexus7 saves the world again [11:45] xnox, erm, how did you get that working ? [11:45] ogra_: which part? =) [11:46] the whole of it [11:46] how did you work around my bug ? [11:46] ogra_: so my old nexus was already pre-flashed, I $ sudo apt-get install oem-config-gtk etc... & sudo touch /var/oem-config/run & reboot [11:47] it just works. [11:47] hmpf [11:47] why doesnt it on fresh images then [11:47] i may not be fully up to date then. [11:47] do you want me to dist-upgrade and see if it breaks? =) [11:47] yes please :) [11:50] * ogra_ is a little desparate to find *any* pointer to whats wrong [11:54] xnox, excellent, thank you [11:54] discussing this layout pattern right now [12:06] ogra_: dist-upgrade, reboot, had plymouth splash and now just black screen with nothin on it. [12:06] here is the dpkg view of my dist-upgrade: http://paste.ubuntu.com/1676722/ [12:06] YAY !!!! [12:06] grep for upgrade [12:07] and install [12:07] sigh, 164 packages [12:07] * xnox was spending time fixing background which now works =) and not dist-upgrading [12:09] ogra_: how can I boot it now? [12:09] remove the lock [12:09] that sometimes works [12:10] i havent found a reliable way yet, it seems to be very random [12:11] do you have an ssh server installed ? probably the logs on an installed system are more verbose [12:11] yeap ssh'ed in. [12:11] Fatal server error: Server is already active for display 0 [12:11] yeah [12:12] complaining about the lock, as well, right ? [12:12] thats all i can get ... i wish there was an ~.xession-errors for u-dm [12:13] right in syslog I see the same stuff as currently seen in the daily desktop images with "Failed to activate service 'org.freedesktop.ConsoleKit' timed out [12:14] and consolekit failing to acquite the bus [12:15] * xnox wonders if the first X is started ubiquity-dm, then ubiquity-dm fails, and respawns a new X without cleaning the lock. [12:15] (killing the first instance) [12:16] yes, thats one of my three theories [12:16] the most compelling one actually ... else it would be lightdm or upstart which is unlikely [12:16] thats why i would like an .xsession-errors file [12:17] since i guess one of the fired up apps u-dm uses is at fault here [12:17] and oem-config-debug sadly only kicks in after oem-config is up [12:18] it's weird because there is console-kit-daemon running with pid 965, yet the one that failed to activate has pid 1263 [12:18] so it failed to talk to it. [12:18] hmm [12:19] i see qdbus in your upgrade list [12:20] nothing about consolekit or polkit [12:21] theoretically there is an Xsession.d script that firse up the appropriate ck session for you [12:21] (unless you use lightdm) [12:22] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680264 [12:22] Debian bug 680264 in nodm "nodm: ConsoleKit fails to recognize the current session as local" [Normal,Open] [12:22] i wondefr if thats related [12:23] it has a patch to try out [12:23] there were some pam changes [12:24] also, slangasek seems to have moved soem pam stuff around in lightdm from "auth" to "session" that tries to read /etc/default/localer ... which doesnt exist in our installer env [12:24] also ubiquity launches X directly does that read / launch xsessions? [12:24] though you should have it on an installed system indeed [12:24] i think it does, not sure [12:24] hmm, it doesnt launch xinit but plain X [12:25] so Xsession might ot be processed [12:26] once my nx7 is charged enough i'll try your method ... it didnt strike me to test on an installled system [12:26] ehhhh [12:27] mpt: did you just read the backlog? =) or is that the comment on the font/spacing alignment of the connecting label? [12:28] xnox, I'm in a meeting where we're talking about bug 732634 for the umpteenth time :-] [12:28] as if it was ever a deliberate design choice [12:28] or just a general statement to the evilness of the world ? [12:28] Launchpad bug 732634 in ubiquity (Ubuntu) "Progress bar restarts from zero after copying files" [Medium,Confirmed] https://launchpad.net/bugs/732634 [12:29] mpt: refresh the bug report, does that help? [12:31] \o/ [12:32] That bug is darkly amusing since it has comments like "The proper solution is apparently to teach debconf that its progress value is sometimes only for a subtask of a larger task" several years after such support was introduced [12:32] It's just broken, it's not fundamentally missing [12:33] xnox: Do you know about and understand the PROGRESS REGION extension? [12:33] cjwatson: know about - yes, understand - sort of. [12:34] Your bug reference is incorrect - nested progress bar support was introduced long before that [12:34] Before espresso was renamed to ubiquity [12:34] r799, originally [12:35] geez, installing oem-config-gtk tries to pull in nearly all of kde here [12:35] even with recommends disabled [12:35] =)))) well, ok that it even early, for me at that time it was good enought that _it exists today_ [12:35] ogra_: install oem-config-gtk ubiquity-frontend-gtk [12:35] and oem-config and ubiquity then it's a short list. [12:35] yep, just did that :) [12:36] it is trying to pull in the kde frontend for some reason, instead of the gtk one. [12:36] xnox: The idea is that you say PROGRESS REGION , then PROGRESS START ... (more progress commands) ... PROGRESS STOP, and the progress commands within the start/stop pair are scaled to the region you provided [12:37] <cjwatson> IIRC [12:38] <cjwatson> So have a look at the protocol stream and see what's doing it wrong [12:39] <xnox> ok. thanks. debug mode logs again =)))) [12:39] <cjwatson> That's what they're for :) [12:40] <xnox> cjwatson: i think we are missing some progress regions then, as if one does progress start 0 without starting a new progress region you see the jump to zero effect. [12:40] <ogra_> 1405 ? S 0:00 /usr/bin/python3 /usr/bin/ubiquity-dm vt7 :0 oem /usr/sbin/oem-config-wrapper --only [12:40] <ogra_> 1431 ? S 0:00 sleep 1 [12:40] <ogra_> 1432 ? Z 0:00 [Xorg] <defunct> [12:40] <cjwatson> Yep, very likely [12:40] <ogra_> aha [12:40] <ogra_> i wonder wheer that zombie comes from [12:40] <cjwatson> Should be a pretty trivial fix once identified [12:41] <xnox> ogra_: in ubiquity-dm we have a loop of trying to start X server and if it fails so many times, we try fail-safe config. [12:41] <ogra_> yeah, i had that at some point during my tests [12:41] <ogra_> i wish there would be any indicator in any log though ... [12:42] <xnox> ogra_: it's python - so just type in more logging =) [12:42] * ogra_ digs into the dm and scatters soem prints over it [12:50] <xnox> ogra_: anything in /var/crash/ ? [12:50] <ogra_> wait, just rebooting [12:54] <ogra_> http://paste.ubuntu.com/1676848/ [12:54] <ogra_> definitely CK [12:55] <xnox> ogra_: can you grep if there are any console-kit daemons running any way? [12:55] <xnox> in ps. [12:55] <ogra_> i wonder if we should just switch to process Xsession [12:55] <xnox> cjwatson: why ubiquity-dm has never been a proper Xsession? [12:55] <ogra_> ogra@nexus7:~$ ps ax|grep console [12:55] <ogra_> 956 ? Sl 0:00 /usr/sbin/console-kit-daemon --no-daemon [12:56] <xnox> so it's failing to talk to it. [12:56] * xnox ponders to try that debian patch or see/revert recent slangaseks pam changes. [12:56] <ogra_> well, i think it is started in the wrong order [12:57] <xnox> ogra_: the first thing ubiquity-dm does is ask for a console-kit session, which should dbus activate it. [12:57] <ogra_> yes, but it doesnt take care for starting it [12:57] <ogra_> which usually Xsession woudl do [12:57] <xnox> so who started the one that is running?! [12:57] <cjwatson> xnox: Too much effort to excise all the bits we wanted to avoid [12:58] <cjwatson> There were memory constraints and the like - I explicitly didn't want to run a full session [12:58] <cjwatson> Or a full DM [12:58] <xnox> ok. [12:58] <cjwatson> I mean I guess you could split ubiquity-dm into a DM part and a session part. It just never seemed worth the effort really [12:59] <ogra_> well, with the recent diet lightdm might serve out purpose [12:59] <cjwatson> ubiquity-dm can't rely on lightdm [12:59] <ogra_> hmm, indeed flavours ... [12:59] <cjwatson> 'cos it needs to be workable in lots of different flavours, yeah [13:00] <ogra_> oh [13:00] <ogra_> erm [13:01] <ogra_> seems teher is no session dbus at all running here [13:01] <ogra_> i would assume thats needed for ck to talk to the system bus through it [13:03] <xnox> but we are starting on lightdm, which in turn starts on dbus. [13:04] <ogra_> system [13:04] <ogra_> not session [13:04] <ogra_> the session bus is started by gnome-session or alternatively by Xsession [13:04] <xnox> upstart jobs that is. [13:04] <xnox> ah, wait. [13:04] <ogra_> it runs as the session user usually [13:04] <ogra_> so after auth [13:05] * xnox thought ck runs on system bus, not session. [13:05] * ogra_ tries to mimic the Xsession behavior in the oem-config.conf exec line [13:05] <xnox> cause ck is opened before ubiquity-dm starts a session bus [13:06] <ogra_> the point is that to talk to system services the session bus is used i think [13:06] <ogra_> with ck inbetween for policy checks [13:08] * ogra_ reboots with the hack in place [13:11] <ogra_> bah, patched the wrong codepath [13:18] <ogra_> hmm, so i have it starting with a session bus but it doesnt change anything :( [13:19] <ogra_> oh, lovely ... at least i can count how often it respawned now [13:22] * ogra_ moves the code around a bit [13:34] <ogra_> GOT IT !!! [13:34] <ogra_> bah, only partially [13:35] <ogra_> changing the exec line in oem-config.conf to: [13:35] <ogra_> exec /usr/bin/ck-launch-session oem-config-firstboot $debug $automatic [13:35] <ogra_> gets me running X and a popup that the installer encountered an error on the desktop [13:36] <ogra_> aha [13:36] <ogra_> dbus.exceptions.DBusException: org.freedesktop.NetworkManager.Settings.NotPrivileged: Insufficient privileges. [13:36] <ogra_> thats funny ... [13:36] <ogra_> since i have NM in the panel [13:37] * xnox reverted lightdm, consolekit and it boots now [13:37] * xnox ponders if consolekit's memory leak wasn't actually a memory leak. [13:39] <ogra_> oh, i created an oem user for testing ... i guess i should swithc that back to root as we use it on the image [13:42] <ogra_> yipiie [13:42] <xnox> you fixed it? =) [13:42] <ogra_> ogra@nexus7:~$ grep exec /etc/init/oem-config.conf [13:42] <ogra_> exec /usr/bin/dbus-launch --exit-with-session /usr/bin/ck-launch-session oem-config-firstboot $debug $automatic [13:43] <ogra_> with that it works for me [13:43] <xnox> it also needs to go into ubiquity normal as it also fails with ~ similar symtoms. [13:43] <xnox> and this also means we can drop dbus-launch code from ubiquity-dm [13:43] <ogra_> well, i still think it would be better to just process Xsession.s [13:43] <ogra_> Xsession.d [13:46] <xnox> my boot was a fluke as it is back to booting black. [13:48] <ogra_> hmm [13:48] <ogra_> none of the indicators work ... i can select reboot but never get the popup for it [13:48] <ogra_> so i would guess its not 100% yet [13:52] <ogra_> btw, the panel doesnt expand in landscape [13:53] <xnox> ogra_: so poking indicator-session-service it's sitting on the dbus that lightdm has, instead of ours. [13:53] <ogra_> ah [13:53] <ogra_> thats a mess [13:54] * ogra_ is so happe we found the cause and at least a workaround ... i wated my whle weekend on this (including my birthday on sat.) [13:54] <ogra_> *happy [13:55] <ogra_> *wasted [14:23] <xnox> ogra_: looking at all the Xsession.d scripts some of them are definately what we do not want. [14:24] <ogra_> hmm, yeah === zequence_ is now known as zequence