[00:12] <cyphermox> what dir?
[00:18] <cyphermox> ahoneybun: the commands I gave you will do everything for you; after you've branched lp:ubiquity, you 'cd ubiquity', then 'make -C d-i/ update' and what is required will be downloaded automatically for you. This is necessary because what ubiquity does is make use of parts from d-i, they need to be in sync rather than having to do changes in two places when they affect both desktop and server
[00:18] <cyphermox> http://paste.ubuntu.com/23109690/
[00:18] <cyphermox> ^ this is part of a typescript of me running through the steps, it works.
[00:45] <ahoneybun> I know the logic, just saying on LP it does not
[00:45] <ahoneybun> I know that is works
[01:38] <cyphermox> I don't understand what you're saying; ubiquity clearly builds fine here, and in the archive. if it doesn't work for you, best is to share exactly what you do, somewhere like in a pastebin. I'm going to bed now though
[04:44] <CarlFK> http://archive.ubuntu.com/ubuntu/dists/trusty/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/linux and initrd.gz
[04:44] <CarlFK> segfault in libresolve-2.19
[04:45] <CarlFK> but not right away.  it is able to wget my early script.. hmm.. stand by for more.
[05:23] <CarlFK> anna[3859]: DEBUG: retrieving libc6-udeb 2.19-0ubuntu6.9 ... anna[3859]: DEBUG: retrieving libcryptsetup4-udeb 2:1.6.1-1ubuntu1
[05:23] <CarlFK> kernel: [   32.624724] wget[5138]: segfault at 14 ip 00007f2ac2defd46 sp 00007fff68531710 error 6 in libresolv-2.19.so[7f2ac2de4000+17000]
[05:25] <CarlFK> not sure what more or where to report.
[13:54] <jalt> Hi, how can I debug ubiquity/success_command post-preseeded-install? I had it working fine and now it doesn't seem to be running anymore, and I'm not sure what changed. I checked the logs at /var/log/installer and I can't seem to find anything related to success_command. Any tips?
[14:01] <cyphermox> you could run the installer again with 'debug-ubiquity' added on the kernel command-line as you boot; that will write a bit more stuff to the logs in /var/log/installer/debug.
[14:01] <cyphermox> perhaps one of the commands necessary wasn't found?
[14:01] <cyphermox> or failed early so the rest of the script didn't run?
[14:03] <jalt> that was my initial thought, but now there is only a single command. i'll add debug-ubiquity and see if more info comes out.
[14:04] <cyphermox> what's the command?
[14:04] <jalt> eject ;)
[14:04] <cyphermox> have you looked at syslog too?
[14:04] <cyphermox> hrm
[14:05] <cyphermox> I suppose eject may have changed a bit? I recall some bug from a while ago
[14:05] <jalt> all was working fine yesterday, and the changes i did to the preseed file should have not caused any trouble.
[14:05] <jalt> nah, eject was working well for the past two weeks
[14:06] <cyphermox> right, then the other changes must have affected it ;)
[14:06] <jalt> i probably messed up somewhere, but it's hard to debug without any useful info in /var/log/installer
[14:06] <cyphermox> otherwise, if you're doing installs of the devel release, other things in the set of packages we install may have broken
[14:06] <cyphermox> jalt: I usually look at syslog there; and much less dm
[14:06] <jalt> no, xubuntu 16.04.1 desktop iso
[14:07] <cyphermox> syslog typically has quite a lot of the required information
[14:07] <jalt> it has no information about the success_command
[14:08] <jalt> debug has some info about some of the debconf stuff, but that's about it
[14:08] <cyphermox> the debug log would have to mention it; success_command is retrieved from debconf
[14:08] <jalt> it never mentioned it, even when it was working
[14:08] <cyphermox> can you share the logs?
[14:08] <jalt> sure, once the current install finishes
[14:10] <jalt> in the meantime, here's the preseed: http://pastebin.com/7TCBtQwR
[14:19] <jalt> hmm logs are too big for pastebin
[14:21] <jalt> the debug-unity added some stuff that shows that the success_command was read from the preseed file, but nothing about it running or not.
[14:36] <cyphermox> jalt: should eject really be in-target?
[14:36] <cyphermox> seems to me like it probably doesn't need to be
[14:37] <cyphermox> (in-target is a chroot, with /dev probably bound-mounted into it; eject on the "real" system should work fine)
[14:37] <jalt> hmm that is a good point. in any case, i restored an older version of my preseed and that one worked
[14:38] <jalt> the diff is minimal, most of it comments, so maybe it's some issue with spaces or newlines... i'll investigate a bit further. thank you for the help cyphermox
[14:38] <cyphermox> did you change the tasksel line?
[14:39] <jalt> nope, that one isn't even read. i keep it there as a label mostly
[14:39] <cyphermox> oh, right, you're using a CD with a livefs, obviously
[14:41] <jalt> actually a dd'ed usb drive, but same difference.
[14:50] <jalt> hmm i might have spot the culprit: a stray space between string and the command though it should not matter to have it preceding the command... ("Put only a single space or tab between type and value: any additional   whitespace will be interpreted as belonging to the value.")
[15:14] <cyphermox> spaces in commands shouldn't matter
[15:22] <jalt> and yet they did and it's now working again, cyphermox.
[15:27] <cyphermox> interesting
[15:27] <jalt> ¯\_(ツ)_/¯