=== ogasawara_ is now known as ogasawara === smb` is now known as smb [10:30] * apw looks out blearily on the world [10:40] apw: nothing see, you better going back :) [10:43] apw, Need some matches? [10:44] ppisati: heh a quiet day is always pleasant [10:44] smb: something stronger me thinks [10:45] apw, Hmmm, planks won't fit. Well at least noone from the other side of the pond will likely bug you today. [10:46] smb: heh no indeed. just need to make sure we are ready for tommorrow, other than that we are quiet i am sure [11:08] * smb thinks ppisati is a machine, though the numbering sometimes is confusing... [11:08] smb: i had all of them queued from dublin but since i dind [11:09] 't have smtp properly configured on my laptop, i waited since i got home [11:10] Heh, that explains a bit. Will try to have a look at them, though it seems the first half of the day has zipped past and its time for me to get my lunch [11:10] no prob [11:12] managed to break my initramfs (https://answers.launchpad.net/ubuntu/+source/initramfs-tools/+question/154973) for an encrypted lvm. On reboot, I'm now being dropped to a busybox shell every time. Is there somebody around who can help me fix this? [11:13] ohsix recommended "update-initramfs -c -k all" yesterday but that actually made things worse. initramfs file shrunk in size from 12 MB to 8. I was still being dropped to busybox, but then even the cryptsetup would fail (something about missing support for some kind of aes256 encryption) [11:14] nice [11:14] not really ;-) [11:14] do you have a distro kernel package installed? [11:14] yes [11:14] then the modules should be in the ramfs [11:15] http://paste.debian.net/121820/ [11:15] how can I verify what modules are needed and whether they are indeed in the initramfs? [11:18] by looking at the scripts that load them in /usr/share/initramfs-tools/ [11:18] like the cryptsetup package puts stuff in /usr/share/initramfs-tools/conf-hooks.d/ for example [11:19] a verbose boot should say when modules are requested but not found for mounting root, if the script that does it is even included [11:20] how can I get a verbose boot? [11:22] http://paste.debian.net/121821/ is the file list of one of the initramfs (a working copy IIRC) [11:24] does it ask for a passphrase at boot, or did it before? /usr/share/initramfs-tools/hooks/cryptpassdev is probably important [11:24] honestly if none of the files are missing or broken in all the components that do it, i don't know how it could break [11:25] from that file list it looks like the aes stuff is in there [11:25] that is the list of an initramfs that I think is working [11:25] oh wait [11:25] of course it's not working automatically [11:26] but working with the workaround [11:26] of manual entry at boot [11:28] i'd have to pretty much do what you'd have to do to figure out what's going on step by step, by looking at ehs cripts that generate stuff and run the boot [11:29] http://paste.debian.net/121823/ is the filelist of one of the initramfs created yesterday that won't work even with "cryptsetup luksOpen /dev/sda1 sda1_crypt". File size is actually 32MB vs 8 MB [11:30] to answer your question. When things were still working, I got prompted graphically for the passphrase at boot (very early on). [11:30] do you remember installing anything just before it broke? like watershed or something [11:30] I'll have another look at what was installed and removed [11:30] things did not break immediately or all at once [11:30] but only after the respective initramfs were updated after the removal [11:31] * apw idly wonders what release Laibsch is running [11:31] lucid [11:31] yar 32 is a classic [11:32] well fwiw, and i've got to run anyways; theres nothing too insane installed that hooks initramfs here, and here's a listing from a working one http://paste.ubuntu.com/637870/ [11:32] only thing out of the ordinary in there is some compcache stuff that is enabled but doesn't work in natty :] so the tools are there and idling [11:34] compcache should only trigger when you have <256M of ram ish [11:40] * Laibsch has 2G RAM [11:47] Laibsch, i don't have any scrollback and so no context whatsoever of your problem [11:54] apw: I managed to break my initramfs (https://answers.launchpad.net/ubuntu/+source/initramfs-tools/+question/154973) for an encrypted lvm. On reboot, I'm now being dropped to a busybox shell every time. Is there somebody around who can help me fix this? [11:55] I have to enter "cryptsetup luksOpen /dev/sda1 sda1_crypt;vgchange -ay;exit" in that busybox shell to continue [11:55] Laibsch, do any of your older kernels boot ok ? [11:58] Laibsch, and does your initramfs contains an /conf/conf.d/cryptroot file ? [12:03] conf/conf.d [12:03] conf/conf.d/uswsusp [12:03] conf/conf.d/driver-policy [12:03] it seems likely it does not, which i suspect is wrong ... [12:04] apw: I have a scripts/local-top/cryptroot file but otherwise only conf/conf.d/{uswsusp, driver-policy} as you can see in http://paste.debian.net/121821/ and http://paste.debian.net/121823/ [12:06] On the booted system, I have two cryptroot files (under /usr/share/initramfs-tools). They both belong to cryptsetup package. [12:06] Laibsch, what directories are they in [12:08] apw: http://paste.debian.net/121827/ [12:13] Laibsch, so if you rebuild your current kernels initramfs update-initramfs -u -k `uname -r` ... the replacement does not contain /conf/conf.d/cryptroot [12:14] (if so then that implies we are not detecting your encrypted root when building it [12:20] * apw waits for confirmation [12:21] apw: it looks like that is the case. the result of "sudo update-initramfs -u -k `uname -r` && cp /boot/initrd.img-2.6.32-31-generic /tmp/initrd.img-2.6.32-31-generic.gz -v && gunzip initrd.img-2.6.32-31-generic.gz && cpio -it -F initrd.img-2.6.32-31-generic" is http://paste.debian.net/121829/ and there is no such file. [12:21] I also get a bunch of lines like http://paste.debian.net/121830/ in /var/log/syslog [12:21] * Laibsch goes to google a bit [12:22] Laibsch, ok, so what is in your /etc/cryptab, that seems to be where it is looked up [12:22] sda1_crypt UUID=6b7021eb-b178-449d-ac4c-40dd2592b778 none luks [12:23] Laibsch, and your /etc/fstab ? [12:23] UUID="ecbd7524-29ea-47d6-b8aa-755c9677194c" / ext4 errors=remount-ro 0 1 [12:24] different uuid [12:24] Laibsch, no information to know if that is right or not at this point, as one may be the crypted container and one the fs inside [12:25] I'm trying to find out how to read the uuid value of a partition [12:25] blkid? [12:25] Laibsch, right, i suspect that blkid on the raw will match one, and the crypt the other [12:29] apw: http://paste.debian.net/121831/ there's the two uuid [12:30] Laibsch, you didn't flush any lvm tools off the machine as well did you ? [12:32] or indeed any dmraid tools [12:32] as the disk detector seems to use such tools to work out what your root is called underneath [12:33] grep the aptitude logs for dm and lvm does not return anything [12:34] lvm2 is installed as well as dmsetup. dmraid is not [12:34] Laibsch, whats your shell scripting like? the next step is to debug the script cryptroot-hook in your /usr/share/initramfs* [12:34] you mean how strong is my shell foo? [12:34] average [12:35] particularly the add_device function which is meant to be finding the disk [12:35] low to average [12:35] you only really need to be adding like echo "blah" >>/tmp/LOG into it in place [12:35] places so we can work out why its not finding your root and making cryptroot config file [12:36] so checking that add_device is called and with what node opts lastopts etc [12:36] and later there is a loop, for node in $nodes [12:36] be nice to know what if any nodes it sees there [12:36] brb [12:37] will look through it in [12:37] a minute [12:37] Laibsch, np [12:38] Laibsch, and indeed in that loop there is a direct echo into the config file in question [12:38] so the if stanza before it is also interesting to see if it is causing us to loop [12:43] * ppisati -> goes to hunt some food... [12:47] * apw sees ppisati packing up his bow and arrow and daubing on camoflauge paint [13:01] * Daviey After experiencing multiple kernel panics on his phone he has realised that he cannot remember the last time he had a kernel panic under Ubuntu.. how things have changed! [13:01] Daviey, i suspect you are just no longer able to see them :) [13:02] apw: hah. [13:02] Daviey, they are hidden by the lovely GPU hangs [13:03] * Daviey spots apw whying away from a complement. [13:03] shying* [13:03] Daviey, who me, shy, seems unlikely :) i suspect we have the advantage of using a kernel released this year [13:05] ah [13:06] then again with that you'd have a lot less holes to root your phone [13:08] heh === Quintasan_ is now known as Quintasan [13:36] apw: forgive me ignorancy, but what do I do with /usr/share/initramfs-tools/hooks/cryptroot? I had a look through it and understood only the general idea. I tried calling it as "sudo sh /usr/share/initramfs-tools/hooks/cryptroot" but I guess that's not how it's done. I assume line 391 is the key, but how do I find the infromation to understand what's wrong with the output? [13:39] Laibsch, that script is run when you are doing the update-initramfs -u stuff [13:39] OK [13:39] Laibsch, so you can add debug which records information in a file in tmp [13:39] and then run the update to see what it says [13:39] Laibsch, remember to cp the file before so you can repair it [13:40] "set -x" and "set -v"? [13:40] git clone git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git; cd ...; fakeroot debian/rules clean; fakeroot debian/rules binary-headers binary-generic [13:40] WARNING: drivers/built-in.o(.data+0x1bc38): Section mismatch in reference from the variable ab3550_driver to the function .init.text:ab3550_probe() [13:41] would that be why the build to failed? [13:41] Laibsch, if that doesn't affect behaviour then perhaps so ... remember to run this inside 'script' so we get all the output then [13:41] CarlFK, i'd be supprised if that warning caused a compile failure [13:42] CarlFK, what did the bottom of the build say [13:42] tail of the build log: http://dpaste.de/Zh3L/ [13:42] apw: "run inside 'script'"? what does that mean? [13:42] Laibsch, run 'script' that starts a new shell in which all output is recorded into file called typescript [13:42] run the update-initramfs ... inside there, then exit to get back to normal [13:43] Laibsch, apw You could also place "set -x" debug on and "set +x" debug off inside the script around blocks of interest [13:43] smb, yep much of the script is of interest sadly [13:43] CarlFK, the error is earlier, search backward for Error, note we are building in parallel so it can be a long way up [13:46] apw: building in parallel - got it. [13:56] gcc: error: /lib/modules/3.0-3-generic/build/include/linux/autoconf.h: No such file or directory [14:07] apw, smb: I'm only marginally smarter after http://paste.debian.net/121843/. But it seems that only /dev/mapper/1001P-root (mounted as /) is being taken into account. The lvm itself at /dev/sda1 with uuid 6b7021eb-b178-449d-ac4c-40dd2592b778 is not. [14:08] CarlFK Hm, are you building something out of tree? [14:08] * Laibsch is off for some sleep [14:09] Sounds a bit like something erased parts of the headers. Maybe you can fix it by forcing a reinstall of the linux-headers package [14:09] good night and thank you very much smb, ohsix and apw [14:09] smb: I'll do that, thank you [14:09] oh, I suppose that comment was not directed at me [14:09] smb, those are in the builds directory, so they sound like something missing from the prepare phase [14:09] Laibsch, No sorry [14:10] CarlFK, how are you triggering the build [14:10] apw, Thats what made me think of out of tree. Cause those usually head for /lib/modules/$(uname -r)/... [14:11] smb, right but the missing file is expected in a build directory, which implies its the early internal conf phase which was meant to make it, and has not [14:12] apw, hm build is also a soft link pointing to /usr/src in you libs [14:12] apw: fakeroot debian/rules binary-headers binary-generic [14:12] smb, ok now its me who isn't reading the filename in full ... [14:13] apw, Though the call rather suggest normal kernel build from git tree [14:13] smb, but if its building that way it really should not be referencing anything outside the tree [14:13] Agreed [14:13] apw: i think i see the problem... [14:16] Maybe its as simple as doing a fdr clean before to avoid any cruft interfering... [14:19] btw: running oneiric, so brokeness isn't surprising (just noticed that, thought it was natty) [14:27] apt-get build-dep linux-meta; should that include linux-headers? [14:30] I think i got it: building 3.0.3, but have linux-headers-3.0-2 [14:30] CarlFK, you shouldn't need headers installed to build a kernel, it is the thing which makes them [14:31] oh right. [14:31] * apw wonders if the binary-headers is missing a dependancy [14:31] does fdr binary-generic binary-headers work any better [14:32] failing that, could you use script to get the whole output of the build and pastebin it [14:35] apw: what is fdr? [14:39] CarlFK, We have an alias for fakeroot debian/rules [14:39] (lazy to type) [14:44] heh [14:44] wc typescript; 2681 7377 124877 - what's a light pastebin? [14:46] http://paste.ubuntu.com/637946/ [14:49] Hrrm, why is it looking for 3.0 headers while you seem to be building 2.6.38... [14:52] CarlFK, Just to confirm, are you building in a Oneiric environment? [14:52] smb: correct [14:53] Just wondering whether we accidentally broke something while fixing all the 3.0.0 -> 3.0 fallout... [14:53] smb, if we couldn't build an oneiric kernel in oneiric we couldn't upload kernels full stop [14:54] oh i wonder if this is that stupid rtl drivers [14:54] driver which uses uname -r [14:55] make[3]: *** [ubuntu/rtl8192se] Error 2 [14:55] yeah its that STUPID STUPID STUPID rtl driver [14:55] so ... two things [14:55] Do you still need that one? [14:56] The rtlwifi driver seems to support most of the se varients now [14:56] mjg59, no i think in 3.0 kernels it has been stripped but it is still in the natty build he is doing [14:56] Ah, sorry, I see [14:56] and the makefiles for it use uname -r ... which is mad [14:56] Well at least it's not calling uname at runtime [14:56] mjg59, heh i suppose [14:56] Which I wouldn't put past them [14:57] CarlFK, there is a line which looks like this: [14:57] ifeq ($(shell uname -r|cut -d. -f1,2), 2.6) [14:57] in ubuntu/rtl*/Makefile ... [14:57] remove it and replace it with ifeq (1,1) [14:57] and life will stop hurting [14:58] i'll get that pulled back to natty ... BAH HATE HATE HATE [14:59] CarlFK, do you have a LP bug filed for this problem [14:59] apw: no, guess I should? [14:59] CarlFK, just let me know your launchpad id and i'll sub you to the one i am making now [15:01] carlfk [15:06] CarlFK, bug #805494 [15:06] Launchpad bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,In progress] https://launchpad.net/bugs/805494 [15:09] ubot2, !sru [15:09] Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [15:10] git checkout -b lp805494 origin/master-next [15:10] oh thanks paste buffer, thats SO helpful [15:11] perhaps you could contains my password for my bank account next time [15:11] apw, Are you starting to blog your git foo too? :-P [15:11] * apw takes smb outside for an education session [15:12] * smb tries to run faster [15:12] git checkout smb-face; git reset --hard HEAD^1 [15:12] error: no such branch [15:12] and the pause was about the right length ... COME ON GIT [15:13] * apw really needs to turn off atime updates ... or read every file at 6am every day [15:18] Hi, I'm trying to kernel bisect and while building, apart from the bisect, I change only the changelog with numbers ~bgo1234vish0 , ~bgo1234vish1 and so on.. but after booting into the newly build kernel when I check using $uname -a , it only shows as ~bgo1234vish0 , the first version number while the package number is the right one... is that OK or am I not building the right version? how do I fix that version number displayed in $uname -a ? [15:19] vish, the version number reported was the one in the source when it was built. If you are changing debian.master/changelog then it only takes effect on the next fakeroot debian/rules clean [15:20] apw: so I should clean every time I build? [15:20] vish really yes [15:20] k.. [15:20] apw: so, was I building the wrong version? and I should start bisect again? [15:21] vish i would say its hard to tell as you discovered, you may be able to tell from what it built as to whether it was valid or not [15:21] if it took close to a full build time, then likely it has the right contents, but its hard to be sure [15:21] hmm.. [15:22] bah! need to start again :p [15:22] vish where you bisecting between ? [15:22] between .35 and .34 [15:22] (wonder if you can use the mainline builds to narrow the search any) [15:23] the error started in .35, and still exists in Mainline current.. atleast till .39 [15:23] vish have you tries the mainline 34-rc builds? [15:24] yea, tried in mainline versions too [15:24] https://bugzilla.kernel.org/show_bug.cgi?id=33912 « thats my bug.. [15:25] vish, and doesn't that help eliminate some of the range [15:25] bugzilla.kernel.org bug 33912 in Video(DRI - non Intel) "[RV515] Kernel .35 onwards, Random X freezes while scrolling" [High,New] [15:28] i tried the most closest versions I could find.. and the issue being random doesnt help either :s [15:28] no i bet [15:28] you are in a world of pain and no mistake [15:29] apw: how do I reset the bisect ? [15:30] hmm, /me looks in --help and RTFM's :D [15:30] there is a way to abort it, a sub-command of bisect, you can also get out the log and it contains the incantions too [15:30] so you can run forward to when you were unhappy [15:30] k.. [15:54] apw: apparently i think you need more frustration today, cuz I went and dug up more instances of that bug, just for you: http://paste.ubuntu.com/637972/ find Makefile grep "shell.*2\.6" [15:56] CarlFK, most of those are either explicit against a specific version or just copes of the orignals [15:56] copies [15:56] or maybe I did it because the build still broke and I want it fixed :) [15:57] copies? [15:57] all the ones in debian are build output [15:58] the others are all explicit matches against a fully formed version number [15:58] and so are fine as they never have matched and never will whatever the version number is [15:58] copies was the correction of copes in the previous sentence (probably wondered about that) [15:58] right [15:58] apw: what about line 5: ./ubuntu/rtl8192se/Makefile:ifeq ($(shell uname -r|cut -d. -f1,2), 2.6) [15:59] CarlFK, what line is it on [15:59] 7 [15:59] * smb wonders whether that was the makefile with many repeats of the same but ifndefed most of the time. So only one actually survived [16:00] CarlFK, thats the one which the patch changes [16:00] hmm, yeah, but I fixed it... so something is bringing it back [16:01] that must be outside the build system [16:01] oh, no... i fixed the copy [16:01] my mistake [16:38] hello! [16:38] I asked the following question in #ubuntu-devel already: "Can someone point me to some config or thelike within the repo to get an impression on server and desktop kernel differences?" [16:39] Can you provide me with some information? I know there are differences but I'd like to see the comple flags and such in comparison. [16:39] I think I can find that.. .give me a sec to dig [16:39] Aquina, that is all in the kernle git report [16:40] git repo even [16:41] Aquina: Just out of interest, what are you hoping to determine? [16:49] can someone confirm this is the desktop config: [16:49] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=blob;f=arch/x86/configs/x86_64_defconfig;h=ee01a9d5d4f0a7b8e3bd9f6e4f86fb28e7fe2b68;hb=HEAD [16:51] I am not seeing where the server config lives. which I think is the only difference between the desktop and sever kernels, right? (same base and patches, different config) [16:51] CarlFK, nope that is a default config [16:51] the easiest way it to checkout the kernel source and run fakeroot debian/rules genconfigs [16:51] and look in CONFIGS/* [16:53] k - I'll stop spelunking. Aquina, do that ^^^ [16:54] huzzah! dpkg-deb: building package `linux-headers-2.6.38-10-generic [17:29] ppisati, about ? [17:37] apw: what? [17:38] ppisati, s'ok i've resolved what i needed to ask and am happy [17:38] ok :) [17:38] that was quick [17:38] ppisati, just to say -NNN3 is now -4243, it merged with that CVE [17:39] ah ok, saw that [17:39] i'll send-email again (perhaps just that patch now...) [17:40] apw: thanks for uploading linux-meta [17:41] ogasawara, np, i thought you were off all week ... [17:41] ogasawara, i did have to push over it, as there was a change for versatile which was missing [17:41] apw: yep, saw that. thanks. [17:43] * ogasawara goes back to being on vacation [17:52] ogasawara, good, have a nice time [18:14] * ppisati -> gym [18:30] Daviey I'd like to verify that there is more diference between those Kernels than someone told me. I'd like to prove that person wrong. [18:32] Hi, I'm doing a kernel bisect in http://bugs.launchpad.net/bugs/805209 and on one of the iterations I'm left with a kernel that doesn't compile (but is unrelated to the bug), do I just mark that bisect as bad and carry on? [18:32] Ubuntu bug 805209 in linux "System locks up after upgrading to linux-image-2.6.32-32-generic-pae" [Undecided,New] [18:32] Aquina: reminds me of http://xkcd.com/386/ [18:34] :-) [18:35] I know that. The most lovely one is the one with "angular miomentum". [18:35] http://xkcd.com/162/ [18:54] anyone have an idea for above? === tsimpson_ is now known as ts2 [19:11] TREllis, nope, you normally just reset head to a nearby commit which can compile and test that [19:11] TREllis, and bisect will use the commit as it was at the time you say good/bad [19:14] apw: hmmm not sure how I'd do that [19:15] TREllis, normally the easiest is to strip a commit off the top and see if that one is better [19:15] TREllis, as in git reset --hard HEAD^ [19:16] git bisect only cares about which ones you did test it doesn't care if its the one it suggests [19:16] ah ok [19:16] if its not possible to find one nearby you can do other things like try both good and bad and test both of the results; but you'd need to take a git bisect log before so you can reset the bisect [19:19] apw: ok thanks, added the log to the bug [19:20] TREllis, that log is a direct set of executable commands to get you back to the same place [19:21] i really miss having a large amount of mainline daily kernels available to make bisecting muuch easier by narrowing it down to a day first [19:29] is that not working? [19:30] Sarvatt, why do you not have them> [19:32] oh i suppose we clean them up now ... hmm as they are vast [19:33] Sarvatt, i guess the problem is that the -rcs are weekly [19:48] yeah thinking about it more it's always one huge merge that introduced the problem I run into and no more changes to that subsystem go in between rc's so I guess it isn't any different (it's always i915 i'm bisecting) === ayan_ is now known as ayan [20:50] apw: woot! after 5 resets I'm back on something that'll compile === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan [23:26] hi [23:27] if I wanted to experiment with some changes to dmraid on my natty box; whats the best way to get the source (apt-get source; bzr branch lp:ubuntu/linux; git ?) [23:28] I'd like to be building the kernel with the same options the deb I have uses, but probably not build all the different flavours; then eventually take my patch and offer it for inclusion [23:32] lifeless: I would say to use git, git clone git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git [23:33] kk; whats the best way to build the kernel + initramfs to match the deb ? [23:35] lifeless, it depends, if you want only the generic kernel, "fdr binary-generic" should do it [23:36] yeah, the box is running -generic [23:36] thank you! [23:37] about changing options, you can use "fdr editconfigs" for example [23:37] I've not heard of fdr [23:37] or edit manually configs at debian.master/config, and run fdr updateconfigs [23:37] I guess its new (== in the last 7 years since I did regular kernel changes) [23:37] fdr == fakeroot debian/rules [23:37] just easier to alias it instead of typing entirely [23:38] doh, ok :)