| MTecknology | Where can I pull down the kernel source and default .config? | 02:44 |
|---|---|---|
| lifeless | debcheckout linux-x-y-z | 02:44 |
| MTecknology | !info debcheckout | 02:45 |
| ubot3` | Package debcheckout does not exist in jaunty | 02:45 |
| MTecknology | !search debcheckout | 02:45 |
| ubot3` | Found: | 02:45 |
| MTecknology | lifeless: ? | 02:46 |
| Darxus | Heh. | 02:50 |
| Darxus | MTecknology: You already have the .config you're using, somewhere in /boot/. | 02:50 |
| Darxus | There is a linux-source package... | 02:50 |
| MTecknology | thanks :) | 02:52 |
| Darxus | You're welcome. | 02:52 |
| MTecknology | hopefully I actually know enough to go mucking around in it :P | 02:53 |
| lifeless | the linux-source package isn't quite the same as the repo | 02:53 |
| lifeless | its output during the build, as opposed to whats used to build packages | 02:53 |
| lifeless | if you want to build a new package, you want to use apt-get source or debcheckout | 02:54 |
| lifeless | $ dpkg -S debcheckout | 02:54 |
| lifeless | devscripts: /usr/bin/debcheckout | 02:54 |
| Darxus | Or make-kpkg... | 02:54 |
| MTecknology | 4 days until freeze - anything important left to finish off? | 02:56 |
| MTecknology | 2.5 min left to pull it :P | 02:57 |
| MTecknology | "These are 'Null' algorithms, used by IPsec, which do nothing." ... what's the point of this? | 03:04 |
| MTecknology | CONFIG_CRYPTO_NULL | 03:05 |
| hzhang__ | ericm_, if so, <ericm> phenompanda, test build has no prob with latest kernel - EABI without OABI_COMPAT | 03:05 |
| lifeless | testing | 03:05 |
| hzhang__ | ericm_, what's the difference between those two binaries? | 03:05 |
| hzhang__ | ericm_, like size vmlinux, how much data section and bss section squeezed ? | 03:05 |
| MTecknology | wow.. you guys pack a whole lot into the kernel | 03:16 |
| jk-_ | MTecknology: testing, i'd say | 03:18 |
| === jk-_ is now known as jk- | ||
| MTecknology | jk-: I think there's always a lot in there - just part of having a distro that "just works" | 03:23 |
| * MTecknology loves "make all modules_install install" | 03:25 | |
| Darxus | I'm wondering how much benefit there would be to a program that figured out what hardware you have and recompiles a custom kernel for you. | 03:26 |
| Darxus | Something that "just works". | 03:26 |
| MTecknology | Darxus: not a bad idea but that would be hard considering some people will install ntfs-3g only the second they need it | 03:29 |
| MTecknology | ar similar | 03:29 |
| ericm_ | hzhang__, haven't compared yet - wait moment | 03:30 |
| MTecknology | Is there any reason for this setting? drivers/block/cciss.c:3153: warning: the frame size of 1056 bytes is larger than 1024 bytes | 03:32 |
| ericm_ | hzhang__, ok will check once compilation is done here | 03:33 |
| ericm_ | text data bss dec hexfilename | 03:39 |
| ericm_ | 3211565 250208 1123363574109 36895dvmlinux.with_oabi_compat | 03:39 |
| ericm_ | text data bss dec hexfilename | 03:39 |
| ericm_ | 3204537 250112 1123363566985 366d89vmlinux.no_oabi_compat | 03:39 |
| ericm_ | withou oabi_compat, code size seems to shrink a bit, but not data section, is this what you expected? | 03:39 |
| hzhang__ | ericm_, well, not a very good news, but also worthy to give a try ... | 03:43 |
| hzhang__ | ericm_, 7KB text section and 80Bytes data ... | 03:44 |
| hzhang__ | ericm_, thanks, anyway :) | 03:44 |
| ericm_ | MTecknology, for testing - most drivers are built-in instead of being module - so comes the size | 03:50 |
| MTecknology | ericm_: compiling the default kernel less some stuff takes a long time :P | 03:52 |
| MTecknology | I didn't realize how much is needed for a kernel that will "just work" for everyone | 03:52 |
| ericm_ | hzhang__, yes - I guess that's significant for your environment ;-) | 04:12 |
| hzhang__ | ericm_, well, once you try this "nm --size -r vmlinux | head -10" for search for big symbols | 04:14 |
| hzhang__ | ericm_, you will always get a 8K bytes symbol in data section - "init_thread_union" | 04:14 |
| ericm_ | MTecknology, I see - thanks | 04:15 |
| hzhang__ | ericm_, 8K, is that a must? seems others are quite tiny, no more than 4KB | 04:18 |
| === ericm_ is now known as ericm-afk | ||
| MTecknology | How do I update grub2 to use the newly installed kernel? | 04:31 |
| ericm-afk | MTecknology, /boot/grub/grub.cfg? | 04:46 |
| === ericm-afk is now known as ericm_ | ||
| MTecknology | ericm_: I didn't know if update-grub would do it or not | 04:58 |
| ericm_ | MTecknology, supposed so - I haven't done a kernel upgrade yet | 04:59 |
| ericm_ | MTecknology, are you installing a kernel package or something you built yourself? | 05:00 |
| MTecknology | I built one | 05:00 |
| MTecknology | ericm_: looks like update-grub does work | 05:05 |
| ericm_ | MTecknology, cool | 05:05 |
| * ericm_ will be back in a while | 05:06 | |
| === ericm_ is now known as ericm-lunch | ||
| === ericm-lunch is now known as ericm_ | ||
| === ericm_ is now known as ericm-afk | ||
| === ericm-afk is now known as ericm_ | ||
| === Whoopie_ is now known as Whoopie | ||
| Keybuk | so here's a fun one, after a few hours this machine slows down to an absolute crawl | 11:26 |
| * Keybuk wonders how the hell he'd go about debugging that | 11:26 | |
| amitk | Keybuk: nothing showing up in iotop or latencytop? | 11:34 |
| Keybuk | no, that's the curious thing | 11:34 |
| Keybuk | I'll check again next time it does it | 11:34 |
| apw | Keybuk, perhaps a memory leak, take a snapshot of slabinfo when you are working and compare to when you are broken | 12:18 |
| Keybuk | it's gone slow now | 12:18 |
| Keybuk | so what should I look for? | 12:18 |
| Keybuk | latencytop says | 12:21 |
| Keybuk | Scheduler: waiting for cpu 107.7 msec 100.0 % | 12:21 |
| Keybuk | unusable now - so shall reboot | 12:23 |
| Keybuk | then compare | 12:23 |
| Keybuk_ | I was going to do the "at least Linux boots fast" joke | 12:31 |
| Keybuk_ | but it didn't boot at all! | 12:31 |
| Keybuk_ | "VFS: unable to mount root" PANIC | 12:32 |
| === Keybuk_ is now known as Keybuk | ||
| Keybuk | apw: the biggest difference in slabinfo during slowness and after reboot is in buffer_head | 12:37 |
| Keybuk | now: | 12:37 |
| Keybuk | buffer_head 17048 17064 112 36 1 : tunables 0 0 0 : slabdata 474 474 0 | 12:37 |
| Keybuk | while slow: | 12:37 |
| Keybuk | buffer_head 143563 143568 112 36 1 : tunables 0 0 0 : slabdata 3988 3988 0 | 12:37 |
| apw | whats head -1 of that say | 12:37 |
| Keybuk | slabinfo - version: 2.1 | 12:38 |
| Keybuk | ? | 12:38 |
| Keybuk | or did you mean | 12:38 |
| Keybuk | # name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> | 12:38 |
| apw | yea | 12:38 |
| apw | that doesn't sound like an earth ending amount | 12:38 |
| apw | hrm | 12:38 |
| Keybuk | indeed | 12:38 |
| jk- | you can end the earth with the slab allocator? cool. | 12:39 |
| apw | oh yeah :) | 12:39 |
| Keybuk | apw: nothing really revealing in iotop or latency top either | 12:46 |
| Keybuk | I wonder whether it's this dodgy "you want hardware? I get you hardware!" SSD | 12:46 |
| apw | does it recover on a reboot? | 12:47 |
| apw | i'd expect ssd effects to be more ongoing | 12:47 |
| Keybuk | no, that's what's making me think | 12:47 |
| Keybuk | it only recovered after a physical power off and on again | 12:48 |
| apw | hrm | 12:48 |
| Keybuk | next time it does that, I'll see whether just the reboot makes it recover or not | 12:48 |
| Keybuk | it was a bit hard to this time due to the empty initramfs issue | 12:48 |
| apw | we have an empty initramfs? | 12:49 |
| Keybuk | yes, seen it a couple of times now | 12:49 |
| Keybuk | initramfs update gets borked | 12:49 |
| * apw struggles to understand why installing one kernel now means we rebuild the grub config 2x | 12:52 | |
| apw | especially now its as slow as nose-juice | 12:52 |
| apw | Keybuk, that reminds me, dispite usplash being back there is a fair gap between the end of usplash and x starting, is that expected? | 12:53 |
| Keybuk | I guess | 12:54 |
| Keybuk | X takes a second or two to start | 12:54 |
| apw | as we're not changing mode i am supprised usplash can't persist till X zaps the display | 12:58 |
| apw | for KMS setups | 12:58 |
| apw | iisn't that what plymouth does, just exits leaving the display message, and asks X to leave it alone? | 13:01 |
| Keybuk | basically yes | 13:02 |
| Keybuk | but we've never figured that patch out | 13:02 |
| Keybuk | and it may be that usplash's svgalibness prevents it | 13:02 |
| Keybuk | much as it pains me to suggest it, we may have to do plymouth and forgo nvidia-glx users wrath | 13:02 |
| Lure | can somebody review request to cherry-pick from linus (if new kernel is planned): bug 392017 | 14:30 |
| ubot3` | Malone bug 392017 in xserver-xorg-video-intel "kms and nonkms use different display names. HDMI-1 vs DVI1" [Unknown,Fix released] https://launchpad.net/bugs/392017 | 14:30 |
| apw | rtg i am looking at an issue with slow mount on usb disks, and it feels like readahead simply doesn't work ... seen anything like that? | 14:34 |
| rtg | apw, mounting a rootfs on a USB disk? | 14:35 |
| apw | this is simply mounting a vfat filesystem, it does a scan of the fat to work out free blocks cause 'the other' doesn't keep the superblock stats up to date | 14:36 |
| apw | from what i can see its submitting read ahead but not getting any benefit at all | 14:36 |
| apw | performance wise | 14:36 |
| apw | and wondering if it rang a bell | 14:36 |
| rtg | apw, do you think the I/O scheduler setting has anything to do with it? | 14:37 |
| apw | seems the same with cfq and with deadline | 14:37 |
| rtg | then no, I've not encountered it | 14:37 |
| jjohansen | apw: is it usb hd or a usb flash? | 14:37 |
| apw | its a rotating disk in this case | 14:38 |
| jjohansen | apw: could it be because it is fat, and has to read in the fat table | 14:39 |
| jjohansen | s/table/tables/ | 14:39 |
| apw | yep its defiantly fat and the fat table thats the issue | 14:39 |
| apw | but ... they added readahead support for it for this very operation | 14:39 |
| apw | and it seems to be triggereing, but the performance simply sucks, like its not there | 14:40 |
| rtg | apw, I mounted as fairly large ext3 USB disk just yesterday with no noticeable delays | 14:40 |
| apw | rtg, non-fat are not affected, this is a specific fat pattern triggered issue | 14:41 |
| rtg | apw, the moral of the story is, don't use FAT. | 14:41 |
| apw | it used to work, now it doesn't ... something broke | 14:41 |
| apw | from the evidence i have to hand it implies readahead is not working | 14:42 |
| apw | which would impact everything and everyone | 14:42 |
| rtg | apw, oh, that seems a bit more serious | 14:42 |
| apw | if i am reading this right its taking 1min40 to read 7mb | 14:43 |
| apw | 76mb in 1:40 ... still unreasonable even for a harddrive | 14:45 |
| jjohansen | apw: yikes that is bad | 14:46 |
| apw | yeah not even sure why it would be that bad even without read ahead, as its doing linear reads anyhow | 14:46 |
| jjohansen | apw: if it is close to the same with and without read ahead, and the figure is that bad I would think it is something else that is broken | 14:47 |
| smb | apw, If everything is linear the device cache should have a performance boost. The question is whether bios are correctly merged into larger requests or whether small ones get sent down | 14:48 |
| apw | well without readahead they are syncronous 512 byte sector reads | 14:49 |
| apw | with it in theiry they should be dumped in in 256 sector chunks | 14:49 |
| smb | wasn't device read ahead 128 sectors? | 14:51 |
| apw | this is being done explicitly in the fs | 14:51 |
| smb | hm, there is another setting defined in the device queue | 14:52 |
| smb | in /sys/block/sd?/queue/read_ahead_kb (ok, it actually 128 kb) | 14:52 |
| apw | yep, but this is explicit, so even if the one you mention there is not working this one is definatly occuring | 14:57 |
| smb | right, if the fs does this too, this should generate requests of that size at least. | 14:59 |
| smb | Actually there has been another thing (maybe on the vfs layer) which would adapt on the amount of sequential hits... | 15:00 |
| === ericm_ is now known as ericm-Zzz | ||
| Lure | rtg: thanks for takin care of bug 392017 | 16:37 |
| ubot3` | Malone bug 392017 in linux "kms and nonkms use different display names. HDMI-1 vs DVI1" [Low,Fix committed] https://launchpad.net/bugs/392017 | 16:37 |
| rtg | np | 16:37 |
| rtg | smb, apw: you guys never answered my question about CONFIG_X86_PAT | 16:41 |
| smb | rtg, no not really. And I got no idea why it was/is unset | 16:41 |
| rtg | smb, what harm do you foresee if its enabled? | 16:42 |
| * apw is supprised to find it is off | 16:42 | |
| smb | I cannot claim complete understanding but as it is the default there should not be much harm | 16:43 |
| rtg | which is why I'm pushing the issue. | 16:43 |
| rtg | ok, I'm gonna turn it on for Beta | 16:44 |
| cking | it's been around for quite a while - anyone seen any other distros with kitten killer X86_PAT bugs? | 16:44 |
| rtg | cking, yeah, I'm a bit boggled that we don't have it enabled. | 16:45 |
| cking | and there's a nopat kernel boot option isn't there if it causes an issue with broken H/W | 16:45 |
| rtg | yep | 16:46 |
| apw | rtg beta, didn't we aleady ship beta? | 16:46 |
| rtg | apw, uh, you know, the next kernel whatever it is. | 16:46 |
| apw | heh :) | 16:46 |
| cking | hehe - there are SuSe discussions on why Ubuntu left it out w.r.t. the e1000e bug way back | 16:48 |
| * cking wonders if the citysprint emailer is actually not human - in which case, I may have failed the turning test | 16:50 | |
| cking | s/turning/Turing/ | 16:50 |
| rtg | cking, you couldn't 'turn' on a dime? | 16:50 |
| rtg | jjohansen, you gonna put the full court press on the ec2 i386 regression? | 17:06 |
| jjohansen | rtg: yep | 17:06 |
| rtg | jjohansen, thanks. | 17:07 |
| jjohansen | right now I am doing clean rebuilds of and akis of everything | 17:07 |
| rtg | jjohansen, you should rewind a re-do the rebase yourself. IIRC I had a conflict that I solved, but perhaps I flubbed it. | 17:08 |
| jjohansen | rtg: will do, just want to double check with a second build, it is easy too easy to mess something little up | 17:09 |
| pgraner | cking: sorry, didn't realize we were in the DT channel | 17:52 |
| cking | pgraner, why upgrade the BIOS - the version on that PV is the same as the one on my one which runs Karmic OK | 17:53 |
| pgraner | cking: Didn't know, I usually try and keep boxes up to the latest | 17:53 |
| cking | living life on the bleeding edge again.. | 17:53 |
| cking | pgraner, I kinda helped them iron out all the Linux-centric BIOS issues, so it should be OK | 17:54 |
| cking | ..but if you like pain, I'm not stopping you upgrading ;-) | 17:55 |
| pgraner | cking: nope I"m good, I just assumed that the one on the box was old and could use a bump | 17:55 |
| cking | pgraner, I kept 4 of these boxes upto date, so they are good IMHO | 17:56 |
| pgraner | cking: cool | 17:56 |
| Darxus | I had /window 15 | 18:03 |
| Darxus | Oops. | 18:03 |
| lamont | where did my broadcom-working state go ? | 18:10 |
| lamont | meh... is network mangler, not kernel | 18:11 |
| rtg | lamont: this is a binary blob driver, right? | 18:11 |
| lamont | rtg: it's a perfectly functional driver.... network mangler just failed to bring it up | 18:13 |
| lamont | ifconfig and it's happy | 18:13 |
| * rtg thinks binary blob and perfectly functional is an oxymoron | 18:14 | |
| lamont | well, functional is totally separate from _SUPPORTABLE_ :( | 18:18 |
| UnitesSta | New facebook! Win 1 of 5000 IPODS NANO 5G! http://vk.com/reg3329057 | 20:53 |
| UnitesSta | New facebook! Win 1 of 5000 IPODS NANO 5G! http://vk.com/reg3329057 | 21:01 |
| Whoopie | rtg: Hi, did you think about enabling CONFIG_PCIEASPM? It saves some power on laptops. | 21:28 |
| rtg | Whoopie, its still marked experimental. | 21:30 |
| Whoopie | rtg: what about enabling the CONFIG_, but disabling by default so that the user can enable it via sysfs? | 21:31 |
| MTecknology | So... I downloaded the kernel source, used the same config that's in /boot, compiled and installed using "make all modules_install install", and booted to it but it died on boot complaining about not being able to remove /forcefsck on read-only file system | 21:36 |
| MTecknology | I didn't make any modifications to the kernel.. | 21:36 |
| Whoopie | rtg: it's enabled in config.flavour.powerpc-smp | 21:44 |
| rtg | Whoopie, send an email to the k-t list and I'll consider it later. | 21:44 |
| Whoopie | ok, thanks | 21:45 |
| rtg | MTecknology, I has something similar happen to me on a fresh install today. what is your clock setting? | 21:45 |
| MTecknology | rtg: how do I check that? | 21:46 |
| rtg | MTecknology, from your BIOS during boot. it must be ahead of the file system | 21:46 |
| MTecknology | I'll check once I finish an update | 21:46 |
| MTecknology | what does that change? | 21:47 |
| rtg | MTecknology, make sure your clock is set to the current time (less your UTC offset). | 21:47 |
| MTecknology | You mean set the clock to UTC? | 21:48 |
| MTecknology | or the local time | 21:48 |
| rtg | MTecknology, yep | 21:48 |
| MTecknology | ok | 21:48 |
| MTecknology | ntpdate won't update the bios clock, will it? | 21:49 |
| MTecknology | 12 Oct 15:49:25 ntpdate[8258]: adjust time server 91.189.94.4 offset -0.018734 sec | 21:49 |
| rtg | MTecknology, it won't if the clock is too far out of date | 21:50 |
| MTecknology | I'll stop doing an update and try it | 21:51 |
| === bjf-afk is now known as bjf | ||
| SyL | is this a place I can ask for help on kernel panics on ubuntu 9.10? | 21:54 |
| MTecknology | rtg: it was spot on | 21:55 |
| rtg | MTecknology, you mean your BIOS clack was correct? | 21:55 |
| rtg | clock* | 21:55 |
| MTecknology | ya | 21:56 |
| rtg | MTecknology, hmm, I think Keybuk has been futzing about with some fsck type stuff. | 21:56 |
| MTecknology | Keybuk: ...... -_- | 21:57 |
| MTecknology | rtg: it's not because of the way I built it then? | 21:57 |
| MTecknology | I built it the same way I learned how in gentoo | 21:57 |
| rtg | MTecknology, does the original kernel do it? | 21:57 |
| MTecknology | no | 21:57 |
| rtg | what version is your original kernel? | 21:58 |
| rtg | cat /proc/version | 21:58 |
| MTecknology | 2.6.31-13-generic | 21:58 |
| Keybuk | MTecknology: yes? | 21:58 |
| MTecknology | Keybuk: rtg said it might be you breaking things | 21:58 |
| Keybuk | MTecknology: what's up? | 21:59 |
| MTecknology | rtg: Linux version 2.6.31-13-generic (buildd@yellow) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu7) ) #44-Ubuntu SMP Sat Oct 10 15:27:14 UTC 2009 | 21:59 |
| rtg | Keybuk, we've both noticed some issues with fsck failing to run on first boot is the bios clock is behind the file system | 21:59 |
| Keybuk | failing to complete you mean? | 21:59 |
| rtg | Keybuk, no, won't even start. drops me to a shell | 21:59 |
| Keybuk | wah! unexpected inconsistency! sky is falling! etc. | 21:59 |
| Keybuk | right | 21:59 |
| rtg | known issue ? | 22:00 |
| Keybuk | yes, it's your fault | 22:00 |
| rtg | oh, I like that. | 22:00 |
| Keybuk | :D | 22:00 |
| Keybuk | tell me a bit about your setup? | 22:00 |
| Keybuk | installing into virtualbox? | 22:00 |
| rtg | no, bare metal. | 22:00 |
| MTecknology | same here | 22:00 |
| Keybuk | machine previously had Windows on it? | 22:01 |
| MTecknology | this had windows on it until I got home 2yr ago | 22:01 |
| rtg | no, it had Hardy. I was installing Karmic from scratch. | 22:01 |
| Keybuk | rtg: what did it have before Hardy? | 22:01 |
| rtg | dunno, I got it from Intel. its an SDP | 22:01 |
| rtg | the clock was 2 years behind. | 22:02 |
| Keybuk | what was the UTC setting on Hardy? | 22:02 |
| Keybuk | and, most importantly, what did the clock in the top-right say while you were installing? | 22:02 |
| Keybuk | two years?! :p | 22:02 |
| Keybuk | behind isn't usually an issue | 22:02 |
| rtg | Keybuk, I never noticed that it was so far behind until fsck wouldn't run. | 22:02 |
| MTecknology | Keybuk: i bought the system, got home, installed ubuntu - it came w/ vista | 22:03 |
| Keybuk | MTecknology: you wiped Vista? | 22:03 |
| MTecknology | the timeon this system was less than 1/10 second off | 22:03 |
| MTecknology | ya | 22:03 |
| MTecknology | i don't like raping computers | 22:03 |
| Keybuk | MTecknology: ok, so your bug is pretty simple | 22:03 |
| Keybuk | when you installed Ubuntu, you didn't notice that the clock in the top-right was actually N hours fast | 22:03 |
| Keybuk | (where N is the timezone offset between you and UTC) | 22:03 |
| MTecknology | I installed from the alternate cd | 22:04 |
| Keybuk | so you rebooted, and the "last mount" time of your filesystem was then in the future | 22:04 |
| Keybuk | you connected to a network (hi!) | 22:04 |
| MTecknology | my issue is.... | 22:04 |
| Keybuk | and that resync'd your clock back to reality | 22:04 |
| Keybuk | and saved that time back into your hardware clock | 22:04 |
| Keybuk | then next time you rebooted, fsck failed because the last mount time was in the future | 22:04 |
| Keybuk | and dumped you to the world's least helpful shell | 22:04 |
| Keybuk | if you ran fsck -y like it DID NOT SAY then everything was fine | 22:05 |
| Keybuk | and now it won't happen again | 22:05 |
| Keybuk | the reason this happened is because Windows had the hardware clock in "local time" | 22:05 |
| Keybuk | but every other OS in the universe, including Ubuntu, puts UTC in the hardware clock | 22:05 |
| Keybuk | because anything else is INSANE | 22:06 |
| rtg | it would be helpful if ntpdate would correct for more then 3600 seconds (at least during install) | 22:06 |
| Keybuk | since you wiped Vista, the clever bit of the installer that checks for Windows and adjusts the configuration to use local time didn't see it | 22:06 |
| MTecknology | I pulled the kernel source, grabbed the config from /boot, compiled the kernel with that exact same config and installed using "make all modules_install install", When I tried to boot to the kernel I just compiled it hung on saying can not remove /forcefsck on read-only file system. | 22:06 |
| Keybuk | rtg: I believe that ntpdate will correct any amount of jump | 22:06 |
| MTecknology | I can't boot beyond that | 22:06 |
| Keybuk | MTecknology: what else is on screen? | 22:06 |
| MTecknology | i can't remember but I don't really know how to take a screenshot of that either. | 22:07 |
| Keybuk | MTecknology: a camera phone is ideal ;) | 22:07 |
| Keybuk | the forcefsck thing is an error caused by a previous error, the previous error is really important | 22:07 |
| MTecknology | not that phone - won't be able to read it | 22:07 |
| Keybuk | but I reckon you have the "I didn't make an initramfs for my custom kernel" bug | 22:07 |
| MTecknology | oh | 22:08 |
| rtg | fsck -y corrects the original problem? | 22:08 |
| MTecknology | probably.. | 22:08 |
| Keybuk | rtg: I patched e2fsck today to always repair a future last mount/write/check time as long as it's no more than 24hr in the future | 22:09 |
| MTecknology | Keybuk: i didn't do that - so you're probably right.. | 22:09 |
| Keybuk | I'm sure Ted will ignore that as long as possible, but the RH e2fsck maintainer has already said they want that patch | 22:09 |
| rtg | Keybuk, 24 hours being the normal Windoze correction factor? | 22:09 |
| Keybuk | MTecknology: I already have a fix for that, can you install packages on that box? | 22:09 |
| Keybuk | rtg: 24 hours being the most a clock can be out due to timezone error ;) | 22:10 |
| MTecknology | i hope I can.. | 22:10 |
| rtg | Keybuk, right | 22:10 |
| MTecknology | Keybuk: I only have one system | 22:10 |
| Keybuk | MTecknology: and you're testing development releases on it? :) Brave man | 22:11 |
| Keybuk | even I don't do that <g> | 22:11 |
| MTecknology | I learned gentoo on this thing over a weekend :P | 22:11 |
| lifeless | Keybuk: 26 hours I think | 22:11 |
| MTecknology | I ran 9.10 on this thing back around 9.05 | 22:11 |
| lifeless | Keybuk: there is some weird corner case overlap - the world is > 24 hours around :) | 22:11 |
| Keybuk | lifeless: no, this is only relative to UTC remember | 22:12 |
| Keybuk | so it's actually +/- 13.5 hours or something | 22:12 |
| Keybuk | but 24 is easier to remember the number of seconds for <g> | 22:12 |
| lifeless | Keybuk: right, -13 to +13 == 26 ;) | 22:12 |
| MTecknology | Keybuk: so - how do I get that fix? | 22:12 |
| MTecknology | 13? | 22:12 |
| Keybuk | MTecknology: it will take the buildds a few minutes | 22:13 |
| Keybuk | MTecknology: daylight savings in sheepland | 22:13 |
| Keybuk | type thing | 22:13 |
| MTecknology | i'm confused! | 22:13 |
| MTecknology | oh | 22:13 |
| MTecknology | i hate dst... | 22:13 |
| lifeless | MTecknology: +12 + DST | 22:13 |
| MTecknology | Is this part really needed? "apt-get build-dep linux-ubuntu-modules-$(uname -r)" | 22:14 |
| lifeless | ah | 22:14 |
| lifeless | tonga is +13 | 22:14 |
| MTecknology | most things in there shouldn't be needed to build the kernel.. | 22:14 |
| lifeless | without needing DST | 22:14 |
| * rtg is outta here for the day | 22:14 | |
| lifeless | and the line islands at +14 | 22:15 |
| lifeless | http://en.wikipedia.org/wiki/Time_zone | 22:15 |
| lifeless | -11 to +14 is the largest gap w/out DST considerations | 22:15 |
| MTecknology | ah.. I see - that's the "ubuntu way" to compile the kernel | 22:16 |
| MTecknology | Is there anything wrong with using linux-source? | 22:17 |
| MTecknology | Keybuk: will I still need your patch for that? | 22:17 |
| Keybuk | linux-source is the kernel source | 22:17 |
| Keybuk | I think everyone builds from GIT though | 22:17 |
| Keybuk | MTecknology: are you on i386 or amd64? | 22:17 |
| MTecknology | amd64 | 22:18 |
| lifeless | linux-source is fine for rolling a custom kernel; if you're working on the kernel packages for ubuntu, you need the kernel package source | 22:18 |
| MTecknology | so if I'm just going to roll out my own - then use git to get the kernel source - otherwise use the ubuntu kernel package? | 22:20 |
| Keybuk | oh, it failed to build | 22:21 |
| Keybuk | lifeless: that is the kernel package source ;) | 22:21 |
| Keybuk | MTecknology: I may need a few more minutes at this ;) | 22:22 |
| MTecknology | Keybuk: ok - can you explain the parts that matter to me? | 22:23 |
| Keybuk | MTecknology: is the machine on a wired network interface? | 22:23 |
| MTecknology | wireless | 22:23 |
| Keybuk | can you plug it into a wire? | 22:23 |
| Keybuk | if not, does your wireless use WPA? | 22:24 |
| MTecknology | ya | 22:24 |
| Keybuk | or can you boot the kernel that you didn't make? | 22:24 |
| MTecknology | I'm in that | 22:24 |
| Keybuk | ah great | 22:24 |
| MTecknology | the kernel I made won't boot and I just wiped it | 22:24 |
| MTecknology | I'm just trying to trim down the extra junk in the kernel that I don't need | 22:25 |
| MTecknology | like XFS support - I don't need it and this laptop never will | 22:26 |
| Keybuk | ahh | 22:27 |
| Keybuk | you know that we don't build in XFS support, right? :) | 22:27 |
| Darxus | Hah. | 22:27 |
| MTecknology | it was in there.. | 22:28 |
| MTecknology | in the config in /boot | 22:28 |
| MTecknology | CONFIG_XFS_FS=m | 22:28 |
| Keybuk | that means it's a module | 22:28 |
| MTecknology | build in as a module | 22:28 |
| Darxus | MTecknology: There is something very important here you don't understand. | 22:29 |
| MTecknology | I did say like though - there's a lot I'd like to knock out - I want to try to get a 10sec boot on this system | 22:29 |
| MTecknology | Darxus: what's that? | 22:29 |
| Darxus | MTecknology: Stuff built as a module that you don't use never gets loaded. So changing it from a module to not being compiled at all gains you nothing (except compile time)., | 22:29 |
| MTecknology | i get that | 22:30 |
| MTecknology | when I'm looking at menuconfig again I can pick out some other things | 22:30 |
| MTecknology | I'm not saying that I think the ubuntu kernel is wrong - I'm just a glutton for punishment - and breaking things is fun | 22:31 |
| MTecknology | but when I use the exact same config to compile it and it breaks - I get confused | 22:31 |
| Darxus | Ah, well, are you using the source package that builds the linux-image packages, or the linux-source package? | 22:33 |
| MTecknology | linux-image | 22:34 |
| Darxus | Hmm, weird. | 22:34 |
| MTecknology | I'm pulling the git source now | 22:34 |
| MTecknology | does that have a default .config in it? | 22:35 |
| Darxus | MTecknology: Yes, in pieces. | 22:35 |
| MTecknology | that last part makes me want to ask for additional information | 22:35 |
| Darxus | cat debian.master/config/config.common.ubuntu debian.master/config/i386/config.common.i386 debian.master/config/i386/config.flavour.generic > .config | 22:35 |
| Darxus | That'll get you an i386 generic .config. | 22:36 |
| MTecknology | interesting.. | 22:36 |
| Darxus | You're likely to be able to extrapolate the other possibilites. | 22:36 |
| MTecknology | you mean like debian.master/config/i386/config.common.i386.iwant.amd64.instead ?? | 22:37 |
| MTecknology | :P | 22:37 |
| Darxus | Ha. | 22:37 |
| Darxus | find . -name "*config*" will show you your options. | 22:37 |
| MTecknology | Receiving objects: 2% (33347/1335407), 9.20 MiB | 59 KiB/s | 22:38 |
| MTecknology | this is going to take a while | 22:38 |
| Darxus | Heh. | 22:38 |
| Darxus | Have you run the thing to pick an optimal mirror? | 22:39 |
| MTecknology | nope | 22:39 |
| MTecknology | what's that? | 22:39 |
| Darxus | I recommend it. | 22:39 |
| Keybuk | I didn't think we have mirrors of our kernel source | 22:39 |
| MTecknology | should I do this as a normal user and make a copy of the source to work on? | 22:39 |
| Darxus | In one of the ubuntu gui package management things, theres a place where you can specify your mirror, and there's an option to select "other" or something, and then "select optimal mirror" and it pings them all or something. | 22:40 |
| MTecknology | Darxus: I'm pulling from git though | 22:40 |
| Darxus | Keybuk: Why wouldn't the kernel be included in the mirrors.... ohh, get, nevermind. | 22:40 |
| MTecknology | my university just throttles to 60K | 22:40 |
| Darxus | er, git | 22:40 |
| Darxus | Ew. | 22:40 |
| Keybuk | MTecknology: https://edge.launchpad.net/~ubuntu-boot/+archive/ppa/+build/1289150/+files/mountall_0.2.2~boot2_amd64.deb | 22:40 |
| MTecknology | should I do this as a normal user and make a copy of the source to work on? | 22:40 |
| Keybuk | if you install that, hopefully you could boot custom kernels ;) | 22:41 |
| MTecknology | or will I be making my .config in the krepo | 22:41 |
| MTecknology | Keybuk: how long until that makes it into karmic? | 22:41 |
| MTecknology | and it's installed :) | 22:42 |
| Keybuk | MTecknology: depends how long it takes me to watch the rest of FlashForward without interruptions | 22:43 |
| Keybuk | and apply a couple more bug fixes after that <g> | 22:43 |
| MTecknology | oh | 22:43 |
| MTecknology | hm... sounds like it makes more sense to make a copy of the part of the git branch that I want instead of working inside it | 22:44 |
| Womble2 | Which package is the aufs2 source in? | 23:02 |
| jjohansen | Womble2: its under the ubuntu dir in the kernel tree | 23:03 |
| Womble2 | OK | 23:03 |
| otay | I want to connect two qemu quests via serial connection so I can do some debugging. Does anybody have any idea how to do this? | 23:07 |
| MTecknology | Keybuk: do I want to do "git checkout Ubuntu-2.6.31-13.44" ? | 23:14 |
| MTecknology | How long does it take you guys to compile the ubuntu stock kernel> | 23:27 |
| mase_wk | MTecknology: that depends entirely on the machine you use to do it | 23:46 |
| MTecknology | mase_wk: ya - I was just curious | 23:46 |
| MTecknology | what kind of system do you have and how long does it take? | 23:46 |
| MTecknology | I should use concurrency next time | 23:48 |
| mase_wk | i have an AMD Athlon(tm) 64 Processor 3000+ , i usually compile under a clean VM environment though so it takes about 1/2 a day | 23:48 |
| MTecknology | to compile the ubuntu kernel? | 23:48 |
| mase_wk | well last time it was a kernel.org kernel | 23:49 |
| MTecknology | Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz | 23:49 |
| MTecknology | only seems to take a couple hours for me | 23:49 |
| mase_wk | well i am doing mine on a VM too | 23:50 |
| mase_wk | virtualbox at that so its not something speedy like xen | 23:50 |
| mase_wk | if you want to speed up your time you can disable many of the modules that you don't need | 23:51 |
| mase_wk | if you are never going to have a SAN then you can remove all of the drivers / files systems associated with that etc.. | 23:51 |
| MTecknology | that's part of the reason I'm doing this :P | 23:53 |
| mase_wk | your compiling a kernel because you want to reduce your compile time ? | 23:54 |
| mase_wk | =) | 23:54 |
| MTecknology | no - because I want to trim it down | 23:54 |
| MTecknology | loading the kernel is ~75% of my boot time | 23:55 |
| mase_wk | i doubt that | 23:55 |
| mase_wk | how big is your kernel ? | 23:55 |
| MTecknology | default | 23:55 |
| MTecknology | right now I have yet to actually compile a kernel that works | 23:55 |
| MTecknology | in ubuntu anyway | 23:55 |
| mase_wk | mine is 3.8mb | 23:56 |
| mase_wk | if you have trouble loading 3.8mb at boot you have other issues | 23:56 |
| MTecknology | 7.3Minitrd.img-2.6.31-13-generic | 23:56 |
| mase_wk | thats not the kernel | 23:56 |
| mase_wk | thats the initrd | 23:56 |
| mase_wk | you don't have to remake the kernel to remake the initrd | 23:57 |
| MTecknology | ** 3.8Mvmlinuz-2.6.31-13-generic | 23:57 |
| mase_wk | you can just remove modules from the initrd | 23:57 |
| MTecknology | how do I do that? | 23:58 |
| mase_wk | mkinitrd | 23:58 |
| mase_wk | you can specify which modules you want to include | 23:58 |
| MTecknology | thanks | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!