| === 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- | ||
| 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:30 |
| caribou | https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1496317 follows that problem | 09:31 |
| ubot5 | Ubuntu bug 1496317 in kexec-tools (Ubuntu) "kexec fails with OOM killer with the current crashkernel=128 value" [High,Confirmed] | 09:31 |
| apw | caribou, ugg, hrm | 10:17 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| caribou | apw: 24M more in ./lib for 4.2 | 10:49 |
| caribou | apw: changing MODULES=most to MODULES=dep in initramfs.conf brings the initrd from 29M to 12M & works around the issue | 12:13 |
| ogra_ | changing to =none brings it to 2MB ;) | 12:14 |
| caribou | ogra_: yes, but mine still boots :) | 12:14 |
| ogra_ | mine too :) | 12:14 |
| * 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:15 | |
| 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:44 |
| 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:45 |
| apw | right but you are above averagely lucky i assume | 12:46 |
| ogra_ | because i dont use a zfs root ? | 12:47 |
| ogra_ | :P | 12:47 |
| 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:48 |
| 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 | 12:49 |
| 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:25 |
| ubot5 | bug 1496433 in linux (Ubuntu) "Error in i915 driver" [Undecided,New] https://launchpad.net/bugs/1496433 | 15:25 |
| tjaalton | rtg: -7.7 didn't have the latest pull request | 15:34 |
| tjaalton | so it's a genuine 4.2 bug :) | 15:34 |
| rtg | tjaalton, ok, -10.12 will get published today. I'll keep an eye on progress | 15:35 |
| tjaalton | seems to be upstream https://bugs.freedesktop.org/show_bug.cgi?id=91511 | 15:36 |
| ubot5 | Freedesktop bug 91511 in DRM/Intel "[drm:check_crtc_state] *ERROR* mismatch in ips_enabled (expected 1, found 0)" [Normal,Needinfo] | 15:36 |
| rtg | tjaalton, can you watch for a resolution on that bug ? | 15:37 |
| tjaalton | yep | 15:37 |
| 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 | 15:38 |
| old_benz | Hi guys, can anyone point me to the source for the Nexus 7 2013 kernel | 17:53 |
| old_benz | "flo"? | 17:53 |
| rtg | old_benz, 14.04 was the first release with a "flo" kernel. See 'git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git flo' | 18:39 |
| old_benz | rtg: thank you very much | 18:40 |
| 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: ^ :( | 20:54 |
| stgraber | oh, fun | 21:02 |
| apw | hallyn, hrm, that _is_ the format in there. There is prolly a way to work round it in userspace, but hrmph | 22:37 |
| 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:41 |
| apw | you could copy in junk to the whiteouts, and then mount the overlay, and rm them | 22:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| apw | that would make _much_ more sense | 22:46 |
| apw | doh | 22:46 |
| 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 | 22:47 | |
| hallyn | apw: yeah, that works. | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!