=== dendro-afk is now known as dendrobates [04:18] Good morning [04:19] SpamapS: I answered to 876959 yesterday === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [05:19] http://packages.qa.debian.org/d/dpatch/news/20111024T000209Z.html \o/ dpatch deprecated for new packages in Debian... [05:20] This is terrible news. [05:21] StevenK: that's is deprecated or only for new pacakges? [05:21] No, that it is deprecated at all. [05:22] quilt can go DIALCF [05:23] * micahg ♥ quilt [05:27] * RAOF can get right behind StevenK's quilt hate. [05:29] * micahg wonders why people hate quilt [05:30] quilt push -a ; quilt new ; edit file ; OHDAMNITIFORGOTQUILTADD [05:31] for more extensive edits there is also quilt shell [05:31] I just want a patch system, not a VCS wannabe [05:32] And a buggy VCS wannabe, at that. [05:32] StevenK: src format 3 FTW, just make your changes debuild -S, you have a patch :) [05:32] Ugh, format 3 [05:32] I love it, no more forgetting quilt add... [05:41] Although now you get to play the game of disentangle the multiple patches! [05:53] * nigelb <3 quilt as well. [05:54] StevenK: Its even more awesome when you use quilt with UDD. [05:54] ;) [05:54] (that's the only quilt use case I absolutely hate) [07:07] good morning [07:13] gmorning! [07:17] Where can I find unity-2d-panel source? It's having problem adjusting it's width on multi monitor setups. [07:17] (on launchpad that is) [07:18] hello everyone! i keep seeing problems reported with read-only file systems by users that followed some guides involving the recovery mode (as this seems to have changed in oneiric). [07:18] wouldn't it be more convenient to offer a 'read-only' menu item rather than making users first use 'remount' and then 'root'? [07:31] speakman: https://code.launchpad.net/~unity-2d-team/unity-2d/oneiric (project page is https://launchpad.net/unity-2d) [07:34] geser: thx m8 :) [07:40] (I'm about to post a bug report for this, but are there any tools to print the current resolution of each monitor attached?) [07:46] Using Xinerama [07:54] Is there any magic I need for apt-cache to show long descriptions again? [07:56] StevenK: it always did? [07:56] no magic should be needed. perhaps your mirror has failed to mirror the Translations-* files? [07:56] Oh [07:56] * StevenK kicks apt-mirror [07:57] debmirror works fine [07:58] I suspect I'm back to a postmirror script to wget the en translations [08:21] StevenK: do please file a bug against apt-mirror about this, though [08:23] cjwatson: I got distracted by writing a suitable postmirror script, but will do [08:25] cjwatson: Already filed: https://bugs.launchpad.net/ubuntu/+source/apt-mirror/+bug/368419 [08:25] Launchpad bug 368419 in apt-mirror (Ubuntu) "apt-mirror i18n files" [Wishlist,Won't fix] [08:27] hmph [08:28] cjwatson: Exactly what I thought [08:28] * cjwatson comments [08:39] speakman: xrandr --verbose [08:56] RAOF: I'm on Xinerama so xrandr doesn't work. I used nvidia-settings GUI instead. [08:58] tkamppeter_ : any idea when openprinting.org will see life again ? (linuxfoundation.org/…/openprinting works though, so maybe just a matter of redirects) [09:03] hi [09:03] I'd like to report a bug but I'm not sure which component is responsible for this [09:03] I cannot shut down my clean-install oneiric [09:03] selecting shut down simply logs me out, selecting shut down from lightdm does nothing [09:03] is it a lightdm bug? [09:04] could be a lightdm or consolekit problem [09:09] pitti, any clue on where to look, syslog has nothing while I try to shut down [09:09] no idea, perhaps start with filing a bug against lightdm, to include /var/log/lightdm/lightdm.log [09:09] that might have a clue [09:10] also ~/.xsession-errors when you try to shutdown from your session === doko_ is now known as doko [09:10] pitti, thanks for the hint, I'll try to shut down now === dendrobates is now known as dendro-afk [09:26] pitti: thanks [09:27] * SpamapS should not be awake but stupid smoke alarms went off because their batteries had died [09:31] http://people.canonical.com/~clint/bootchart.png .. anybody know what would cause check-new-relea to be run at boot time? [09:32] I think its update-motd [09:32] /etc/update-motd.d/91-release-upgrade -> /usr/lib/update-manager/release-upgrade-motd -> /usr/lib/update-manager/check-new-release [09:32] cyphermox: fyi, usb-modeswitch linked against libjim uploaded to Ubuntu. Tests and comments appreciated… [09:33] meh. s/Ubuntu/Debian/ [09:33] cjwatson: ahh thats why greps didn't work [09:34] seems like we could delay a bit... its a rather busy command [09:36] or am I reading the rather non-decipherable colors wrong and its a zombie most of the time? :-P [09:36] SpamapS: certainly not; checking apt stuff during boot is ridiculously expensive [09:36] (or anytime during login, really -- it causes VT logins to hang for a long time) [09:37] at least they used to in the past, it took about 5 seconds for me [09:57] pitti: all of update-motd feels like something that can wait until the first login.. or 5 minutes after first boot even. [09:58] SpamapS: btw, red means "iowait", i. e. processes blocking on disk activity (usually waiting for data to read) [09:58] pitti: "red" ? [09:58] on rotary disks, the heavy apt stuff can block quite a bit [09:58] I see only white [09:58] SpamapS: on the bootcharts [09:58] or blue [09:58] I see a fair amount of red on your charts [09:59] you don't seem to have an ureadahead cache [09:59] dpkg-reconfigure ureadahead maybe? [09:59] presumably this is from a boot right after you changed something in the boot sequence (perhaps you installed bootchart and this is the first boot after it?) [09:59] or that :) [09:59] no after 10 slow boots I got frustrated [09:59] usually, after you do this, you boot to a desktop, wait for a minute, remove all old charts, and reboot again [10:00] this is the third boot-chart measured boot [10:00] but, seriously, no red [10:00] its like we have a different pallete or something [10:00] your CPU gets bored to death, the entire boot is one huge big red IOwait condition, and your HDD doesn't get to shovel more than some 5 MB/s into the RAM [10:01] SpamapS: I'm looking at http://people.canonical.com/~clint/bootchart.png [10:01] SpamapS: well, it's a relatively light red, more like pink [10:01] yeah, I see pink, blue, white, no red [10:01] the colors are fairly hard to distinguish from one another [10:01] they mostly just look like shades of gray [10:01] really? there are only four: white, black, blue (CPU), pink (IO wait) [10:02] except the green ;) [10:02] ah, right [10:02] so your boot is entirely stuck on utterly slow data reading [10:02] in theory ureadahead ought to help there quite a bit [10:02] you have one or two peaks with 40 MB/s, but most of the time only a tiny fraction of that [10:03] yeah I wonder why ureadahead hasn't been updated [10:03] SpamapS: try a comparison with disabling that apt script? [10:03] since 9/20! [10:03] SpamapS: if it is, you should have /var/lib/ureadahead/*pack [10:03] oh I hav eno packs, just debugfs [10:03] hm [10:04] SpamapS: do you have /etc/init/ureadahead.conf ? [10:05] yes indeed [10:05] hm, so perhaps it fails for some reason to write the pack files [10:05] it was in fact running during bootchart [10:06] SpamapS: http://people.canonical.com/~pitti/bootcharts/tick-lucid-20100622-standard.png [10:06] are we graphing bootchart somewhere btw? [10:06] that's from my utterly slow latitude d430, its disk really sucked (20 MB/s) [10:06] but even there ureadahead saved some 30 or 40 seconds [10:06] I swear we do *way* too much manual testing [10:06] SpamapS: yes [10:06] http://reports.qa.ubuntu.com/reports/boot-speed/ [10:06] the beginnings of it, anyway [10:07] cool [10:08] I'm going to reboot with console output in /etc/init/ureadahead.conf [10:09] I think you may be right that its not writing the pack files [10:09] SpamapS: oh, how do you get the console output of a job? [10:10] so far I kludged that with something like "exec 2>/tmp/log; set -x" in the pre/post-start scripts [10:10] pitti: ctrl-alt-f7 ;) [10:10] (to debug these particular parts) [10:10] ah, ok; no magic cookie [10:10] might end up in /var/log/boot.log too [10:10] but thats hit or miss [10:11] pitti: I think jhunt is working on a dmesg-like thing for job output buffers [10:11] * SpamapS reboots... [10:12] hmm, is mom not working (or did we stop isung it) 8 merges for main doesnt look much [10:13] ogra_: Think you clicked on the manual link :-) [10:13] look above [10:13] https://merges.ubuntu.com/main.html looks fine [10:14] Laney, lol, yeah, you are right [10:14] thanks ! [10:14] i did the same the other day [10:14] and no we have not stopped using MoM [10:15] obviously ... as long as the user can read it even works as expected ;) [10:22] pitti: ok, so I just realized I uninstalled/reinstalled bootchart between runs... i wonder if something it does during its install removes the pack files. They're there now [10:22] * SpamapS needs to go back to sleep. Stupid smoke alarms [10:23] SpamapS: yes, bootchart changes the boot sequence; the pack files are removed, triggered by changes to /etc/init [10:28] pitti: thats what I thought.. so my first 2 were probably more accurate ;) [10:31] cjwatson: do you have an opinion about bug 873401? should live-build not write a header to the md5sum.txt file, or can we fix gfxboot's checksum thingy (I don't know which package that is) to ignore the header? [10:31] Launchpad bug 873401 in live-build (Ubuntu) "Check disc for defects failed with a iso images built using ubuntu-defaults-image" [Low,Triaged] https://launchpad.net/bugs/873401 [10:34] the latter. I'll deal with it [10:34] and it has nothing to do with gfxboot :) [10:34] I thought so, but for the lack of a better name :) [10:34] what part does that, OOI? [10:35] see the bug [10:35] (reassigned and such) [10:35] ah, casper, nice [10:35] thanks [10:54] slangasek: I guess it was removed by upgrading to 11.10 [10:54] slangasek: there should be some docu that states that fact, would have helped me a lot [10:58] slangasek: thanks for the info ;) [10:59] it would have taken specialised gymnastics to have libc6:i386 installed before upgrading to 11.10 [11:00] the only people for whom that should have been true would have been people working on multiarch implementation, really === tkamppeter_ is now known as tkamppeter [11:04] tkamppeter: i wonder if you can help - i've been after a particular ppd file (pxl1010.ppd) since linuxprinting.org went offline - can you advise where i can get it? [11:21] oimon, this is in the source of foomatic-db. Do "apt-get source foomatic-db" and you find the XML files for it in /deb/source/. [11:21] tkamppeter: excellent, many thanks :) [11:22] oimon, to build the Ubuntu package with it, edit db/source/driver/pxl1010.xml removing the "" line. [11:22] cheers - any news on when the website is coming back btw? [11:24] oimon, every week they say "next week", on UDS I will look into getting another hoster ... [11:25] * StevenK stares at apt. [11:25] W: Failed to fetch copy:/var/lib/apt/lists/partial/silver_ubuntu_dists_oneiric_main_i18n_Index Encountered a section with no Package: header [11:25] I thought the index wasn't supposed to have any Package: headers ... [11:26] kees: I'm stealing your jasper merge, per your comments of a few days ago that you weren't going to have time for a while [11:26] StevenK: I bet you have an out-of-date apt from oneiric beta-1. upgrade it [11:26] By hand, I guess [11:26] no need for that [11:26] apt-get update has updated enough stuff that you can 'apt-get install apt' now [11:26] And yeah, that chroot is a bit stale [11:27] cjwatson: Sorted, thanks. [11:27] this is bug 871731 which we decided to accept [11:27] Launchpad bug 871731 in Release Notes for Ubuntu "Direct upgrades from beta-1 will produce annoying error message" [Undecided,Fix released] https://launchpad.net/bugs/871731 [11:27] you may remember it from LP conversation just pre-release :) [12:05] SpamapS: update-motd doesn't get run until login [12:05] SpamapS: should not affect boot time [12:06] Spads: something else must be running that apt-check === pedro__ is now known as pedro_ [12:28] kirkland: I'm not sure that's true. [12:28] kirkland: Hang on. [12:28] soren: oh, hmm, actually [12:28] kirkland: The mounted-run job runs update-motd. [12:28] soren: ah, you're right ... === Quintasan_ is now known as Quintasan [12:49] My pulseaudio session daemon seems to stop sometimes (I think it's Flash doing something). How do I best turn on debugging of the daemon? [12:49] (I've been running it in the foreground most of the day but of course nothing happens) [12:56] pitti, hi === Quintasan_ is now known as Quintasan === plars-afk is now known as plars [13:14] hm it just died. saying "Killed". wtf? [13:14] that sounds like the out-of-memory killer got it; I bet you'll find something in /var/log/syslog and/or /var/log/kern.log [13:15] (it's possible some other process was at fault) [13:17] * cjwatson upgrades to precise [13:17] WCPGW [13:17] good luck :) [13:18] I'm surprised by brain interpreted WCPGW /very/ fast. [13:18] s/by/my/g [13:18] apt-get did tell me that there were some ocaml-related uninstallables (which I'm working on clearing), but otherwise it seems OK at least at that level [13:19] cjwatson: no debugging was enabled. Just changed that in /etc/pulse/daemon.conf. I'll watch syslog for error messages. [13:19] OOM killer events will get logged by the kernel regardless of pulseaudio logging levels [13:20] you should find it in dmesg === firewave is now known as FireWave_Job === Amaranth_ is now known as Amaranth [13:47] kirkland: something was running check-new-release early in the boot.. update-motd was thought to possible be it. === yofel_ is now known as yofel [13:51] possibly even :p [13:52] SpamapS: do you think you could merge gdal? it needs a rebuild for the libjpeg transition, and if it needs to be merged anyway ... [13:52] cjwatson: sure, will merge it today. [13:52] thanks! [13:53] hey… if im installing a symbolic link when building a package, will it get the real file to build? [13:54] not quite sure what you mean, maybe an example would help [13:54] are there any #ubuntu-pulseaudio sort of channel? [13:54] well in my debian/install i have: myApp usr/bin [13:55] but myApp is a sym link to where the executable really is [13:55] where is that symlink created? [13:56] and where is the real executable? [14:01] geser: ping [14:01] hmm, who did score up the powerpc builds? [14:01] cjwatson: its in the development folder… :P [14:01] cjwatson: on the same level, but diff folder [14:03] luist: sorry, I don't think that answers my question. Perhaps you could put the whole source package somewhere? [14:03] doko: me - trying to get some multi-level transitions done and it's easier if all architectures keep up [14:03] doko: what's the problem? [14:04] cjwatson: i dont see whats so hard to understand… im putting a symbolic link in the install list and i want to know if its gona pack a broken link or the real file [14:04] luist: there are a couple of different things you might mean and I need specifics. Please can I see the whole source package? [14:04] I don't have time to guess [14:05] cjwatson, hmm, I did rescore openjdk-6 for the security update [14:05] (answered doko in /msg) [14:11] luist: you see, the answer depends on things like whether the symlink is absolute or relative, and whether it's statically present in the tarball, created in a Makefile or similar, or created with dh_link [14:12] luist: and on whether the real path to the executable is installed in the package [14:12] luist: this kind of thing is much easier to tell without lots of going back and forth by just looking at a source package, if that's at all possible === smb` is now known as smb [14:57] doko: Did you have any comments about the php5 debian package you merged? [15:08] slangasek, i'd be interested in your feedback on https://code.launchpad.net/~smoser/ubuntu/oneiric/isc-dhcp/lp857524/+merge/76791 . cjwatson would also be nice as i know you've touched that package (i think for installer primarily). [15:12] smoser: I agree with Marc; there's no reason not to update this file atomically [15:13] please refactor the patch to do so (it sounds like that's what the code did originally) [15:13] cjwatson, actually i dont think you can accomplish that [15:13] with read-only /etc/ [15:13] I don't care how narrow a race condition is; it's either there or it isn't. Actually a narrow one is worse than a wide one. [15:13] if /etc is read-only then you can't write to /etc/resolv.conf either [15:14] ah, yeah, i just have to find the target of the link if its a link [15:14] and put the temp file on *that* filesystem [15:14] if /etc/resolv.conf is a symlink to somewhere writable, then update it atomically there [15:14] right [15:14] smoser: you could follow the symlink and create the tempfile wherever the real resolv.conf turns out to be located [15:14] heh [15:14] anyone else want to repeat ? [15:14] :) [15:14] narrow worse than wide> because it's harder to debug [15:15] smoser: I'm not afraid of a write race, I'm more afraid of a read race while the address is being renewed [15:15] mdeslaur, well that'd take a lockfile via some mechanism to address, right? [15:16] yup, and that would be absolute hell to debug, so let's not doom our successors to that [15:16] no, mv into place is enough [15:16] prevents reading an incomplete resolv.conf [15:17] cjwatson, i didn't understand "narrow worse than wide>" [15:17] 16:13 I don't care how narrow a race condition is; it's either there or it isn't. Actually a narrow one is worse than a wide one. [15:17] oh. regarding the race. [15:41] cjwatson, quick question. [15:41] in the case where there is no /etc/resolv.conf, the old chown / chmod would fail. [15:41] should i explicitly set root:root 644 on it then ? [15:41] or let the normal umask/uid/gid of this script be used. [15:42] I'm not sure. Does the normal umask/uid/gid produce the right answer? [15:43] well this would be running as root, called through ifup [15:43] so i assume uid:gid is right [15:44] smoser: if it produces the right answer then I think I would be happy to just use the defaults [15:51] cjwatson, test here shows root:root 644. [15:51] so we'll go with that. [15:52] ok [16:14] hi, since you guys have been helpful yesterday, I would like to be helped again ;) when I boot I am dropped a non functional root shell instead of starting slim,xdm,gdm or ... I can switch to a different tty and just startx as a workaround, but I would like to get slim working again ;) the only thing that went wrong, judging from the syslog is [ 18.189682] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro. Does anyone have an idea where to sta [16:16] infinity: *poke* bug 759545 .. if you have an idea of how to resolve this, i'd be most appreciative of a fix for alpha 1 :) [16:16] Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545 [16:17] ubottu: thanks, I will study it, brb [16:17] leex: I am only a bot, please don't think I'm intelligent :) [16:18] Daviey: That gives me a month and a bit to ponder it? I'm okay with that schedule. :P [16:19] ah, that wasn't related to me ;) === beuno is now known as beuno-lunch [16:31] infinity, regarding the grub2 bug above, i'd really appreciate it if you could also address the general need for local modification to /etc/default/grub [16:32] right now, the cloud-images modify that file for good reason, and set: [16:32] GRUB_CMDLINE_LINUX_DEFAULT=console=ttyS0 [16:33] also we modify GRUB_HIDDEN_TIMEOUT_QUIET, GRUB_TERMINAL, GRUB_TIMEOUT [16:37] some additional information: running 11.10, fsck done didnt help [16:40] smoser: I defer to cjwatson, he seems to have the bases covered [16:40] agreed. [16:44] http://paste.ubuntu.com/718018/ that's my dmesg output === dendro-afk is now known as dendrobates [16:52] * ogra_ glares at http://qa.ubuntuwire.org/ftbfs/ and wonders why it thinks evas and ecore are parts of ubuntu-desktop [16:54] They're in the ubuntu-desktop package set in precise. I'm not sure why or who put them there (wasn't me). [16:55] ah, i only checked for the task in the package description in oneiric [16:56] * ogra_ isnt really up to speed with precise yet [16:56] i just found it weird to have them in a supported set [16:56] Quite. I'll see what happens when I run the script to sync up with seeds. [17:04] cjwatson: would you mind if I did an audit of the various package sets at some point this cycle? some stuff does look out of place? [17:05] micahg: not at all although I don't promise to change anything ;-) [17:05] heh, ok [17:05] autogeneration is what makes them manageable at all [17:08] cjwatson: so, core, and the CD related sets are only autogenerated? [17:08] yes [17:09] ok, that will make this interesting then :), maybe there's a bug somewhere [17:09] there's a small exception list for moving things out of "more privileged" sets when e.g. the desktop team actually functionally maintains things in core [17:09] but I don't want to take it further than that [17:09] ogra_: should be fixed next time it updates [17:09] it seems to also generate unr and netbook atm [17:09] cjwatson, great [17:10] i assume the two above will vanish as well then [17:10] cjwatson: makes sense, but when I see universe stuff in core, I start to wonder, I will do some digging at some point [17:10] micahg: that was a bug and should be gone now. [17:11] cjwatson: excellent, thank you [17:11] I'm not quite sure what happened, possibly a Launchpad bug on initialising the distroseries, but I can't quite tell at this point since there's little auditing. I've made a mental note to check this out when Q opens to see if the same thing happens [17:11] It's not too big a deal since I always blat over it with an autogenerated list at some point anyway. [17:12] ogra_: unr and netbook - no idea [17:12] I'll go and have a look [17:12] both should be officially gone [17:12] though i'm not sure anyone ever deleted the seed branches from the respective seeds [17:14] cjwatson: the other puzzling thing was something like awstats in core which seems like it should be in the server packageset, any ideas about that? (no rdepends)? [17:15] it seems to have copied some from much older series, which is odd [17:15] micahg: check germinate output [17:15] cjwatson: ok, thanks [17:15] http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/rdepends/ALL/awstats - seeded [17:18] my guess as to what's happened here is that LP has made precise packagesets be the union of those in all previous series, rather than the immediately previous one [17:18] ah, that seems bad [17:18] but I've run out of time to investigate this right now and it's not super-urgent [17:20] ogra_: could you renew my membership of canonical-arm-dev? [17:20] sure, one sec [17:20] cjwatson: ok, if I get time, I"ll dig more and file bugs as appropriate (probably not until after UDS) [17:21] Riddell, you got one more year :) [17:28] thanks ogra, I shall savour every day of it [17:28] Can anyone confirm that there is no /etc/inittab on ubuntu 11.10? [17:28] leex: yes [17:29] Riddell: thanks [17:30] Riddell: still searching for my strange "dropped to root shell after boot"-bug [17:30] dropped to a root shell, or dropped to a login prompt? [17:31] slangasek: dropped to a login prompt would be ok ;) [17:31] I'm asking which happens [17:31] slim just stopped working, and I get a root shell instead [17:32] [ 14.546502] init: failsafe main process (796) killed by TERM signal ... [ 14.588677] init: lightdm main process (1053) killed by TERM signal [17:33] http://paste.ubuntu.com/718075 that's the whole dmesg === beuno-lunch is now known as beuno [17:34] the only cases in the 11.10 boot sequence that will give you a root shell are 1) booting in recovery mode (booting with 'recovery' on the kernel commandline), 2) booting with 'S' as the runlevel target, 3) a critical failure in mountall causing it to drop to a root shell for you to fix your filesystem [17:35] do you know if any of these apply to your case? [17:35] slangasek: I did a shutdown -rF now, before comming here [17:35] slangasek: I did not select recovery mode [17:35] slangasek: how can I check for the runlevel target? [17:36] the runlevel target would also be on the kernel commandline (normally) - since your dmesg doesn't show that, it's probably not runlevel S either [17:37] however, this dmesg shows processes being killed by SIGTEMR [17:37] SIGTERM [17:37] that's not at all normal [17:37] did you use SysRq to kill the jobs? [17:37] slangasek: y [17:37] slangasek: no [17:37] ok [17:37] slangasek: I just enter my luks password, nothing else [17:38] I justed upgraded from 11.04 recently, but that's a week ago. and I havent had the issue til today [17:38] should I file a bug report? [17:39] you might want to check if you have any modified files under /etc/init or /etc/init.d, or anything in either of those directories not belonging to a package; or if you have put anything unusual in /etc/rc.local. This doesn't look like an Ubuntu bug, it looks like something has run amok in your startup sequence and is killing off processes [17:40] hmm, I will check, have to leave office now though. I will have a look at and tell you lator [17:40] * ogra_ sees gdm in the dmesg output [17:40] but I didn't touch any of these files by hand [17:40] how did you do your upgrade from 11.04 exactly ? [17:41] ogra_: the upgrade from 11.04 is expected to leave gdm installed, and that's not the bug [17:41] ogra_: upgrade manager [17:42] I have a hard time seeing this as an upgrade bug anyway. Worked fine for a bit, exploded today. And, seriously, what runs amok and kills everything, including rc? [17:42] infinity: ack [17:42] My kingdom for sane init logs. [17:43] infinity: define? :) [17:43] infinity: better yet, define in Orlando :) [17:44] slangasek: Can I just hand-wavingly say "something a lot more verbose than his dmesg output that would tell me WTF happened there"? :) [17:44] infinity: you can, but that's not actionable :) [17:44] we do have working /var/log/boot.log [17:44] With nothing else to blame, I'd guess sendsigs is being run in runlevel 2. [17:44] Which would be... Special. [17:44] and you can boot with --verbose [17:44] slangasek, ah, i wasnt aware it leaves gdm in place [17:45] infinity: right, also notice the gap in timing of the SIGTERMs... one batch at 17s after boot, another at 39s after boot [17:45] thigns are getting killed *twice* [17:45] maybe sendsigs is in both /etc/rcS.d and /etc/rc2.d :P [17:45] leex: ^^ make sure there are no symlinks to /etc/init.d/sendsigs in either of these directories, please [17:45] have to go home now, but if you have an idea on how to track this bug, please let me know. btw here is my boot.log http://paste.ubuntu.com/718082 [17:45] slangasek: Though, that still wouldn't do anything bad. sensigs start is a no-op. [17:46] slangasek: I will do, back in about an hour [17:46] in any event, sendsigs is *not* supposed to kill anything that's attached to an upstart job [17:46] infinity: it could be a K link? [17:46] That would be even more special. ;) [17:46] this whole scenario is unambiguously special [17:47] If this proves to be an upgrade bug, I think we're getting ever closer to discovering the long-sought-after secret to punching people in the face over the internet. [17:48] leex: fwiw, your boot.log shows that your system *is* entering single-user mode, *after* having started runlevel 2: "* Starting System V single-user mode compatibility" [17:48] infinity: see? we have logs [17:48] we just need to line wrap them properly [17:49] slangasek: Oh, I may have missed the bit where a log was provided. :) [17:49] infinity: it was provided after you asked :) [17:49] Also, I can't read. [17:52] leex: this message comes from /etc/init.d/single, which is somehow being invoked. Up to line 60 of your paste, everything appears to be correctly starting runlevel 2, then all of a sudden, with no indication of runlevel change, /etc/init.d/single has been called. I suspect there's a wrong link to this script in /etc/rc2.d. [17:52] Indeed. [17:54] * infinity wonders if one of the many "user-friendly" rc editors is to blame. [17:54] Or something. [17:55] leex: For the record, on a stock install you should see this: [17:55] adconrad@cthulhu:~$ ls /etc/rc?.d/???single [17:55] /etc/rc1.d/S90single [17:55] (And no other links) === zyga is now known as zyga-afk [18:12] Daviey, if it's got my fixes, yeah that sounds good [18:18] * Daviey tries to remember context === dendrobates is now known as dendro-afk [18:24] Daviey, python mysqldb [18:25] ah! [18:25] superm1: Are you handling the sync? [18:25] Daviey, you can go ahead if you'd like [18:26] * Daviey tries the whizzy webui [18:26] I don't have a precise schroot set up yet, and don't plan on getting to that until after UDS probably [18:26] re ;) reading backlog [18:27] seems the option has been disabled. [18:27] gah [18:28] infinity: sysv-rc-config [18:29] infinity and slangasek how to figure out what's wrong? [18:29] leex: covered in scrollback - having any links to 'single' outside of /etc/rc1.d is wrong [18:30] lrwxrwxrwx 1 root root 16 2011-10-20 14:16 S90single -> ../init.d/single* [18:30] :D [18:30] in rc2.d [18:30] slangasek: can I just remove that? [18:31] sysv-rc-config isn't a package in the archive. Where did you get it... and why did you think to run it on your systeM? [18:31] leex: yes, you can and *must* remove it [18:31] oh, it's called sysv-rc-conf, maybe [18:31] sry, sysv-rc-conf [18:32] slangasek: will restart and check whether it is ok [18:32]