| === skaet_ is now known as skaet | ||
| === hughhalf_ is now known as hughhalf | ||
| ppisati | moin | 07:08 |
|---|---|---|
| === smb` is now known as smb | ||
| * smb tries to get in unseen | 07:14 | |
| === Guest8994 is now known as tlei | ||
| ppisati | brb | 08:52 |
| dileks | apw: http://marc.info/?l=linux-kernel&m=134519512112692&w=2 | 09:33 |
| apw | heh, that sounds like fun | 09:48 |
| dileks | apw: s***storm expected | 10:07 |
| apw | dileks, i expect it will just get ignored actually | 10:07 |
| apw | though al migh reply and tell us if union-mounts is going in or not | 10:07 |
| dileks | I repeated consciously the word "finished" and remembered the nvidia-f-u video, so this will ring bells (I hope so). but lets see. | 10:09 |
| apw | well its not like overlayfs is finished either | 10:09 |
| apw | its all pretty tricky | 10:10 |
| dileks | apw: if the code is upstreamed more people will look at it and use it. its more a phychological thingie. /me thinks of enlightenment DR17 (OK, the major libs have now stable versions :-), but ...) | 10:15 |
| apw | dileks, there is that, overlayfs has semantic issues (due to its attempts to be performant) that i am not sure will ever be acceptable | 10:16 |
| apw | to the purists | 10:16 |
| dileks | I remember a faculty meeting where one professor throw into the round, only (software engineering) fundamentalist talk like this... rebellion or kindergarden I dunno. he sould have said "purists", hehe. | 10:19 |
| dileks | apw: and miklos somehow reminds of IBM and OS/2 | 10:19 |
| dileks | hope he will not throw away his own code | 10:20 |
| dileks | marketing seems to be a foreign word to him | 10:20 |
| dileks | I suggested to get overlayfs into linux-next | 10:21 |
| dileks | out of my own experiences... linux-next is better tested than any rcX (upstream) :-) | 10:22 |
| dileks | https://lkml.org/lkml/2012/8/16/602 | 10:22 |
| caribou | smb: howdy, just saw your comment about the kdump kernel issue in Quantal | 10:29 |
| smb | caribou, Hi there. Well, just made it. :) | 10:30 |
| caribou | smb: just so I understand things correctly : this is not specific to our kernel but is in any mainline kernel above 3.5 ? | 10:30 |
| smb | caribou, right | 10:31 |
| caribou | smb: if so, shouldn't it be brought up to the kexec ML ? | 10:31 |
| smb | caribou, Well it is an issue that ends up making the limited memory even more limited. I don't think it is something that kexec needs to change but the kernel. | 10:32 |
| caribou | smb: I know, but maybe the kexec people oughta be aware of it (I mean the fact that it doesn't work) | 10:33 |
| caribou | smb: afaik, hpa is on the kexec ML | 10:33 |
| smb | But feel free to take it to the kexec ml | 10:33 |
| smb | So maybe that would be another way to make him aware | 10:34 |
| smb | He was cc'ed on the lkml discussion but I can understand when people miss things there | 10:34 |
| caribou | smb: it's worth a try. I just don't wanna make a fool out of myself by stating the obvious :-) | 10:36 |
| caribou | smb: to me, it looks like the full kexec mechanism doesn't kick in, which should have been seen before | 10:37 |
| smb | caribou, I wonder, did you try with more than 128M of crashkernel memory? | 10:37 |
| caribou | smb: nope, but I can try, I just prepared a VM for that | 10:38 |
| smb | (that would be 64bit, on 32bit it would be a different problem) | 10:38 |
| caribou | smb: yep, x86_65 | 10:38 |
| caribou | euh, 64 | 10:38 |
| smb | heh :) | 10:38 |
| * smb always needs to refrain from saying 31 bit | 10:38 | |
| smb | caribou, So basically the problem is that on 64bit, due to some mismatch you have about 3 to 6MB (rough estimate) more memory wasted to initial page tables. | 10:40 |
| smb | Depends of course on the amount of memory you have on the machine | 10:41 |
| caribou | smb: with a 2G VM, even with 256M reserved it doesn't work | 10:42 |
| smb | caribou, what kind of vm (xen, kvm, virtualbox,...)? and does a normal (non-crash) kexec work there? | 10:43 |
| smb | The problem could be a different one just in the VM | 10:44 |
| caribou | smb: it's a KVM vm. | 10:48 |
| caribou | smb: I'll try to test on baremetal when I have a minute | 10:48 |
| * henrix -> lunch | 11:41 | |
| smb | *sigh* is it just me or is a kvm using cirrus graphics currently broken in quantal (had to blacklist the cirrus kernel module otherwise the X driver went into a corner and sulked) | 12:30 |
| apw | smb, not tried that i am afraid | 12:34 |
| smb | Of course I have not looked what modules were loaded and which driver was used before that giant upgrade... | 12:38 |
| siretart | hi. - I'm currently testing the fai (fully automated installation) package in ubuntu, and am struggling with technicalities in the kernel | 12:42 |
| siretart | it seems that aufs has been disabled currently in quantal. is this correct, and is the plan for release to leave that disabled in favor of overlayfs? | 12:43 |
| apw | that is the current plan, though it was the plan for P as well, and it didn't work out | 12:43 |
| siretart | I've also tried overlayfs, but I got a kernel oops when trying it with an nfsroot | 12:43 |
| siretart | I didn't find nor file a bug for that yet, I'm still checking the options here. | 12:44 |
| apw | always interested in overlayfs triggered opses | 12:45 |
| siretart | let me phrase it as a question: is overlayfs supposed to work with NFS? | 12:45 |
| apw | there is an indication that NFS is not complete enough to be suitable | 12:46 |
| apw | (as an UPPER filesystem) | 12:47 |
| apw | otherwise i suspect it is expected to work | 12:47 |
| siretart | I'm not sure if I undestand the 'UPPER' part correctly. The setup is to mount the nfsroot read-only from the installation server, and use unionfs to mount a tmpfs ontop of that in early userspace, then continue booting | 12:48 |
| apw | in that context the NFS is LOWER | 12:48 |
| siretart | ok | 12:48 |
| apw | so i think the docs say we might it expect it to work indeed | 12:48 |
| apw | cirtainly i have never tried that combo | 12:49 |
| siretart | I'll try to reproduce this in non-initramfs context (i.e., on an properly booted system) first, and see if that's enough to describe a test-case. thanks for explaining the current situation and what to expect. | 12:49 |
| apw | ok cool. do ping me with the bug number when you get that far | 12:50 |
| siretart | willdo | 12:50 |
| siretart | apw: yep, I managed to reproduce it without early userspace. http://pbot.rmdir.de/ba0ec9f8742a0a0dce7ffcd24db00c12 - filing a bug now | 12:59 |
| siretart | apw: filed as bug #1038075 - feel free to ping me either here or in #ubuntu-devel if there is any additional information that might be useful here | 13:08 |
| ubot2` | Launchpad bug 1038075 in linux "[Overlayfs] kernel OOPS with NFS" [Undecided,New] https://launchpad.net/bugs/1038075 | 13:08 |
| rtg_ | apw, sbuild wants aufs, doesn't it ? | 13:22 |
| apw | rtg_, i believe it uses overlayfs as well | 13:23 |
| siretart | rtg_: sbuild itself doesn't care, but schroot deals with aufs if configured to do so | 13:23 |
| apw | i thought the default changed recently, i'd have to check | 13:24 |
| siretart | the mk-sbuild script from the ubuntu-dev-tools package switched the default from aufs to overlayfs in quantal | 13:24 |
| apw | if only the three upstream groups could talk to each other and sort out the problems | 13:24 |
| siretart | I did that only a couple of days ago | 13:24 |
| apw | smb, might that explain why your builds all broke ? | 13:25 |
| rtg_ | apw, siretart: I'm using a quantal setup in a chroot, but a precise host. I guess I should just install a vanilla precise. this is on an ARM system. | 13:25 |
| siretart | could aufs be provided as out-of-tree add-on kernel module package in quantal? | 13:26 |
| apw | that doesn't really reduce the maintenance burden which would be the point of not building it | 13:27 |
| smb | apw, No I am still P. My "error" was to a( have switched from lvm snapshots to overlay and b) have set build_dir which seems to cause the actual build go into /build (which is overlay) | 13:27 |
| siretart | rtg_: I think the switch to overlayfs by default was already done for precise, if I read the changelog correctly | 13:27 |
| siretart | version number 0.136, dated Wed, 16 Nov 2011 14:33:04 +0200 | 13:28 |
| rtg_ | siretart, right. I know that sbuild works correctly in precise. it sure doesn't seem to in quantal. | 13:28 |
| apw | really waht issues you seeing, i am pretty sure my builder here is quantal using overlay for sbuild | 13:29 |
| siretart | rtg_: as said, with the test machine here that I have (amd64, upgraded from precise to quantal) mk-sbuild seems to work just fine for me | 13:29 |
| rtg_ | hmm | 13:29 |
| apw | that fits with my expectations too | 13:30 |
| rtg_ | dunno. I'm using this hacked up nano image from linaro. | 13:30 |
| apw | ahhh ... eeep | 13:30 |
| rtg_ | think I'll start over | 13:30 |
| siretart | too bad that this booting via nfsroot is quite critical for our deployment here :-( | 13:31 |
| rtg_ | apw, turns out this dang Linaro kernel has neither overlayfs or aufs. Guess I'd better fix that first. | 13:37 |
| apw | qualtity | 13:37 |
| ppisati | ogasawara: rtg_: after rebasing Q/omap4 on -11.11 i found a regression on boot. so i'll need some time to check what's going on | 14:01 |
| ogasawara | ppisati: ack | 14:01 |
| ppisati | but i would really like to upload 3.5 Q/omap4 even if it's still on -9.9 | 14:02 |
| rtg_ | ppisati, send a pull request. we can catch up to -11 next week. | 14:02 |
| ppisati | ack | 14:02 |
| ppisati | besides, i wanted to warn you that, no matter what we do, beta1 omap4 desktop image is going to be broken due to missing 3d driver | 14:03 |
| smb | caribou, So I have proof now that kvm crash-kexec works when fixing up the too big page table (4M->16K) and crashkernel=128M but it would not work with crashkernel=256M and the unpatched kernel. | 14:34 |
| caribou | smb: good ! | 14:34 |
| caribou | smb: I didn't get to test on realiron | 14:35 |
| * ogasawara back in 20 | 14:35 | |
| smb | caribou, Cannot really explain why. Probably it is not alone the size but also the location or increasing crashkernel= over a certain number is as bad as not being big enough... | 14:36 |
| akua | Can someone help me. I am trying to compile a kernel ( into a deb so I can copy it to a few systems at my work ). I need to use the linux 3.5.x kernel because of USB3 support, however I am trying to stay on Ubuntu 10.04 for the time being. Everything is going well, I had a lot of problems finding a .config that worked OK, but before I install the kernel-image.deb, I have to copy initramfs from | 14:46 |
| akua | /usr/share/doc/kernel-package/examples/etc/kernel/postinst.d/initramfs into /etc/kernel/initramfs or the kernel panics on reboot. | 14:46 |
| caribou | smb: might be a good idea to put your findings in the bug; I will refer to it if I post to the kexec ML (maybe monday) | 14:46 |
| akua | I would rather the deb has all the files and actions necessary, but it seems it doesn't. I am building the deb with the command: "fake root make-kpkg --initrd --append-to-version=-test1 kernel-image kernel-headers" | 14:47 |
| smb | caribou, I should ... and thought I had some but right, I will update it | 14:47 |
| rtg | akua, have you tried just installing the quantal kernel ? | 14:48 |
| akua | I also tried the "AUTOBUILD=1 fake root debian/rules binary-debs" method on a git checkout from quantal, but ended up with debs that had no usb hid_drivers, etc. | 14:48 |
| akua | ya. I tried that, but it was built with gcc 4.6, and some new version of glibc and then I couldn't compile any kernel modules after the fact, which I must do to run the devices ( capture cards, etc ) required. | 14:49 |
| rtg | akua, remember that the git checkout method produces _2_ packages that need to be installed. linux-image and linux-image-extra | 14:50 |
| rtg | you might also need the linux-firmware package from precise or quantal to pair up with kernel drivers that need newer firmware. | 14:52 |
| akua | rtg: what do you mean about the firmware, is it only if i use the pre-built quantal kernel, or even if i compile my own? | 14:53 |
| rtg | akua, yes, you should use a newer linux-firmware in either case | 14:54 |
| akua | rtg, i was hoping to build my own kernel-image.deb so I can use a specific kernel, do I need to compile my own firmware then, or is it 'generic'? | 14:55 |
| rtg | akua, its largely generic | 14:56 |
| * rtg reboots gomeisa for kernel update | 14:58 | |
| akua | rtg: and there is no easy/obvious solution as to this initramfs problem? I can probably live with it, but for the firmware should I just install linux-image and linux-firmware ( the one from quantal ) and everything should work? | 15:16 |
| rtg | akua, yes, but don't forget linux-image-extras | 15:16 |
| akua | it seems the debian/rules method makes one of those, but the make-kpkg doesn't | 15:21 |
| akua | rtg: ok, the git method seemed to work, but the headers won't install cleanly because it (linux-headers-3.5.0-10-generic) depends on 'linux-headers-3.5.0-10'. Can I build this? | 15:32 |
| rtg | akua, build binary-indep (I think) | 15:34 |
| === kamal1 is now known as kamal | ||
| * smb -> EOW | 16:12 | |
| apw | binary-headers might do it too | 16:25 |
| * henrix -> EOD | 16:52 | |
| * ppisati -> EOW | 17:07 | |
| cwillu_at_work | quick question: the 32-bit mainline packages seem to have some magic to detect whether the cpu supports pae or not; I'm trying to roll a test image, but I can't install that package on the build server because cpuinfo doesn't reflect the target hardware | 18:07 |
| cwillu_at_work | is there a way to ignore that check? | 18:07 |
| cwillu_at_work | "This kernel does not support a non-PAE CPU. | 18:08 |
| cwillu_at_work | dpkg: error processing /tmp/linux-image-3.5.2-030502-generic_3.5.2-030502.201208151151_i386.deb (--install)" | 18:08 |
| rtg | cwillu_at_work, unless you've changed the config options, then I don't think the mainline kernel is gonna work. | 18:10 |
| === mfisch` is now known as mfisch | ||
| === mfisch is now known as Guest37216 | ||
| cwillu_at_work | rtg, how do you mean? | 18:13 |
| rtg | cwillu_at_work, I mean the its not gonna work on a non-PAE capable CPU | 18:13 |
| cwillu_at_work | rtg, I'm not running a non-pae capable cpu | 18:13 |
| cwillu_at_work | the cpu supports pae just fine | 18:13 |
| cwillu_at_work | the problem is the build environment | 18:14 |
| rtg | cwillu_at_work, well, the check is in the pre-inst. perhaps it is incorrect ? | 18:14 |
| === Guest37216 is now known as mfisch | ||
| cwillu_at_work | rtg, I don't doubt that the check is correct, it's just that I really do know better than it in this case | 18:19 |
| rtg | cwillu_at_work, well then, hack on debian/control-scripts/preinst to remove the check and rebuild the kernel. | 18:20 |
| cwillu_at_work | rtg, I see a grim future of never being able to use the packaged kernels for automated installs though | 18:21 |
| cwillu_at_work | I'm mainly wondering if there's an existing flag to slap it down (--force-architecture should seem to imply this sort of thing, although that's primarily for dpkg I suppose) | 18:22 |
| rtg | cwillu_at_work, yeah, I don't see a way around it. preinst is part of the package and it wants to see 'pae' in /proc/cpuinfo | 18:22 |
| * rtg -> lunch | 18:25 | |
| Eimann | sweet, https://eimann.etherkiller.de/nmz/panic-cisco-dlm-java-applet-in-ff.JPG - happens with 3.6.0-999-generic #201208090423 on x86_64 with 7~u3-2.1.1~pre1-1ubuntu3 openjdk when using the cisco software download manager in firefox 14.0.1+build1-0ubuntu0.12.04.1 | 18:30 |
| cwillu_at_work | rtg, I think I got it faked out by plopping the word into an empty cpuinfo; first attempts didn't work as it's actually looking for " pae ", while I had tried a simple "pae" :p | 18:31 |
| cwillu_at_work | even so | 18:31 |
| * cwillu_at_work leaves a postit reminder on his monitor to file a bug | 18:31 | |
| akua | I built my own kernel, and linux-image and linux-headers installs as expected, and boots with everything working. However, I am trying to compile nvidia's drivers ( because I need CUDA ), and it is complaining about not being able to find the headers. | 19:42 |
| akua | the director "/usr/src/linux-3.5.2-custom1/ exists, but /lib/modules/linux-3.5.2-custom1/build and /lib/modules/linux-3.5.2-custom1/source point to /usr/src/linux-3.5.2 | 19:45 |
| akua | but if i link /usr/src/linux-3.5.2to /usr/src/linux-3.5.2-custom1 it still fails | 19:46 |
| * rtg -> EOW | 20:37 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
