=== bjf_ is now known as bjf === slangase` is now known as slangasek === infinity1 is now known as infinity === TJ- is now known as Guest8103 === TJ_Remix is now known as TJ- [09:30] This may interest some : Wily fails to complete a crashdump with crashkernel=128 these days [09:30] OOM kicks in before rootfs is mounted. It needs at least 145M to work [09:31] https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1496317 follows that problem [09:31] Ubuntu bug 1496317 in kexec-tools (Ubuntu) "kexec fails with OOM killer with the current crashkernel=128 value" [High,Confirmed] [10:17] caribou, ugg, hrm [10:19] apw: initramfs went from 22M in 3.x kernels to 29M with 4.x [10:19] caribou, what the heck [10:19] we _so_ need to make a =dep initramfs for the machine for use with kdump [10:20] as i am sure that is all turd we don't need in reality [10:20] we have been talking for a while how it would be nice to have a thin initrd and a fat one, this would be a perfect use case [10:20] yeah, indeed [10:21] though I'm not too enthusiastic about a separate boot file for dumping [10:21] too many horror stories in the early days [10:22] welll in a perfect world we would use the thin one for booting and dumping, and only "i am broken" boots would use fat [10:23] caribou, if you have a list of what got added for 4.x i would be interested to know, as we have a much newer merge of initramfs-tools in wily [10:23] and it may be related to that as much as anything [10:23] apw: I'll diff them & let you know [10:49] apw: 24M more in ./lib for 4.2 [12:13] apw: changing MODULES=most to MODULES=dep in initramfs.conf brings the initrd from 29M to 12M & works around the issue [12:14] changing to =none brings it to 2MB ;) [12:14] ogra_: yes, but mine still boots :) [12:14] mine too :) [12:15] * ogra_ would simply move the modules to an img file living in /boot ... that could be loop mounted by the initrd and later move mounted to /lib/modules ... that way you wouldnt waste twice the space for modules on disk [12:44] ogra_, though if you can mount root you don't need any of them, if you can't you need them in the initramfs [12:45] apw, well, the only think i need modules for is netboot or encrypted root [12:45] *thing [12:45] and both can have a standalone /boot [12:46] right but you are above averagely lucky i assume [12:47] because i dont use a zfs root ? [12:47] :P [12:48] extX is compiled in ... vfat should be too (IMHO) .... if i do a pretty standard install with a standard fs i usually dont need any modules [12:48] because you don't use a disk controller which is a module [12:48] which makes you lucky [12:49] in theory =dep shold be empty for your use case though [12:49] true ... but even with a disk controller like that your /boot needs to be accessible for grub ... [12:49] which means you most likely dont have it on the disk needing this controller [15:25] tjaalton, I'm starting to see complaints about i915 in Wily with the 4.2 kernel. bug #1496433 for example. I've pulled a lot of 4.3 i915 cruft and am wondering if it is causing issues. [15:25] bug 1496433 in linux (Ubuntu) "Error in i915 driver" [Undecided,New] https://launchpad.net/bugs/1496433 [15:34] rtg: -7.7 didn't have the latest pull request [15:34] so it's a genuine 4.2 bug :) [15:35] tjaalton, ok, -10.12 will get published today. I'll keep an eye on progress [15:36] seems to be upstream https://bugs.freedesktop.org/show_bug.cgi?id=91511 [15:36] Freedesktop bug 91511 in DRM/Intel "[drm:check_crtc_state] *ERROR* mismatch in ips_enabled (expected 1, found 0)" [Normal,Needinfo] [15:37] tjaalton, can you watch for a resolution on that bug ? [15:37] yep [15:38] tjaalton, isn't there a way to attach a watch on the LP bug ? [15:38] I'll add the bugwatch and cc myself upstream [15:38] cool [15:38] "also affects project", then paste the buglink. done that [17:53] Hi guys, can anyone point me to the source for the Nexus 7 2013 kernel [17:53] "flo"? [18:39] old_benz, 14.04 was the first release with a "flo" kernel. See 'git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git flo' [18:40] rtg: thank you very much [20:54] apw: oy ve. are you sick of overlayfs yet? cause there's a new problem with whiteouts for unprivileged containers: [20:54] whiteouts are apparently created as character devices. This means there is no way in a userns to rsync them [20:54] (which is required for cloning such a container) [20:54] issue was raised at https://github.com/lxc/lxc/issues/655 [20:54] stgraber: ^ :( [21:02] oh, fun [22:37] hallyn, hrm, that _is_ the format in there. There is prolly a way to work round it in userspace, but hrmph [22:41] apw: only way i know to work around it is either with a privileged helper or with bind mounts - neither will stop rsync complaining, and bind mounts won't persist. sigh. [22:42] you could copy in junk to the whiteouts, and then mount the overlay, and rm them [22:43] hallyn, or actually as you know there is a white out, you could just rsync and let them get lost, then mount the overlay and rm any whiteout in the upperlayer making a new one [22:43] (vile i know) [22:44] it is possible you should be allowed to make whiteout chardevs as a normal user, maybe, god don't make me think of the security consequences though [22:45] problem is rsync will fail, so how does a calling program know whether the only failures were expected whiteout failures? [22:45] if we can detect that, then what you propose sounds... well, like a decent workaround [22:45] find - and use that list as an exclude, rsync, mount, rm the original list perhaps [22:45] or maybe what we should be doing is simply mounting the two overlays and rsync from the one mount to the other [22:46] that would make _much_ more sense [22:46] doh [22:47] feels like ther e must be something wrong with it, but i can't see waht right now [22:47] * hallyn goes for a cup of coffee, biam [23:12] apw: yeah, that works.