[09:30] <caribou> This may interest some : Wily fails to complete a crashdump with crashkernel=128 these days
[09:30] <caribou> OOM kicks in before rootfs is mounted. It needs at least 145M to work
[09:31] <caribou> https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1496317 follows that problem
[10:17] <apw> caribou, ugg, hrm
[10:19] <caribou> apw: initramfs went from 22M in 3.x kernels to 29M with 4.x
[10:19] <apw> caribou, what the heck
[10:19] <apw> we _so_ need to make a =dep initramfs for the machine for use with kdump
[10:20] <apw> as i am sure that is all turd we don't need in reality
[10:20] <apw> 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] <caribou> yeah, indeed
[10:21] <caribou> though I'm not too enthusiastic about a separate boot file for dumping
[10:21] <caribou> too many horror stories in the early days
[10:22] <apw> 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] <apw> 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] <apw> and it may be related to that as much as anything
[10:23] <caribou> apw: I'll diff them & let you know
[10:49] <caribou> apw: 24M more in ./lib for 4.2
[12:13] <caribou> apw: changing MODULES=most to MODULES=dep in initramfs.conf brings the initrd from 29M to 12M & works around the issue
[12:14] <ogra_> changing to =none brings it to 2MB ;) 
[12:14] <caribou> ogra_: yes, but mine still boots :)
[12:14] <ogra_> 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] <apw> 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] <ogra_> apw, well, the only think i need modules for is netboot or encrypted root 
[12:45] <ogra_> *thing 
[12:45] <ogra_> and both can have a standalone /boot 
[12:46] <apw> right but you are above averagely lucky i assume
[12:47] <ogra_> because i dont use a zfs root ? 
[12:47] <ogra_> :P
[12:48] <ogra_> 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] <apw> because you don't use a disk controller which is a module
[12:48] <apw> which makes you lucky
[12:49] <apw> in theory =dep shold be empty for your use case though
[12:49] <ogra_> true ... but even with a disk controller like that your /boot needs to be accessible for grub ... 
[12:49] <ogra_> which means you most likely dont have it on the disk needing this controller
[15:25] <rtg> 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:34] <tjaalton> rtg: -7.7 didn't have the latest pull request
[15:34] <tjaalton> so it's a genuine 4.2 bug :)
[15:35] <rtg> tjaalton, ok, -10.12 will get published today. I'll keep an eye on progress
[15:36] <tjaalton> seems to be upstream https://bugs.freedesktop.org/show_bug.cgi?id=91511
[15:37] <rtg> tjaalton, can you watch for a resolution on that bug ?
[15:37] <tjaalton> yep
[15:38] <rtg> tjaalton, isn't there a way to attach a watch on the LP bug ?
[15:38] <tjaalton> I'll add the bugwatch and cc myself upstream
[15:38] <rtg> cool
[15:38] <tjaalton> "also affects project", then paste the buglink. done that
[17:53] <old_benz> Hi guys, can anyone point me to the source for the Nexus 7 2013 kernel
[17:53] <old_benz> "flo"?
[18:39] <rtg> old_benz, 14.04 was the first release with a "flo" kernel. See 'git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git flo'
[18:40] <old_benz> rtg: thank you very much
[20:54] <hallyn> apw: oy ve.  are you sick of overlayfs yet?  cause there's a new problem with whiteouts for unprivileged containers:
[20:54] <hallyn> whiteouts are apparently created as character devices.  This means there is no way in a userns to rsync them
[20:54] <hallyn> (which is required for cloning such a container)
[20:54] <hallyn> issue was raised at https://github.com/lxc/lxc/issues/655
[20:54] <hallyn> stgraber: ^ :(
[21:02] <stgraber> oh, fun
[22:37] <apw> hallyn, hrm, that _is_ the format in there.  There is prolly a way to work round it in userspace, but hrmph
[22:41] <hallyn> 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] <apw> you could copy in junk to the whiteouts, and then mount the overlay, and rm them
[22:43] <apw> 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] <apw> (vile i know)
[22:44] <apw> 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] <hallyn> problem is rsync will fail, so how does a calling program know whether the only failures were expected whiteout failures?
[22:45] <hallyn> if we can detect that, then what you propose sounds...  well, like a decent workaround
[22:45] <apw> find -<chardev0> and use that list as an exclude, rsync, mount, rm the original list perhaps
[22:45] <hallyn> or maybe what we should be doing is simply mounting the two overlays and rsync from the one mount to the other
[22:46] <apw> that would make _much_ more sense
[22:46] <apw> doh
[22:47] <hallyn> 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] <hallyn> apw: yeah, that works.