=== attente_ is now known as attente
=== ssweeny` is now known as ssweeny
=== _salem` is now known as _salem
=== fginther` is now known as fginther
=== Zic_ is now known as Guest40484
=== Elimin8r is now known as Elimin8er
=== bdrung_ is now known as bdrung
=== lfaraone_ is now known as lfaraone
=== FlannelKing is now known as Flannel
=== adam_g` is now known as adam_g
[05:42] <pitti> Good morning
[05:44] <pitti> apw: hm, https://www.debian.org/doc/debian-policy/ch-relationships.html says that they are supported with !
=== thegodfather is now known as fabbione
[07:50] <dholbach> good morning
[07:50] <dholbach> mvo_, do you know where http://pastebin.ubuntu.com/13309322/ could be coming from?
[07:52] <mvo_> dholbach: hm, thats usually if the wily.tar.gz and wily.tar.gz.gpg are out of sync, could you try again as user without the sudo and see if that makes a difference?
[07:56] <dholbach> mvo_, now it seems to work - it didn't work in update-manager earlier, which is why I switched to do-release-upgrade
[08:03] <mvo_> dholbach: I suspect network/proxy or similar effects :/
[08:03] <dholbach> ok, thanks
=== Guest40484 is now known as Zic
[09:20] <apw> pitti, right they are normaly, it seems that the regexp that extracts them for tests/control doesn't expect !
[09:26] <popey> pitti, got my cpu spinning on apport with caja again, what debugging should I do?
[09:29] <popey> pitti, http://paste.ubuntu.com/13310423/ is a few moments of strace from apport
[09:36] <pitti> apw: oh! that does sound something that can be fixed easily
[09:39] <pitti> read(4, "651-475c-811c-ce2' failed: No su"..., 4096) = 4096
[09:39] <pitti> popey: that looks interesting
[09:39] <pitti> popey: can you look into /proc/<apport pid>/fd/4 what this points to?
[09:39] <pitti> read(4, "glibtop(c=4170): [WARNING] statv"..., 4096) = 4096
[09:39] <pitti> that too
[09:40] <pitti> that could be a d-bus call
[09:40] <popey> lr-x------ 1 root root 64 Nov 17 09:40 /proc/22274/fd/4 -> /var/crash/_usr_bin_caja.1000.crash
[09:40] <pitti> uh, wth
[09:40] <popey> -rw-r----- 1 alan whoopsie 67466388 Nov 10 14:50 /var/crash/_usr_bin_caja.1000.crash
[09:40] <popey> from days ago
[09:41] <pitti> ok, this is apparently from reading the previous file to determine the CrashCounter: value
[09:42] <popey> would you like me to file a bug against apport perhaps?
[09:42] <pitti> popey: yes, easier for tracking, that doesn't seem a trivial issue
[09:42] <popey> okay, any additional logs I should attach?
[09:42] <pitti> popey: is it still looping over reading from fd 4 if you attach strace now?
[09:43] <pitti> popey: please don't kill it yet, I'd first like you to run some experiments which would reproduce this
[09:43] <popey> okay. It's making my laptop hard to use though, just so you know :)
[09:44] <popey> http://paste.ubuntu.com/13310583/ is the latest from the strace log
[09:44] <pitti> $ python3 -c 'import apport.fileutils; print(apport.fileutils.get_recent_crashes(open("/var/crash/_usr_bin_caja.1000.crash", "rb")))'
[09:44] <pitti> popey: ok, so still looping over reading the old file; what does that ^ say for you and how long does it take?
[09:45] <popey> pitti, that doesn't feel like it's going to finish any time soon :) 24328 alan      20   0   78124  30796  10508 R  89.8  0.2   0:26.35 python3
[09:45] <popey> that's now eating a core too
[09:45] <pitti> popey: oh, good! so that reproduces it
[09:45] <popey> :)
[09:45] <pitti> popey: so you can kill apport
[09:45] <popey> yay
[09:46] <popey> and the python3 thing?
[09:46] <pitti> popey: can you scp that .crash to people.u.c., or just attach it to the bug (if you are reasonably sure it doesn't have s3kr1t stuff in it), so that I can try here?
[09:46] <popey> sure
[09:46] <pitti> popey: you can kill it too
[09:46] <pitti> popey: but please try again if it still hangs after you killed apport, to be sure
[09:47] <popey> pitti, it does
[09:47] <pitti> popey: cool; so we have a much easier handle on this
[09:47] <pitti> popey: if I can reproduce it with your .crash file, then you are entirely off the hook :)
[09:47] <popey> woot!
[09:47] <popey> uploading now
[09:49] <popey> pitti, https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1516947 is the bug for it, link to crash in the bug
[09:49] <ubottu> Launchpad bug 1516947 in apport (Ubuntu) "apport looping on an old crash dump" [Undecided,New]
[09:50] <popey> thanks for the help!
[09:52] <Mirv_> heh
[09:52] <Mirv_> @pilot out
=== Mirv_ is now known as Mirv
[09:52] <Mirv> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[09:52] <pitti> popey: reproduces fine, thanks!
[09:52] <popey> super
[09:52] <Mirv> (not really pilotting for 27h)
=== G_ is now known as G
[11:04] <halfie> hi, the .deb packages seem to be missing from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc1-wily/
[11:04] <halfie> which is a bit unusual
=== oSoMoN_ is now known as oSoMoN
=== _salem is now known as salem_
=== cpaelzer_ is now known as cpaelzer
=== blami_ is now known as blami
=== ssweeny` is now known as ssweeny
=== francisco is now known as Guest59143
=== Pici` is now known as Pici
[14:01] <cyphermox> good morning!
[14:03] <mdeslaur> hi cyphermox!
[14:04] <seb128> hey cyphermox mdeslaur
[14:04] <tsg> micahg: checking in to see if you would have a few to take a look at bug 1516259 and bug 1515710 today. Thanks!
[14:04] <mdeslaur> hi seb128
[14:04] <ubottu> bug 1516259 in Precise Backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to precise" [Undecided,New] https://launchpad.net/bugs/1516259
[14:04] <ubottu> bug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New] https://launchpad.net/bugs/1515710
[14:14] <LocutusOfBorg1> hi, who is patch piloting today? I have a quick and easy SRU to ask you :p
[14:15]  * LocutusOfBorg1 is joking, there is no easy SRU, but a really difficult one
=== barry` is now known as barry
[14:15] <LocutusOfBorg1> sometning like this  2729 files changed, 779602 insertions(+), 142675 deletions(-)
[14:18] <nils17> perhaps anybody knows it in this channel: where can I disable the warning "granted permissions without asking for password" when I execute e.g.   gksudo nautilus ?
[14:28] <seb128> LocutusOfBorg1, you can try barry or TheMuso (though he's probably eod for a while) or bdmurray
=== tlyu_ is now known as tlyu
[14:42] <barry> LocutusOfBorg1: i'm around, but have a couple of other things on the stack atm.  give me some info and i'll try to take a look
[14:43] <LocutusOfBorg1> barry, I'm doing test builds right now
[14:43] <LocutusOfBorg1> TLTR: I need to upgrade virtualbox-precise as SRU from 4.1.12 to 4.1.44
[14:43] <LocutusOfBorg1> and trusty from 4.3.26 to 4.3.34
[14:44] <LocutusOfBorg1> I already did the same for debian, with a great success
[14:44] <LocutusOfBorg1> and I'm starting from that version to do the same for ubuntu
[14:44] <LocutusOfBorg1> (also wily needs fixing, but we can just SRU with the xenial version)
[14:44] <barry> LocutusOfBorg1: ok.  i'm not a virtualbox expert, so i might defer, but i'll take a look when you're ready
[14:45] <LocutusOfBorg1> the rationale is many CVE fixes, stability fixes, and kernel building again
[14:45] <LocutusOfBorg1> thanks
[14:45] <LocutusOfBorg1> I'm going to open a bug to keep track of patches if it is ok for you
[14:45] <barry> yes please!
=== alai888 is now known as alai
=== Guest80875 is now known as mfisch
=== mfisch is now known as Guest20594
=== Guest20594 is now known as mfisch
[15:36] <rbasak> pitti: please could you see bug 1511899? What's the logic for where /bin/running-in-container should belong now? If in init-system-helpers, then do we just need a versioned breaks/replaces for upstart?
[15:36] <ubottu> bug 1511899 in init-system-helpers (Ubuntu) "init-system-helpers and upstart need to conflict/replace" [High,Triaged] https://launchpad.net/bugs/1511899
[15:37] <rbasak> It seems upstart 1.13.2-0ubuntu17 doesn't ship /bin/running-in-container.
[15:39] <pitti> rbasak: hallyn moved it to i-s-h in bug 1442228; can't say I'm happy about this as it's a permanent delta, but that's the status quo
[15:39] <ubottu> bug 1442228 in lxc (Ubuntu) "lxc fails to start inside vivid container" [Critical,Fix released] https://launchpad.net/bugs/1442228
[15:40] <pitti> rbasak: so I guess i-s-h needs to B/R: upstart (<< 1.13.2-0ubuntu13)
[15:40] <rbasak> pitti: OK so I'll just upload a Breaks/Replaces then?
[15:40] <rbasak> Ack.
[15:41] <pitti> rbasak: in the long run I'd rather get rid of it
[15:42] <hallyn> i did what?
[15:43] <rbasak> hallyn: https://launchpad.net/ubuntu/+source/init-system-helpers/1.22ubuntu10
[15:43] <rbasak> hallyn: a necessary Breaks/Replaces has gone missing since, though I see that you did upload one originally.
[15:43] <rbasak> Maybe some move between upstart and upstart-bin?
[15:43] <hallyn> hm
[15:45] <pitti> could also be a merge error in i-s-h
[15:45] <pitti> (much more likely, as the B+R need to go there, not into upstart)
[15:46] <rbasak> Yeah looks like a merge error.
[15:46] <hallyn> woulda preferred systemd depend on upstart? :)
[15:46] <rbasak> I'll upload a fix.
[15:48] <hallyn> where do we need running-in-containers these days?  maybe it's too early for me to thinkabout this.
[15:54] <pitti> probably only an archive grep can tell
[15:54] <pitti> mostly in LXC, but a few otehr packages might have picked it up too
[15:54] <gQuigs> is udisks2 something we plan to support for a long time?
[15:55] <seb128> gQuigs, is it being replaced?
[15:55] <seb128> but I guess it any case even if it is that's not for the coming LTS
[15:55] <gQuigs> seb128: trying to convince adobe to move off of hal, and want to make sure it's not going anywhere
[15:55] <seb128> so yeah, we probably keep to support udisks2 for a while
[15:55] <pitti> the only potential replacement today is storaged, but we haven't looked at that so far, and it's D-BUS API compatible (it says, anyway)
[15:56] <gQuigs> awesome, so I'll recommend they move to use the D-BUS api
[15:56] <gQuigs> thanks!
=== caribou_ is now known as caribou
[16:28] <didrocks> ximion: hey! after Laney poke me about some appstream-dep11, I did fix it and create a PR: https://github.com/ximion/appstream-dep11/pull/1
[16:29] <didrocks> ximion: I tried to summarize my findings as much as possible on the description, do not hesitate to tell me if you think I should do any modification
[16:41] <ximion> didrocks: neat, thank you!
[16:42] <ximion> using setuptools properly was on my todo-list even, but admittedly at a very low position ;-)
[16:42] <Laney> I tried to install a checkout in a virtualenv and it didn't work
[16:42] <Laney> so invoked the didrocks :P
[16:43] <didrocks> ximion: yw! Indeed, I guess those kind of crashs are the only way to motivate changing things that basically worked :p
[16:44] <didrocks> ximion: oh, I didn't write it on the PR, but I reinstalled on our machine a new blank virtualenv with my branch, installed it there and did a successful run
[16:45] <ximion> didrocks: that's a pretty interesting bug you've found there - I wasn't aware that this couls happen at all...
[16:46] <didrocks> ximion: I wasn't aware about that __spec__ + multiprocessing either before… today :p
[16:46] <ximion> btw, initially the python3-dep11 module was meant to be used by Python applications reading DEP-11 data, so there initially was a split between all the database/building stuff in scripts/ and read-only stuff in dep11. That just made things harder anyway, so the change is fine
[16:47] <ximion> (and actually, reading DEP-11 in Python is as simple as safe_load'ing a YAML file)
[16:47] <ximion> didrocks: multiprocessing leads to some very weird and hard-to-debug issues...
[16:47] <didrocks> yeah, that was my feeling when reading the code
[16:48] <didrocks> ximion: I'm using futures module now, not sure if there is a constant pool functionality though
[16:48] <ximion> for example, one that I still haven't tracked down, opening a LMDB database in the main process and then starting multiprocessing doesn't work - the child processes simply return without an error, and that's it
[16:48] <ximion> so we now close the db and reopen it everytime :-/
[16:48] <didrocks> (but it's quite nice for ThreadPoolExecutor and ProcessPool)
[16:49] <didrocks> urgh, yeah, that's why it's quite slow I guess
[16:49] <didrocks> that was your comment on calling "fork_server", I saw this
[16:52] <ximion> that even was a different story at first, involving an issue with apt_pkg, which is now fixed...
[16:53] <ximion> the code was fast once, but in order to not double-process data from different suites, we unfortunately need to give the generator access to the database. Which results in better data and increased speed
[16:54] <ximion> I am not happy with how that thing looks, especially the icon-searching code is insane - but it's working well now
[16:54] <ximion> (and a proper fix would be to enforce stricter icon-naming and placement for applications, which won't happen anytime soon)
[16:55] <didrocks> ximion: yeah, we had a similar issue with ubuntu-software-center as far as I know, I guess you have a similar insane icon-naming search path :/
[16:55] <Laney> I think we're going to have to fix humanity
[16:57] <didrocks> (I guess Laney is talking about the theme) ;)
[16:57] <didrocks> the meaning will be harder to fix :p
[16:57] <didrocks> other*
[16:57]  * seb128 votes for Laney
[16:58] <ximion> didrocks: mvo told me that at Debconf, made me feel a bit better - I still feel a bit guilty for sending my GSoC student through that ^^
[16:59] <ximion> at least since the "appstreamcli validate-tree" command is used by some upstreams, they all started to name their .desktop files and MetaInfo files corectly and added missing tags \o/
[17:16] <sergiusens> cyphermox, hey, random question, if I apply for PPU no, do I become an ubuntu member or is that a separate process?
[17:18] <cyphermox> sergiusens: you should mention in your application that you want to apply for ubuntu member too, but it's documented as being granted at the same time.
[17:20] <sergiusens> cyphermox, great; last question, can I reuse an application or should start from scratch?
[17:20] <cyphermox> sergiusens: fwiw it's a discussion we're having : https://lists.ubuntu.com/archives/devel-permissions/2015-August/000815.html
[17:20] <cyphermox> sergiusens: if you already have an application wiki page done, by all means feel free to reuse it ;)
[17:21] <sergiusens> cyphermox, I do, from my previous PPU request :-) (which at the time thought included Ubuntu Membership) ;-)
[17:21] <sergiusens> cyphermox, thank you
[17:48] <rbasak> slangasek: could you advise on bug 1507151 please? Is the appropriate fix just to call insserv from sysv-rc.postinst with a hardcoded path, or should we drop or alter the insserv delta?
[17:48] <ubottu> bug 1507151 in sysvinit (Ubuntu) "sysv-rc.postinst calls insserv by name, but insserv package does not provide the command in a bin directory" [High,Triaged] https://launchpad.net/bugs/1507151
[18:03] <LocutusOfBorg1> barry, lp: #1517161
[18:03] <ubottu> Launchpad bug 1517161 in virtualbox (Ubuntu) "virtualbox SRU for CVE" [Undecided,New] https://launchpad.net/bugs/1517161
[18:03] <LocutusOfBorg1> :)
[18:04] <LocutusOfBorg1> BTW can anybody please sponsor an easy backport? https://bugs.launchpad.net/wily-backports/+bug/1512982
[18:04] <ubottu> Launchpad bug 1512982 in wily-backports "Please backport hedgewars 0.9.22-dfsg-2 (universe) from xenial" [Undecided,New]
[18:04] <LocutusOfBorg1> upstream is bothering me about it, because of the online game features
[18:04] <LocutusOfBorg1> (users are asking upstream to update, and upstream is asking me to do it)
[18:04] <LocutusOfBorg1> and I'm asking you :p
[18:04] <barry> LocutusOfBorg1: okay, i opened a tab.  no promises - i seem to be just getting swamped :/
=== dkessel_ is now known as dkessel
[18:05] <LocutusOfBorg1> barry, no problem :)
[18:06] <LocutusOfBorg1> please consider that sponsoring the upload will fix at least 200 bugs
[18:06] <LocutusOfBorg1> :D
=== mbarnett` is now known as mbarnett
=== salem_ is now known as _salem
=== _salem is now known as salem_
[19:46] <slangasek> rbasak: you are describing a different bug than what was reported in bug #1507151.  The submitter's system apparently had no trouble locating insserv?
[19:46] <ubottu> bug 1507151 in sysvinit (Ubuntu) "sysv-rc.postinst calls insserv by name, but insserv package does not provide the command in a bin directory" [High,Triaged] https://launchpad.net/bugs/1507151
=== Snow-Man_ is now known as Snow-Man
[19:48] <slangasek> rbasak: oh - no, I see, the maintainer script gives a generic error and the real error is in the log.  ok.  Yes, the postinst already does "Make sure insserv is in the path", so it just needs /usr/lib/insserv to be part of that path, I think
[19:50] <smoser> hey...
[19:51] <smoser> i have a curtin testcase that fails sometimes
[19:51] <smoser> whathapens is that it ends up not powering off the system even though poweroff was called.
[19:51] <smoser> wondering how i'd get more data out of that.
[19:52] <smoser> cloud-inti invokes shutdown -P now
[19:52] <smoser> and then system just doesnt seem to go down
[19:54] <slangasek> smoser: and you say this is intermittent?
[19:55] <smoser> seemingly
[19:55] <slangasek> I'm not sure what systemd debugging options are available on shutdown
[19:56] <slangasek> smoser: do you get the kernel's "powering off" message at the end?
[19:56] <smoser> no.
[19:57] <smoser> itll finish like http://paste.ubuntu.com/13316912/
[19:57] <slangasek> hmm
[19:58] <smoser> the cloud-init message is after it has invoked shutdown (and it has received SIGTERM after having done so)
[19:58] <slangasek> what's the kernel commandline? is ttyS0 the only console?
[19:58] <smoser> [    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.19.0-33-generic root=UUID=ef812a22-0d30-4d05-b0ba-8a46c02777f2 ro console=ttyS0 luks=no nomdmonddf nomdmonisw
[19:59] <smoser> heres a very verbose log http://paste.ubuntu.com/13317017/
[20:00] <slangasek> seb128: I see you synced fop, which brought in two new build-dependencies not in main; are you planning to do the MIRs for these?
[20:01] <seb128> slangasek, I've that somewhere on my todolist but rather low, feel free to steal it from me if you want ;-)
[20:01] <Unit193> slangasek: Did you get a chance to re-review the MPs after the fix?
[20:02] <slangasek> smoser: well, the verbosity we need here is from the kernel+init, which is still lacking; I think you need to get systemd logging more verbosely to console, which I don't know how to do offhand - pitti would of course know if he's around
[20:03] <slangasek> seb128: I don't want to do them, I want the people causing the mismatches to follow through ;P
[20:04] <smoser> systemd.log_target=kmsg systemd.log_level=debug maybe
[20:04] <smoser> i'll try
[20:04] <slangasek> Unit193: hi, sorry can you give me the pointer to the MPs again?
[20:04] <seb128> slangasek, right, I sort of agree, though technically I just put back in sync since the delta was good to drop the new version would have come through autosync then without me :p
[20:05] <slangasek> Unit193: I don't remember seeing new emails, so either the MPs weren't 'resubmit'ted or I missed the mails somehow, sorry
[20:05] <seb128> slangasek, speaking about following through, do you know if doko is around? unsure what to do with packagekit in xenial-proposed, it seems there is no concrete plan to deal with it in a reasonable timeframe and it's going to block other things
[20:05] <Unit193> slangasek: https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167
[20:06] <slangasek> seb128: I haven't spoken to doko today; but I don't think doko's packagekit merge implies any kind of committment to follow through on the issues you outlined.  Maybe we should kick that back out of xenial-proposed?
[20:06] <slangasek> Unit193: cheers, queued for looking at this afternoon
[20:06] <seb128> slangasek, yeah, that's what I was going to do, I just wanted to hear back from doko first
[20:06] <Unit193> Great, thanks.
[20:08] <nagromlt> is there a good channel for ubuntu support?
[20:08] <Unit193> nagromlt: #ubuntu is for support.
[20:08] <nagromlt> thx
[20:40] <tsg> doko: any ideas on who could help with https://bugs.launchpad.net/trusty-backports/+bug/1515710
[20:40] <ubottu> Launchpad bug 1515710 in trusty-backports "Please backport liberasurecode-1.1.0, python-pyeclib-1.1.1 to trusty" [Undecided,New]
=== jdstrand_ is now known as jdstrand
=== salem_ is now known as _salem
[21:22] <jetsaredim> pitti: any comments on a workaround for the following bug?
[21:22] <jetsaredim> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1491658
[21:22] <ubottu> Launchpad bug 1491658 in linux (Ubuntu) "systemd[1]: Failed to insert module 'kdbus': Function not implemented" [Medium,Expired]
[21:23] <Unit193> jetsaredim: What's the bug?
[21:23] <sarnold> pitti: (I suggested jetsaredim head here and ask you about it, it feels funny to see systemd require kdbus moments after fedora yanked kdbus from the distro -- https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html )
[21:24] <Unit193> sarnold: It's not so much that systemd requires it, but it tries to load it if it exists and thus gives output if it doesn't.  It works like it always has.  If you want, you can try the kdbus-dkms package (from Debian experimental only, IIRC.)
[21:24] <sarnold> Unit193: oh, is -that- it? just a silly informational message?
[21:25] <jetsaredim> the system won't boot past that
[21:25] <Unit193> sarnold: It's insignificant unless you have kdbus-dkms, pretty much.
[21:26] <Unit193> jetsaredim: Maybe, but that's not the issue.  You'll see that on any wily boot.  [    8.683505] systemd[1]: Failed to insert module 'kdbus': Function not implemented   here locally.
[21:26] <jetsaredim> Unit193: other way around i think
[21:26] <jetsaredim> hmm
[21:26] <Unit193> jetsaredim: Nah, if you have kdbus-dkms, you likely want it loaded.  Otherwise just ignore it.
[21:26] <jetsaredim> maybe i grabbed the wrong error line
[21:27] <Unit193> (And FWIW, I personally wouldn't recommend kdbus.)
[21:27] <jetsaredim> just noticed the last line before the systemd freeze message is something about mtab not being a symlink
[21:27] <jetsaredim> I certainly didn't go out of my way to set up kdbus
[21:27] <Unit193> That's the issue, and was a known Xenial bug.
[21:28] <Unit193> LP 1511376
[21:28] <ubottu> Launchpad bug 1511376 in ubiquity (Ubuntu Xenial) "install writes /etc/mtab as file, not symlink" [High,Fix released] https://launchpad.net/bugs/1511376
[21:28]  * Unit193 passes it back to sarnold.
[21:28] <jetsaredim> hm
[21:28] <jetsaredim> ok
[21:28] <jetsaredim> i'll give that a rty
[21:28] <jetsaredim> *try
[21:28] <jetsaredim> even
[21:28] <sarnold> Unit193: many thanks :)
[21:29] <jetsaredim> sorry for the confusion
[21:29] <Unit193> sarnold: Sure, glad I was actually able to help you!
[21:29] <sarnold> pitti: aha, nevermind, Unit193 covered it nicely, suggested 1511376 is the cause of the problem :)
[21:30] <smoser> slangasek, http://paste.ubuntu.com/13318228/
[21:30] <smoser> theres a 15M pastebin there for you.
[21:30] <jetsaredim> so, small-ish?
[21:31] <smoser> jetsaredim, yeah.
[21:31] <jetsaredim> seems like the fix is - boot to recovery then create link and then init 2?