[08:43] <cnf> hi
[08:43] <cnf> i don't know if this is the right place, but i have some questions about using preseed.
[08:44] <cnf> is there a way to get the installer to ask confirmation for prefilled values?
[09:31] <cjwatson> d-i name/of/question string value
[09:31] <cjwatson> d-i name/of/question seen false
[09:31] <cjwatson> like that
[09:32] <cjwatson> believe this is documented in the installation guide
[09:32] <cjwatson> https://help.ubuntu.com/12.04/installation-guide/i386/preseed-advanced.html#preseed-seenflag
[09:34] <antarus> heh, that partitioning guide is super outdated
[09:37] <antarus> ahh a pointer to the expert recipe syntax!
[09:38]  * antarus goes to read
[09:40] <cnf> cjwatson: oeh, shiny, let me try that!
[09:44] <cnf> cjwatson: perfect! you are hero of the day!
[09:53] <cjwatson> you're welcome
[10:44] <patraule> cjwatson: I just read your explanation for OBJ_TYPE_PREFIX, thanks
[10:45] <patraule> I had just hexdump'ed grubx64.efi and all I could find was /EFI/ubuntu in the binary (not /boot/grub), that's why I assumed the former was embedded at build time
[10:48] <cjwatson> you'd be better off looking at the source :)
[10:48] <cjwatson> no point trying to reverse-engineer when you don't have to
[10:48] <cjwatson> the embedded prefix there is just for the purpose of loading a bootstrap configuration file
[10:52] <patraule> true since it's not related to the ubuntu patchset anyway. thanks agian
[10:55] <cjwatson> ... but it is related to the Ubuntu patch set
[10:55] <cjwatson> sigh :)
[11:42] <psivaa> cjwatson: Reported bug 1126107 for raring installation failures on KVM
[11:42] <ubot2> Launchpad bug 1126107 in ubiquity (Ubuntu) "Ubiquity does not start during raring desktop installations using libvirt and KVM " [Undecided,New] https://launchpad.net/bugs/1126107
[11:44]  * cjwatson defers to somebody who isn't exhausted from 12.04.2
[11:44] <cjwatson> sorry, have very little brain today
[11:48]  * xnox syncs images....
[11:50] <ogra_> hmm, i wonder if thats the same i see on the nexus7 where oem-config exposes a similar behavior
[11:51]  * ogra_ didnt get very far yesterday, but i definitely saw issues with ubiquity-dm not starting ... 
[11:53] <ogra_> psivaa, can you take a look at hidden files in /tmp and as well at /var/log/installer/dm ? my ac100 images seem to have /tmp/.X0-lock inside the images which seems to confuse the dm (i wonder if that exists on x86 too)
[11:54] <ogra_> err
[11:54] <ogra_> s/ac100/nexus7/
[11:58] <psivaa> ogra_: this failure is only on KVM based installations on libvirt for me, on those I cant access the logs because there is no responses to any key presses.
[11:58] <ogra_> ouch, ok
[11:58] <psivaa> ogra_: but the installation goes ok on vbox and there is no /tmp/.X0-lock file as such
[11:59] <ogra_> ok
[11:59] <ogra_> there goes my theory of a misbehaving package then
[11:59] <ogra_> thanks !
[12:01] <psivaa> ogra_: sorry i just noticed the 'hidden' file that you mentioned and contrary to what i said there is .X0-lock file, my apologies
[12:01] <psivaa> under /tmp/ that is
[12:01] <ogra_> before you get to any X stuff ?
[12:02] <ogra_> (what dles the installer dm log say ... here i have lots of errors from X trying to start)
[12:02] <ogra_> *does
[12:04] <psivaa> no this is after the installation starts fine on vbox, but the dm does not say any errors, let me pastebin it
[12:06] <cjwatson> you'd expect /tmp/.X0-lock after X is running
[12:06] <cjwatson> ogra_ is talking about a problem he's observed where the filesystem image itself already contains /tmp/.X0-lock and thereby prevents X from starting properly
[12:21] <psivaa> ohh ok, thanks. In that case, i can not see those logs on the failing system but the images don't appear to have /tmp/.X0-lock
[12:29] <ogra_> k, thanks
[12:29]  * ogra_ will just dig more into the nexus image
[13:23] <ogra_> xnox, did your wallpaper fix already land in the archive ?
[13:24]  * ogra_ doesnt see an upload 
[13:24] <xnox> ogra_: no. and i'm failing to make it work. no mater what i do the x root window doesn't get wallpaper painted on it.
[13:25] <xnox> and even distilling g-s-d plugin doesn't seem to make it work either.
[13:25] <ogra_> i see a bunch of bugs that seem to point to ubiquity-dm dieing ... others fall back to the live session then, nexus indeed doesnt
[13:26] <ogra_> xnox, lets just use the compiz plugin then .... flavours should just add their specific wallpaper handler
[13:26] <xnox> just running ubiquity/oem config on the host/installed system works.
[13:26] <xnox> not sure what else has changed on the cd though.
[13:27] <ogra_> bug 1123798
[13:27] <ubot2> Launchpad bug 1123798 in ubiquity (Ubuntu) "ubiquity-dm crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.ConsoleKit timed out" [High,Confirmed] https://launchpad.net/bugs/1123798
[13:27] <ogra_> there are others that dont directly point to dbus but expose similar behavior
[13:35] <ogra_> hmm
[13:35] <ogra_> https://launchpad.net/ubuntu/raring/+source/gnome-settings-daemon/3.6.4-0ubuntu5
[13:35] <ogra_>  debian/patches/nexus_orientation.patch: Wait until a DBus connection to
[13:35] <ogra_>     the xrandr module is in place before trying to change orientation
[13:35] <ogra_> thats from the 12th
[13:36] <ogra_> which is when the nexus7 breakage started
[13:52] <xnox> ogra_: ubuntu boots and starts fine in the VM.
[13:54] <ogra_> xnox, well, comment #5 on the above bug says ubuntu has it too ... k
[13:56] <cjwatson> Wow, bug 664526 is a real bug.  I genuinely wasn't expecting that.
[13:56] <ubot2> Launchpad bug 664526 in ubiquity (Ubuntu Raring) "setting nomodeset in grub, if live session was started with nomodeset" [High,In progress] https://launchpad.net/bugs/664526
[14:52] <ogra_> hmm, k
[14:53] <ogra_> so booting with break=bottom, then remounting /root as rw and removing /tmp/.X0-lock gets me into X
[14:56] <ogra_> hmm, but only once
[14:56] <ogra_> how weird
[14:56] <xnox> ogra_: either mountall didn't clean /tmp
[14:57] <ogra_> well, there is something else too
[14:57] <xnox> ogra_: or we can add that before spawning X in ubiquity
[14:57] <ogra_> yeah, i would have added it to ac100-tarball-installer if its device specific though
[14:58] <ogra_> but there is also something going on with g-s-d, my second attempt hung againg
[14:58]  * ogra_ makes g-s-d non executable
[15:00] <xnox> ogra_: oem-config starts on starting lightdm which starts on filesystem which means that /tmp has been cleared by mountall
[15:01] <ogra_> the point with /tmp/.X0-lock is that X should actually just fal back to the next display
[15:01] <xnox> ogra_: but you only have one.
[15:01] <xnox> ?!
[15:01] <ogra_> and just create a .X1-lock
[15:01] <ogra_> ??
[15:01] <xnox> yeah, I'm confused.
[15:01] <ogra_> i have as many as i like until it ate up all RAM
[15:02] <xnox> (me didn't manage to start a second x display on a different tty but that's different)
[15:02] <xnox> indeed.
[15:02] <ogra_> anyway, i seem to be able to reliably get into X when removing the lock *and* making g-s-d non executable
[15:07] <ogra_> (and having the rootfs rw)
[15:09] <ogra_> and it only seems to work with all three
[15:12] <ogra_> sigh
[15:13] <ogra_> i'm booting without splash and quiet ... and i can see that fsck doesnt complain, everything eles upstart starts boots up fine
[15:13]  * ogra_ doesnt get whats going on
[15:16] <ogra_> permissions seem fine too
[15:17] <gema> xnox: I have a question for you
[15:18] <gema> xnox: we'd like to have some messages in the installer log that allows us to know when to stop waiting for a machine because the installation is broken
[15:18] <gema> xnox: we'd like to set up a meeting to discuss the topic early next week, are you the right person to talk to?
[15:19] <xnox> gema: i think cjwatson would be a much better choise.
[15:19] <cjwatson> As long as it doesn't involve a meeting
[15:19] <gema> doanac: are you around?
[15:19] <cjwatson> (overkill for this!)
[15:20] <gema> cjwatson: we can do IRC no prob
[15:20] <xnox> gema: what do you define as "installation is broken" =)
[15:20] <gema> xnox: when something has gone so wrong that it is clear there won't be a system to test at the end
[15:20] <gema> xnox: kind of a "no return" message
[15:21] <gema> that allows us to kill the install and report a failure
[15:21] <xnox> and preseeding ubiquity/failure_command does fire for you?
[15:21] <cjwatson> We could log something from a top-level exception handler, but what about cases where the installer aborts too abruptly to be able to log anything, or when it doesn't even start?
[15:21] <xnox> s/does/does not/
[15:22] <gema> cjwatson: I guess those cases are hopeless
[15:22] <cjwatson> Certainly there's no reason to suppose that anything we log explicitly would be any more reliable than ubiquity/failure_command, as xnox says
[15:22] <cjwatson> It's already called from a last-ditch exception handler
[15:22] <gema> xnox: tell me more about that ubiquity/failure_command
[15:22] <gema> how does it work?
[15:22] <cjwatson> ubiquity ubiquity/failure_command string syslog -t ubiquity OH MY GOD I FELL OVER
[15:23] <cjwatson> er, s/syslog/logger/ - something that actually works anyway :)
[15:23] <xnox> gema: it's like ubiquity/success_command (a string of shell script that will be executed) but runs when ubiquity falls over.
[15:23] <cjwatson> https://wiki.ubuntu.com/UbiquityAutomation
[15:23] <gema> excellent we'll try that
[15:24] <xnox> gema: i'd suggest to listen for a positive stimuli from success_command and a negative one from failure_command with a timeout for gray state where things fell-over too quickly for ubiquity to report that to you
[15:24] <gema> so the success command is like a heartbeat?
[15:25] <xnox> gema: neither of them are hearbeat like.
[15:25] <xnox> gema: they are run once at the end and nothing will happen afterwards.
[15:25] <gema> xnox: then how does the positivee negative stimuli works?
[15:26] <xnox> gema: well if you didn't reach either of failure/success that means e.g. kernel/X crashed ubiquity didn't start and wait for a timeout.
[15:26] <gema> ok
[15:26] <xnox> gema: if success/failure was reached you will get a message you can act upon -> e.g. run tests, abort.
[15:27] <gema> ok
[15:27] <gema> sounds like an improvement from where we are
[15:27] <gema> jcollado: https://wiki.ubuntu.com/UbiquityAutomation <- ubiquity/failure_command or success_command
[15:27] <xnox> with a timeout you go into 'unknown' state of maybe try again and if that jobs keeps on hitting unknown state something is going horribly wrong.
[15:28] <gema> xnox: timeout is what we have at the moment
[15:28] <gema> but people are complaining that it takes too long to figure out that something went wrong
[15:28] <xnox> gema: a hearbeat would be like watching ubiquity: messages on the rsyslog with a small timeout (e.g. ~2 minutes)
[15:28] <gema> xnox: ok
[15:29] <xnox> and I belive nuclearbob was working on having rsyslog on all utah desktop installs.
[15:29] <jcollado> xnox: What happens if something went wrong in the success_command? Is there any way to detect that?
[15:29] <gema> xnox: so if not message in say 5 mins, something broke
[15:29] <gema> xnox: yes, that is almost ready
[15:30] <xnox> jcollado: wrap your success_command in a try/execpt hook. I guess we can check the return code of succeess_command and run failure_command if the success_command fails.
[15:30] <xnox> cjwatson: should failure_command run if success_command exits with != 0
[15:30] <xnox> ?
[15:30] <xnox> (currently success_command return codes are ignored)
[15:31] <cjwatson> Possibly, but bear in mind that that would be an interface change
[15:32] <cjwatson> i.e. it wouldn't at all surprise me if people had success_command hooks that harmlessly exited non-zero (e.g. the thing where a shell script exits with the exit status of the last command even if you don't use set -e)
[15:32] <xnox> true, and from ubiquity point of view - installation did succeed it's a 'presseeder' error in the success_command.
[15:32] <cjwatson> jcollado can certainly solve his immediate requirement by having the success_command do its own checks
[15:33] <jcollado> xnox, cjwatson: Sounds reasonable. Thanks.
[15:37] <ogra_> sigh
[15:38] <ogra_> so the lock was a red herring
[15:38] <ogra_> its definitely not inside the tarball
[15:38] <ogra_> so lets try over ... but put rw on the kernel cmdline
[15:56]  * ogra_ reboots and crosses fingers
[15:56] <jcollado> xnox: One more question. Do you know if there's an equivalent of ubiquity/failure_command in debian installer?
[15:59] <xnox> cjwatson: ^
[15:59]  * xnox doesn't see anything obvious with a quick d-i grep
[16:05] <cjwatson> jcollado: no, but main-menu should whine about component failures in syslog
[16:08] <jcollado> cjwatson: Ok, thanks.
[16:08] <cjwatson> grepping for 'exited with status [^0]' should do it ...
[16:09] <jcollado> cjwatson: That's helpful.
[16:22] <ogra_> hmm so booting with rw doesnt seem to change a thing