[08:24] Booting intrepid-proposed's kernel, I get the boot hanging at: udevd-event[2606]: run_program: '/sbin/modprobe' abnormal exit [08:25] Can anyone point me at any relevant debugging options that might help deterimine why? [08:25] thanks [08:32] you can boot the kernel with "debug" parameter.That will provide you with more info.You can use grub to add parameter to the kernel command line [08:35] I wonder whether changing udev debugging level in the conf and recreating the initrd for the new kernel from an older one also brings more ingo. Sounds like some module could not get loaded and after it hangs maybe an important one. Also removing quiet from the grub line might be a good idea [08:38] smb_tp: sounds good, /etc/udev/udev.conf, udev_log="debug" ? [08:40] maxb, That can give a lot of output. If that is too much maybe "info". Maybe going from the kernel options via info to debug... [08:40] On an unrelated note, having tagged an lbm bug regression-proposed, is there anything else I should be doing also? [08:41] Can you quickly point to it? Then I have a look [08:42] bug 337929 [08:42] Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Undecided,New] https://launchpad.net/bugs/337929 [08:45] eek, yeah that's a lot of udev spew. /me tries info [08:46] maxb, The bug seems to be complete afaics. If there are questions we surely will ask [08:47] ok, just checking I wasn't supposed to report potential regressions in proposed anywhere special [08:49] Just in the sense of "we have to get this fixed before it moves to updates". It might pop up on certain screens to have a look at [08:50] oh, guh [08:50] my modprobe error was the ath5k BUG-ing :-) [08:51] eh, so likely related to the bug [08:57] smb_tp, thats odd ... i would expect ieeee80211_regdome to simply cause the module to fail to load ... we have a bug on that too [08:58] I would be thinking that if the module causes an oops, then strange things can happen to the modprobe as well... [08:58] modprobe may well hang for ever, and no more modprobes be possible [08:58] and that is what seems to happen [09:01] it sounds a lot like the kernel and lbm there are out of sync in terms of the config options for REGULATORY domain [09:02] the variable that those ieee80211_regdom= things point to is no longer there in our latest kernels [09:02] as we have CRDA enabled instead [09:02] It could be. Though for intrepid this should behave the old way (and certainly not oops) [09:03] yeah it should. but just check it not the same package [09:04] yeah. I thought both were updated to the same compat-wireless master ... [09:04] but i have to check [09:05] I see. Intrepid should be at 2009-03-04, Jaunty at 2009-03-17 [09:06] maxb, the dmesg on the bug is for Jaunty it seems. Could you add one for Intrepid as well? [09:09] sure [09:10] err [09:11] On intrepid the failure mode somehow manages to be different such that it doesn't end up in /var/log/ there :-/ [09:11] this may be a bit more difficult [09:14] here I go rebooting, let's try it again [10:12] amitk: your change is good [10:12] I think I asked Ben to do that years ago [10:12] but he bitched :p [10:12] it means I can eliminate a tiny bit of the udev init script as well [10:13] Keybuk: I tripped across it while going over the entire config for the babbage [10:13] Keybuk: though I don't this the actual impact is measurable [10:13] it's just nicer [10:13] s/this/the [10:14] yes [10:14] Keybuk: could you please ack it then? [10:14] amitk: I've replied with a Signed-off-by line of my own [10:14] thanks === Nicke_ is now known as Nicke [10:59] Any idea why CONFIG_RTC_DRV_CMOS is disabled for Hardy and enabled for Intrepid + Jaunty? It appears to been disabled in linux-source-2.6.22 (2.6.22-6.13) gutsy [11:04] ..perhaps I need a time machine to figure out the rationale behind the decision [11:13] smb_tp: ^^ wrt CONFIG_RTC_DRV_CMOS in Hardy? [11:21] cking, ok can you tell me what might trigger the grub error: Error 13: Invalid or unsupported executable format [11:21] have you moved from ext3 to ext4? [11:22] yes, but not recently [11:22] do i need to reinstall grub or something? [11:22] though i can boot an older kernel [11:23] When in the boot process is it occuring? Any other messages? [11:23] very first thing after it says its booting an image [11:23] as if the actual binary was corrupt [11:23] OK - sounds like the kernel image is corrupt [11:23] especially if you can boot older kernels [11:24] and yet the md5sum is the same on my boxes [11:24] and the other is booted from it [11:24] apw@chloe:/boot$ md5sum vmlinuz-2.6.28-11-generic [11:24] 6dfd6e870419d93a37c27341940316e7 vmlinuz-2.6.28-11-generic [11:24] apw@lana:/boot$ md5sum vmlinuz-2.6.28-11-generic [11:24] 6dfd6e870419d93a37c27341940316e7 vmlinuz-2.6.28-11-generic [11:24] apw@lana:/boot$ cat /proc/version [11:24] Linux version 2.6.28-11-generic (buildd@yellow) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #35-Ubuntu SMP Wed Mar 18 21:55:34 UTC 2009 [11:25] grub has a block map command that allows one to get a block map of the image. It may be worth checking grubs idea of the block map for this file compared to the reality [11:25] ok how do i get that in OS and grub [11:26] this is the fun bit. In Linux there is a ioctl() FIBMAP or something like that to get a block map of a file... hold on.. [11:27] I will Email you the source to my fibmap dumper tool [11:27] nice [11:29] cking, ohhh blocklist in grub is unhappy [11:30] Error 24: Attempt to access block outside partition! [11:30] owch [11:30] ext4? [11:30] yes sir [11:30] its even printing extents :) [11:30] i assume thats +8 means [11:31] This is good and bad. Good that we have somebody who can send me an image I can work on :-) bad that it's screwed [11:31] Can you dd up the boot partition so I can look at it? [11:33] its my entire disk :( [11:34] (hd0,0)1546320+8.32+8,4096+8,402255872+8,4096+8,2792+8,402280448+4 [11:34] that looks utterly corrupted to me [11:34] urgghh. [11:34] if its an extent list, it has the same extent twice doesn't it? [11:35] not sure [11:35] where's ted? [11:35] i think i'll boot a recovery cd and fsck it before i do anything else [11:35] apw, could it be it got a wrong kernel, like a 64bit on a 32bit machine or somethin? [11:35] don't think so, it should boot the kernel then and fail at userspace [11:35] I'd dd the image to backup then fsck it [11:35] cking, wrt to the config option: so it has been disabled before intrepid and enabled starting with it and later? [11:35] cking, no point in backing it up [11:36] its all recoverable from the other machine [11:36] Ah. fsck will be fast, that's for sure [11:36] its had early ext4 on it so it could be corrupt [11:36] smb_tp: it appears to be disabled pre-hardy and re-enabled post hardy. [11:36] from there, so its probabally not pejorative of the current kernel even if its broken [11:37] apw: I agree [11:37] apw, eek, should have read the whole backlog then [11:37] smb_tp, lemme see.. I had the change log somewhere... [11:37] yeah ext4 ate my /boot [11:37] missed the blocklist is unhappy [11:37] yeah its well sick [11:37] ted is hiding from us [11:37] ext4 as boot. You're living dangerously [11:38] heh, you promised me it was working :) [11:38] ..yeah, but I did not promise it was 100% reliable :-) [11:38] ..what's it on? [11:39] its an intel shv [11:39] shv? eh? [11:40] its a intel quad core thing [11:40] owch. [11:40] well it was, its a heap at the mo :) [11:40] and it went wrong on the reboot? [11:40] nice our rescue disk doen't have fsck on it [11:40] well ... it fails to boot from the new kernel [11:40] i suspect the upgrade broke it [11:40] as in doing the upgrade [11:42] apw, I think fdisk in the rescue disk might be a good proposal [11:43] smb_tp: hardy debian/changelog: linux-source-2.6.22 (2.6.22-6.13) gutsy; urgency=low ... build/config: Disable CONFIG_RTC_DRV_CMOS [11:43] nope not one of those either [11:43] this alternate disk is USELESS [11:43] ..remove disk and fsck on another box? [11:43] apw, would a live cd work? [11:44] trying now [11:45] cking, I have to look into that a bit. Reasons do not come to my mind immediatly [11:45] cking, i am a s/w engineeer [11:45] heh [11:45] i expect to be able to fix this from outside the box! [11:46] though i have screwdrivers on standby [11:46] surely using a screwdriver is software engineering? [11:46] heh, only h/w engineering when you need a hammer? [11:47] or solder [11:48] fsck says 'clean', is there a 'look do it properly' option? [11:48] -f [11:49] taking more time at leas [11:49] cking, so how is fsck fast in ext4? waht do they do different? [11:50] iirc they can mark regions they have not touched, so those can be skipped [11:50] apw: http://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/ [11:51] faster "due to the elimination of indirect blocks and the uninit_bg feature reducing the amount of disk reads necessary in e2fsck’s pass 1" [11:51] so now you know :-) [11:52] ok so its fsck'd ok [11:52] and thinking about it the md5sum of the file was fine too [11:52] fingers crossed [11:52] so i am suspect fo grub [11:53] How big was /boot? [11:53] ..oh yeah. the whole disk for / wasn't it? [11:55] yep massive [11:56] Can you run the fibmap prog and workout which blocks are used by the kernel image. Maybe we can dd up just some of this disk image to see why grub is bawking [11:56] 306M blocks [11:57] bit to big to fit on a DVD then :-( === mcasadevall is now known as NCommander [11:58] heh yeah [11:59] I will compare and contrast the grub 0.97 + ext4 support with grub 2 and see if anything make sense [12:01] apw: I wonder if one could create an USB bootable drive and install grub 2 on this and see if this can read the kernel off the hard disk. [12:02] ..me goes to try this [12:02] cking, i guess its possible, i'd have no idea how [12:02] cking, the blocklist from fibmap bears no relation to that from grub [12:02] i'd susgest its overflowwing [12:03] mmm.. could be. How about comparing older kernels to see if grub vs fibmap marry up just for a sanity check [12:05] the working kernel seems pretty similar in location [12:06] and no major weirdness in the fibmap wrt sequential blocks etc [12:06] it looks like its in two extents to me [12:06] assuming there is no limits on actual extents [12:06] amitk: I guess you noticed the ARM kernel didn't build? I think the Kconfig for drivers/cpufreq has problems, but it looks like you must build in the performance governor. [12:07] rtg: it doesn't like the cpufreq driver built as a module [12:08] amitk: right, I found that out last night, but when I quickly looked at your last push, I thought you had done the same [12:08] rtg: and regarding hitting your shitlist looks like you didn't get my last message [12:08] 21:34 < amitk> rtg: had to force push to jaunty. Found a typo in my patch (im51 -> imx51) [12:08] apw: can you send me the fibmap of a good kernel and the badone [12:08] rtg: so I deserved it :-/ [12:09] amitk: hmm, sure didn't. I get so many flashes from this IRC client some days that I miss things. [12:10] cking, sure ... [12:10] rtg: I've got the build issues fixed. Just testing with ogra regarding AA and aufs issues. Then I'll fix d-i for imx51 [12:11] amitk: ok [12:11] I'm looking at making a bootable USB image with grub2.. [12:15] cking, on its way [12:15] i blocklisted a good kernel and its two extents [12:15] apw, that's good. thanks [12:16] i can keep this pretty much indefinatly if its a help [12:20] cking, i note that grub is reporting block number *8 the fibmap [12:20] but they are pretty similar [12:20] 402243640 [12:20] 17F9C038 [12:20] 50281984*8 [12:20] 17F9F000 [12:20] first is the one which works [12:21] apw: one could inform grub of the block map (from the map from fibmap) by hand and see if this boots - http://www.gnu.org/software/grub/manual/grub.html#Block-list-syntax [12:22] hmmm [12:22] bit of a pain I know [12:31] hi, is there a karmic repo already? as you need new squashfs-tools from cvs [12:32] squashfs 4.0 from 2.6.29 is not compatible with old squashfs 3 [12:33] Kano, repo as in the full archive? [12:33] there is no karmic archive yet, and won't be till jaunty is released [12:34] cking, ok i have converted the fib lists, and get the same as grub for the X8 [12:34] booting the X11 block lists gives Error 24: Attempt to access blocj outside partition [12:34] also do you have any clue as to what this format even means? [12:35] (hd0,0)1546320+8.32+8,4096+8,402255872+8,4096+8,2792+8,402280448+4 [12:35] note the first bit has two +'s [12:35] it should look like: 402255872+4096,402280448,2792 [12:35] it should look like: 402255872+4096,402280448+2792 [12:36] the grub manual you pointed me to doesn't even mention two +'s as an option: 1546320+8.32+8 [12:37] oh perhaps that was me ... [12:38] bah it was, i forgot i hand transcribed it [12:40] well you can not use new squashfs-tools with jaunty when you don't update squashfs to 4.0 [12:40] would be basically no problem however [12:41] as you have to do that for karmic too [12:44] apw, it's baffling. I need to look at the source [12:45] Kano, ok so there is a userspace kernel depenancy there [12:45] which will be sorted out in karmic when it opens [12:46] i sent the aufs compile fix to the list, i booted it already live *g* [12:46] yep saw that, thanks for the patch, i am sure it'll be showing up soon enough in our tree [12:47] cking, yeah is most perplexing for sure [12:47] apw, especially the 8.32 part [12:47] i looked at zen sources but only fixed the compile issues. maybe a new aufs snapshot would be good too [12:47] cking, i note that there is a 4096 in there which is the _size_ i am expecting [12:48] its almost as if its using smaller sizes for the extents on that one [12:48] ie less bits for the pointers [13:24] apw, did you try booting specifying the kernel with the block list of 402255872+4096,402280448+2792? [13:30] yeah [13:31] cking, yeah that produced the block out of partition error [13:31] OK - lemme build grub2 with some debug in the ext fs handler. [13:31] what will you send me, usb image to boot? [13:32] ..yep - working on this. It's a little tangled but doable [13:32] something to have on a stick me thinks [13:33] indeed [13:35] rtg, under intrepid a fair number of people are going to have ended up with the ieee80211_regdom=FOO thing set in their module options, when they upgrade to Jaunty those will be preserved and prevent the module loading [13:36] is there a something we can do to remove them, or perhaps we could make those options valid but ignored in jaunty [13:36] apw: so, the module won't load because that is no longer a valid option? [13:36] yeah as its not a valid option we lose the module completely [13:37] apw: we should certainly release note it. [13:37] IntuitiveNipple has reported it on Jaunty upgrades which we could probabally ignore as they are all knowledgable people, but those on Intrepid are likley to be less aware [13:37] ahh good point. should have thought of that [13:39] apw: my thinking is that this is something outside of our normal install, so anyone who does something like that, e.g., adds a module option, is also gonna have to be smart enough to figure out the borkage on an upgrade. [13:40] thats also a fair point. they know they put it in [13:40] apw, Did you have time to check whether the option always causes an oops or just a load fail as expected [13:40] besides, its not like the wireless subsystem hasn't already had some turbulence [13:41] not tried that yet. will do so once i am upgraded on here [13:41] which i would have done, if my build box wasn't in a heap over ext4 [13:41] smb_tp: an oops is a bit more serious [13:41] bug 337929 [13:41] Malone bug 337929 in linux-backports-modules-2.6.28 "ieee80211_regdom=EU now causes oops after latest update" [Undecided,New] https://launchpad.net/bugs/337929 [13:41] I just had not time to look furhter into that [13:42] Was reported to happen for intrepid after the latest maste 2009-03-03(?) update as well [13:43] smb_tp: I'm not to keen on the VIA sata patch for Hardy. what do you think? [13:44] rtg, not in that form anyways. too much thrown into a single patch [13:44] and I don't like the two libata changes [13:44] I fail to understand what they are about [13:45] smb_tp: my thoughts exactly. this falls under the heading of new hardware enablement, so I'm inclined to reject it for Hardy. [13:45] I wanted to give them a chance to come with better patches. I'll write something up later [13:46] amitk: I've rebuilt ARM with the correct CPU freq settings. shall I push or have you already commited to your local repo? [13:46] rtg: I have it my local repo along with some other changes [13:47] amitk: ok. you should push at least that fix so the repo builds ARM [13:48] amitk: that and the /sbin/hotplug fix as well [13:49] rtg: I need to make sure imx51 works well since I might not get another upload before beta. [13:51] amitk: it would sure be nice if what is committed to the core repo actually builds. [13:51] if you aren't comfortable with the CPU freq commit, then revert it. [13:52] rtg: naaah. the cpufreq part is fixed. I want to make sure the AA/aufs parts have the correct settings. ogra's testing them out right now. [13:53] smb_tp: you gonna teach ikepanhc how to use 'git request-pull' next ? (seeing as how you are his mentor) [13:54] rtg, We started this morning send-mail for the acks and later request-pull for the patch [13:54] rtg: I miss something in the patch? [13:55] ikepanhc: I haven't checked it yet, but I was just wondering where smb_tp was headed with your continuing education. (perhaps I'm just annoying him as well) [13:56] rtg, You mean as in "will do" or "am already doing" ;-) [13:57] smb_tp: annoying you? I assume I'm doing that already. [13:57] rtg, Not too much :) [13:57] oh, I ask some this morning. but I am not fully understand the output of git-request-pull [13:58] rtg, Really apw an me spoke with ikepanhc this morning and agreed that for review the git-send-email is good and later if you ack it for Jaunty he will post the request-pull for you [13:59] ikepanhc, Ok, how may we help? [14:00] I get two kerneloops popups on every resume [14:00] I think this is due to https://bugs.edge.launchpad.net/ubuntu/+source/kerneloops/+bug/330606 [14:00] Malone bug 330606 in kerneloops "WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume" [Undecided,New] [14:00] i.e. WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume [edit] [14:00] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [14:00] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] [It's All Text!] OkCancel [14:00] eek [14:00] I meant: WARNING: synaptics was reset on resume, see synaptics_resume_reset if you have trouble on resume [14:00] smb_tp: Let me take a look at the output again [14:00] I think WARNING: triggers kerneloops [14:01] mdz: apw suspected that in an email to me yesterday [14:01] because the resume is too slow [14:01] this one's killer because it happens twice on every single resume [14:01] hrmmm. i had not considered it might trigger that. [14:02] apw: I'm don't think a WARNIG should trigger the oops scavenger [14:02] that fix has not hit upstream and they implemented it slightly differently [14:02] apw: what fix is that? [14:02] that really shouldn't imho, but i will look at the upstream version of the patch [14:03] rtg the fix which this warning is part of [14:03] they took it and accepted it, but then mushed it a bit later in the process [14:03] and the warning was removed i think [14:04] mdz i will pick that up and see what is what [14:04] apw: ok, I guess we need to pull that in, 'cause its gonna annoy a lot of folks otherwise. [14:04] yeah for sure. i suspect we need to check if kernel oops is being overly strong as well [14:05] rtg: I don't suppose the hotplug change could sneak in with the next kernel upload? [14:05] Keybuk: _if_ you can get amitk to push his changes, I'd be happy to accept it. [14:06] rtg: do you have a train to catch? [14:06] :) [14:06] amitk: this is my day to annoy _everyone_ [14:07] I'll push it with the babbage changes [14:08] apw: thanks [14:09] smb_tp: I use the command to show the summary of change: "git-request-pull origin/HEAD ." [14:09] Is that right? [14:09] ikepanhc, not quite. there should be your remote repository somewhere... [14:11] you mean the url? give it git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git? [14:11] ikepanhc: something like this: 'git request-pull git://kernel.ubuntu.com/rtg/ubuntu-jaunty' [14:12] point to your git tree, so that you will know the summary between our tree? [14:16] ikepanhc, the is the id of what was the head before you added something [14:18] ikepanhc: hmm, I'll be more literal. Use 'git request-pull git://kernel.ubuntu.com/ikepanhc/ike-jaunty.git' where is the commit ID that you want me to start pulling from. Its _usually_ HEAD after you've rebased. [14:21] got it, it means the output will tell you where to pulling, and the summary of it [14:21] am I right? [14:21] ikepanhc: correct [14:21] let me take a try [14:25] rtg, with HEAD you probably mean origin/HEAD ... [14:27] smb_tp: perhaps, I've not used request-pull much myself because I'm typically the consumer. I thought the SHA1 was usually the commit ID of where you differences begin, e.g., the patches that you want pulled. [14:27] rtg, right. and imo origin/HEAD is what you pulled last and HEAD is your local head with your own changes [14:28] smb_tp: that makes perfect sense. [14:29] Plus it can be nicely automated with a wrapper script :) [14:37] smb_tp: I got a warn: No branch of git://kernel.ubuntu.com/rtg/ubuntu-jaunty is at: 6afb87c: UBUNTU: SAUCE: Fixing symbol name in HECI module [14:37] ikepanhc, have you pushed to you repo before? [14:38] smb_tp: not yet, I shall push to my repo at zinc first? [14:38] yes [14:42] smb_tp: I have to go home now, its pretty late in Taiwan, otherwise no bus can take [14:42] ikepanhc, sure [14:42] off you go [14:42] see you later [14:46] apw: yay, your script is in checkbox in jaunty now [14:47] mdz yeah got it through in the end! [14:47] and i've even tested it [14:49] apw: that'll save folks a step or two in testing [14:49] apw: will checkbox walk the user through the test as well soon? [14:51] amitk: forgot to mention that I did the newrelease thing, just copied the ARM ABI bits, etc. [14:52] rtg: ok, will git pull again to test [14:59] bradF: btw, I looked at your aufs changes to get it to compile w/o AA. They look sane to be, where sane = doing what has been done to all filesystems when AA patch was applied. [14:59] s/be/me [15:01] amitk: good, now I or someone needs to test them to see if they will actually work [15:01] bradF: where they is? [15:02] rtg: probably me, i'm working on getting things setup so that I can build a babbage image [15:02] bradF: 'they' being the AA patches. [15:03] rtg: I made the changes available to amitk in case he or one of the mobile guys wanted to give them a try before I got to it [15:03] bradF: there is a reason we have public git repos [15:03] rtg: and that is where my changes are [15:05] bradF: Compile-test and send the patch to kernel-team ML to see if someone recoils in horror looking at it. [15:05] then point them to what has been done to the other fs'es :) [15:06] amitk: it compiles [15:06] _then_ lets make sure it still works on booting with aufs [15:07] bradF: and so they are. I'm just a cranky bastard this morning. [15:07] amitk, rtg: will get the changes emailed out today [15:08] rtg: we know [15:09] rtg: I am sloooooow to learn sometimes, but I try :) [15:11] bradF: what is this? humor from mr stoicism? I'm just shocked. [15:12] rtg: you should deal with my business partners every day, it can be a bit trying === Ampelbein is now known as ampelbein [15:38] bradF: I suggest you get rid of the '#ifdef CONFIG_VSERVER' clauses altogether. That config option is totally meaningless as it does not exists anywhere but in that source file. [15:39] looks like hereditary forward porting cruft [15:39] rtg: right [15:39] bradF: it would simplify that patch a bit [15:44] rtg: so what happens if one of the modules (cbc in crypto) that is expected by d-i as a module is compiled-in. Does d-i complain? [15:45] amitk: yep, add a '?' so that its optional [15:48] amitk: the case where adding '?' isn't sufficient is when _all_ of the modules for that d-i are compiled into the kernel. Then you have to get more creative 'cause kernel-wedge bitches that the udeb will be empty. [15:52] rtg: that's where you exclude the udeb for that flavour? [15:53] amitk: the creative part? sometimes I just drop the whole udeb. === aanjhan is now known as ThiefOfBaghdad [16:03] zul: what does the comment in this commit mean? http://kernel.ubuntu.com/git?p=chucks/ubuntu-ec2-jaunty.git;a=commit;h=c9e42c176084bfc18bede682332842a89d14c79d [16:04] rtg: zul: xvd is what's used if the block device is virtio [16:04] the part about "This should not be included in the main ubuntu kernel." bothers me [16:05] rtg: yeah, i agree [16:06] kirkland: and the patch changes the dev name to "sd", is that really what you want? [16:07] rtg: i wouldn't think so [16:07] udev? [16:07] rtg: if you're using virtio, you expect the device to be xvd* [16:07] rtg: i have no context for what zul is trying to accomplish here [16:07] kirkland: looks like an ec2 instance [16:07] rtg: i'm just interjecting that xvd* is sometimes used/expected [16:08] kirkland: zul's explanation on the k-t list was a bit terse (to put it mildly) [16:09] could a udev/rules.d file in some ec2 package (ec2-init?) not make appropriate symlinks? [16:10] Ng: possibly. I'm still trying to grok the impact of his patch set on the distro kernel. [16:11] (where "make appropriate symlinks" means "do any applicable udev magic up to and including renaming the devices". seems cleaner than a kernel patch, but I am probably lacking context) [16:12] Ng: if its a boot-essential device, then it will likely require some initramfs magic. can you do that with ec2 images? [16:13] you can with eucalyptus, but I've not used ec2 extensively enough to need to try [16:23] rtg: looking [16:24] rtg: basically ec2 uses an older version of xen which doesnt use virtio devices so if this patch is included in the main ubuntu kernel then it will break existing xen setups for jaunty [16:24] zul: is there any way to decide that dynamically? [16:25] rtg: not that I know of, the ec2 kernel might have to be treated like a seperate tree like lpia [16:25] oops [16:25] sorry to interrupt, but i'm interested; is kernel aware of duplicate IPs on the same network? [16:26] zul: ec2 might be a separate flavour. LPIA is an arch [16:27] rtg_: maybe something like an ifdef for that case then? [16:27] zul: lemme think about it. [16:27] rtg_: k [16:28] zul: other then that, this patch set is sufficient to create an ec2 capable xen client? [16:28] it seems quite minimal [16:28] rtg_: yep i was using it the other day and building images based on it right now [16:29] cool [16:29] better than the xensource patchset ;) [16:30] zul: what effect will some of these other config changes have on existing xen DomU clients? [16:31]