[08:43] hi [08:43] i don't know if this is the right place, but i have some questions about using preseed. [08:44] is there a way to get the installer to ask confirmation for prefilled values? [09:31] d-i name/of/question string value [09:31] d-i name/of/question seen false [09:31] like that [09:32] believe this is documented in the installation guide [09:32] https://help.ubuntu.com/12.04/installation-guide/i386/preseed-advanced.html#preseed-seenflag [09:34] heh, that partitioning guide is super outdated [09:37] ahh a pointer to the expert recipe syntax! [09:38] * antarus goes to read [09:40] cjwatson: oeh, shiny, let me try that! [09:44] cjwatson: perfect! you are hero of the day! [09:53] you're welcome [10:44] cjwatson: I just read your explanation for OBJ_TYPE_PREFIX, thanks [10:45] 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] you'd be better off looking at the source :) [10:48] no point trying to reverse-engineer when you don't have to [10:48] the embedded prefix there is just for the purpose of loading a bootstrap configuration file [10:52] true since it's not related to the ubuntu patchset anyway. thanks agian [10:55] ... but it is related to the Ubuntu patch set [10:55] sigh :) [11:42] cjwatson: Reported bug 1126107 for raring installation failures on KVM [11:42] 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] sorry, have very little brain today [11:48] * xnox syncs images.... [11:50] 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] 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] err [11:54] s/ac100/nexus7/ [11:58] 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] ouch, ok [11:58] ogra_: but the installation goes ok on vbox and there is no /tmp/.X0-lock file as such [11:59] ok [11:59] there goes my theory of a misbehaving package then [11:59] thanks ! [12:01] 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] under /tmp/ that is [12:01] before you get to any X stuff ? [12:02] (what dles the installer dm log say ... here i have lots of errors from X trying to start) [12:02] *does [12:04] no this is after the installation starts fine on vbox, but the dm does not say any errors, let me pastebin it [12:06] you'd expect /tmp/.X0-lock after X is running [12:06] 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] 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] k, thanks [12:29] * ogra_ will just dig more into the nexus image [13:23] xnox, did your wallpaper fix already land in the archive ? [13:24] * ogra_ doesnt see an upload [13:24] 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] and even distilling g-s-d plugin doesn't seem to make it work either. [13:25] 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] xnox, lets just use the compiz plugin then .... flavours should just add their specific wallpaper handler [13:26] just running ubiquity/oem config on the host/installed system works. [13:26] not sure what else has changed on the cd though. [13:27] bug 1123798 [13:27] 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] there are others that dont directly point to dbus but expose similar behavior [13:35] hmm [13:35] https://launchpad.net/ubuntu/raring/+source/gnome-settings-daemon/3.6.4-0ubuntu5 [13:35] debian/patches/nexus_orientation.patch: Wait until a DBus connection to [13:35] the xrandr module is in place before trying to change orientation [13:35] thats from the 12th [13:36] which is when the nexus7 breakage started [13:52] ogra_: ubuntu boots and starts fine in the VM. [13:54] xnox, well, comment #5 on the above bug says ubuntu has it too ... k [13:56] Wow, bug 664526 is a real bug. I genuinely wasn't expecting that. [13:56] 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] hmm, k [14:53] so booting with break=bottom, then remounting /root as rw and removing /tmp/.X0-lock gets me into X [14:56] hmm, but only once [14:56] how weird [14:56] ogra_: either mountall didn't clean /tmp [14:57] well, there is something else too [14:57] ogra_: or we can add that before spawning X in ubiquity [14:57] yeah, i would have added it to ac100-tarball-installer if its device specific though [14:58] 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] ogra_: oem-config starts on starting lightdm which starts on filesystem which means that /tmp has been cleared by mountall [15:01] the point with /tmp/.X0-lock is that X should actually just fal back to the next display [15:01] ogra_: but you only have one. [15:01] ?! [15:01] and just create a .X1-lock [15:01] ?? [15:01] yeah, I'm confused. [15:01] i have as many as i like until it ate up all RAM [15:02] (me didn't manage to start a second x display on a different tty but that's different) [15:02] indeed. [15:02] anyway, i seem to be able to reliably get into X when removing the lock *and* making g-s-d non executable [15:07] (and having the rootfs rw) [15:09] and it only seems to work with all three [15:12] sigh [15:13] 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] permissions seem fine too [15:17] xnox: I have a question for you [15:18] 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] 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] gema: i think cjwatson would be a much better choise. [15:19] As long as it doesn't involve a meeting [15:19] doanac: are you around? [15:19] (overkill for this!) [15:20] cjwatson: we can do IRC no prob [15:20] gema: what do you define as "installation is broken" =) [15:20] xnox: when something has gone so wrong that it is clear there won't be a system to test at the end [15:20] xnox: kind of a "no return" message [15:21] that allows us to kill the install and report a failure [15:21] and preseeding ubiquity/failure_command does fire for you? [15:21] 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] s/does/does not/ [15:22] cjwatson: I guess those cases are hopeless [15:22] 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] It's already called from a last-ditch exception handler [15:22] xnox: tell me more about that ubiquity/failure_command [15:22] how does it work? [15:22] ubiquity ubiquity/failure_command string syslog -t ubiquity OH MY GOD I FELL OVER [15:23] er, s/syslog/logger/ - something that actually works anyway :) [15:23] gema: it's like ubiquity/success_command (a string of shell script that will be executed) but runs when ubiquity falls over. [15:23] https://wiki.ubuntu.com/UbiquityAutomation [15:23] excellent we'll try that [15:24] 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] so the success command is like a heartbeat? === zequence_ is now known as zequence [15:25] gema: neither of them are hearbeat like. [15:25] gema: they are run once at the end and nothing will happen afterwards. [15:25] xnox: then how does the positivee negative stimuli works? [15:26] 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] ok [15:26] gema: if success/failure was reached you will get a message you can act upon -> e.g. run tests, abort. [15:27] ok [15:27] sounds like an improvement from where we are [15:27] jcollado: https://wiki.ubuntu.com/UbiquityAutomation <- ubiquity/failure_command or success_command [15:27] 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] xnox: timeout is what we have at the moment [15:28] but people are complaining that it takes too long to figure out that something went wrong [15:28] gema: a hearbeat would be like watching ubiquity: messages on the rsyslog with a small timeout (e.g. ~2 minutes) [15:28] xnox: ok [15:29] and I belive nuclearbob was working on having rsyslog on all utah desktop installs. [15:29] xnox: What happens if something went wrong in the success_command? Is there any way to detect that? [15:29] xnox: so if not message in say 5 mins, something broke [15:29] xnox: yes, that is almost ready [15:30] 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] cjwatson: should failure_command run if success_command exits with != 0 [15:30] ? [15:30] (currently success_command return codes are ignored) [15:31] Possibly, but bear in mind that that would be an interface change [15:32] 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] true, and from ubiquity point of view - installation did succeed it's a 'presseeder' error in the success_command. [15:32] jcollado can certainly solve his immediate requirement by having the success_command do its own checks [15:33] xnox, cjwatson: Sounds reasonable. Thanks. [15:37] sigh [15:38] so the lock was a red herring [15:38] its definitely not inside the tarball [15:38] so lets try over ... but put rw on the kernel cmdline [15:56] * ogra_ reboots and crosses fingers [15:56] xnox: One more question. Do you know if there's an equivalent of ubiquity/failure_command in debian installer? [15:59] cjwatson: ^ [15:59] * xnox doesn't see anything obvious with a quick d-i grep [16:05] jcollado: no, but main-menu should whine about component failures in syslog [16:08] cjwatson: Ok, thanks. [16:08] grepping for 'exited with status [^0]' should do it ... [16:09] cjwatson: That's helpful. [16:22] hmm so booting with rw doesnt seem to change a thing === JanC_ is now known as JanC