| cnf | hi | 08:43 |
|---|---|---|
| cnf | i don't know if this is the right place, but i have some questions about using preseed. | 08:43 |
| cnf | is there a way to get the installer to ask confirmation for prefilled values? | 08:44 |
| cjwatson | d-i name/of/question string value | 09:31 |
| cjwatson | d-i name/of/question seen false | 09:31 |
| cjwatson | like that | 09:31 |
| 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:32 |
| antarus | heh, that partitioning guide is super outdated | 09:34 |
| antarus | ahh a pointer to the expert recipe syntax! | 09:37 |
| * antarus goes to read | 09:38 | |
| cnf | cjwatson: oeh, shiny, let me try that! | 09:40 |
| cnf | cjwatson: perfect! you are hero of the day! | 09:44 |
| cjwatson | you're welcome | 09:53 |
| patraule | cjwatson: I just read your explanation for OBJ_TYPE_PREFIX, thanks | 10:44 |
| 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:45 |
| 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:48 |
| patraule | true since it's not related to the ubuntu patchset anyway. thanks agian | 10:52 |
| cjwatson | ... but it is related to the Ubuntu patch set | 10:55 |
| cjwatson | sigh :) | 10:55 |
| 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:42 |
| * cjwatson defers to somebody who isn't exhausted from 12.04.2 | 11:44 | |
| cjwatson | sorry, have very little brain today | 11:44 |
| * xnox syncs images.... | 11:48 | |
| ogra_ | hmm, i wonder if thats the same i see on the nexus7 where oem-config exposes a similar behavior | 11:50 |
| * ogra_ didnt get very far yesterday, but i definitely saw issues with ubiquity-dm not starting ... | 11:51 | |
| 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:53 |
| ogra_ | err | 11:54 |
| ogra_ | s/ac100/nexus7/ | 11:54 |
| 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:58 |
| ogra_ | ok | 11:59 |
| ogra_ | there goes my theory of a misbehaving package then | 11:59 |
| ogra_ | thanks ! | 11:59 |
| 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:01 |
| ogra_ | (what dles the installer dm log say ... here i have lots of errors from X trying to start) | 12:02 |
| ogra_ | *does | 12:02 |
| psivaa | no this is after the installation starts fine on vbox, but the dm does not say any errors, let me pastebin it | 12:04 |
| 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:06 |
| 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:21 |
| ogra_ | k, thanks | 12:29 |
| * ogra_ will just dig more into the nexus image | 12:29 | |
| ogra_ | xnox, did your wallpaper fix already land in the archive ? | 13:23 |
| * 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:35 |
| ogra_ | which is when the nexus7 breakage started | 13:36 |
| xnox | ogra_: ubuntu boots and starts fine in the VM. | 13:52 |
| ogra_ | xnox, well, comment #5 on the above bug says ubuntu has it too ... k | 13:54 |
| 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 | 13:56 |
| ogra_ | hmm, k | 14:52 |
| ogra_ | so booting with break=bottom, then remounting /root as rw and removing /tmp/.X0-lock gets me into X | 14:53 |
| ogra_ | hmm, but only once | 14:56 |
| ogra_ | how weird | 14:56 |
| xnox | ogra_: either mountall didn't clean /tmp | 14:56 |
| 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:57 |
| 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 | 14:58 | |
| xnox | ogra_: oem-config starts on starting lightdm which starts on filesystem which means that /tmp has been cleared by mountall | 15:00 |
| 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:01 |
| 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:02 |
| ogra_ | (and having the rootfs rw) | 15:07 |
| ogra_ | and it only seems to work with all three | 15:09 |
| ogra_ | sigh | 15:12 |
| 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:13 | |
| ogra_ | permissions seem fine too | 15:16 |
| gema | xnox: I have a question for you | 15:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| === zequence_ is now known as zequence | ||
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| cjwatson | Possibly, but bear in mind that that would be an interface change | 15:31 |
| 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:32 |
| jcollado | xnox, cjwatson: Sounds reasonable. Thanks. | 15:33 |
| ogra_ | sigh | 15:37 |
| 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:38 |
| * 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:56 |
| xnox | cjwatson: ^ | 15:59 |
| * xnox doesn't see anything obvious with a quick d-i grep | 15:59 | |
| cjwatson | jcollado: no, but main-menu should whine about component failures in syslog | 16:05 |
| jcollado | cjwatson: Ok, thanks. | 16:08 |
| cjwatson | grepping for 'exited with status [^0]' should do it ... | 16:08 |
| jcollado | cjwatson: That's helpful. | 16:09 |
| ogra_ | hmm so booting with rw doesnt seem to change a thing | 16:22 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!