On Mon, 27 Mar 2006 11:06:15 +0200 Peter Mann <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 24, 2006 at 11:10:52AM +0100, Gerald Hochegger wrote: > > I'm willing to maintain the Ubuntu Dapper 2.6.15.6 kernel with > > the vserver 2.0.2 patch for some time in the future > > since we ourself depend heavily on this combination. > > i'm just trying patch-2.6.15.6-vs2.0.2-rc13.diff and the newest ubuntu > kernel: you can try, and if you succeed, then congratulations, you got farther than i did. i too run debian sarge with ubuntu kernels on my server. i tried patching 2.6.15-19.29 with vs2.0.2-rc13 this weekend. it didn't go well. actually, merging the patches is essentially the same as 2.0.1.3 (i don't know exactly how similar, because when i finally gave up on compiling 2.6.15-19.29 with 2.0.2-rc13 and resolved to use 2.0.1.3, i deleted all my merge patches, only to realize once i started patching with 2.0.1.3 that the rejects were VERY similar, possibly identical, from what i remembered). but the merging is the (relatively) easy part, once you understand what the kernel code and vserver patch are trying to do. the hard part is getting the merged result to compile. if you use the ubuntu .config (but with the addition of vserver options), which compiles nearly every module possible, then your first compile error will be with unionfs. do a google search and you'll learn that the vserver bme patch, which i'm guessing has found its way into 2.0.2, has changed the vfs interfaces. i'm guessing ubuntu includes unionfs, the official 2.6.15 kernel doesn't, so vserver's 2.0.2 patch doesn't fix unionfs to use the modified interface. i stared and traced through the unionfs code and the modified vfs interfaces and i just don't know enough to make it work (couldn't find where unionfs could obtain a nameidata struct, i think it is, and pass it in the updated interfaces, assuming a NULL wasn't sufficient as in some examples i saw). so i finally gave up on unionfs and disabled it. next i ran into compile problems with MTD. i looked at the problem for 5 minutes and gave up on merging 2.6.15-19.29 with 2.0.2-rc13, after having already wasted 2 hours on unionfs and envisioning nothing more but the same frustration. even though i don't need unionfs nor MTD, i took it as a bad sign, because if these things are failing to compile, then no telling how many things are compiling but are going to break at run-time. i saw that Gerald Hochegger was using 2.0.1 for his published kernels (https://wiki.ubuntu.com/VServer or http://www2.uni-klu.ac.at/support/VServer, but can only find 2.0.1.2 mentioned), so i decided to try patching with 2.0.1.3. after 15 minutes apparently recreating my hastily deleted 2.0.2rc13 merge patch and an hour compiling, i was testing 2.6.15-19.29-vs2.0.1.3 on my workstation. (testme.sh-0.15 & testfs.sh-0.13, using ext2 & ext3, pass all tests.) with that, may i recommend 2.0.1.3 over 2.0.2-rc13. ;-) and analyzing the situation, 2.0.1 is better than 2.0.2 from a stability stand point. 2.0.1 is on its third revision, while 2.0.2 is still in the rc stage, not even "released" yet. unless some 2.0.2 feature is needed (bme would be nice, but i've lived without it since 1.9) AND you can get it merged & compiled, i would stick with 2.0.1 (currently 2.0.1.3). i'm currently using breezy's 2.6.12 with 2.0 and it provides everything i need (but i'm tired of ubuntu's sata ata-passthrough patch filling up my logs everytime i hit hddtemp with cacti), which proves that the latest-greatest isn't always needed (at least for me ;-). > cat ../vserver.13thfloor.at/Experimental/patch-2.6.15.6-vs2.0.2-rc13.diff > | patch -p1 --dry-run --quiet 1 out of 1 hunk FAILED -- saving rejects to > | file Makefile.rej > 1 out of 2 hunks FAILED -- saving rejects to file > arch/sparc64/kernel/sys_sparc.c.rej 1 out of 1 hunk FAILED -- saving > rejects to file drivers/block/Makefile.rej 1 out of 1 hunk FAILED -- > saving rejects to file include/asm-i386/page.h.rej 1 out of 18 hunks > FAILED -- saving rejects to file kernel/sys.c.rej those appear to be the same rejects as i encountered with 2.0.2-rc13 and 2.0.1.3, but that was fri/sat/sun and i've slept since then. > can someone look at this last FAILED hunk??? as Björn Steinbrink said, but more definitively (having just dealt with it): ubuntu provides its own kernel/user memory split patch. vserver's is finer grained (half gig increments), but i'm happy with the default 3/1 split, "when in rome, do as the romans", and most importantly it was the path of least resistance (in my opinion), so i stuck with the ubuntu logic for choosing the memory split. but you have to use the rest of vserver's logic because it's depended on in other files in the patch. the really confusing part that you have to keep straight while reading the code is that ubuntu and vserver differ in terminology. vserver's "SPLIT_3GB" means 3 GB *user-space*, but ubuntu's "3GB" means 3 GB *kernel-space*. btw, i find vserver's terminology most "natural". i've attached my patch that merges the failed hunks from applying vs2.0.1.3 to 2.6.15-19.29 (which should be very similar, if not the same, for 2.0.2-rc13). as already stated, i've tested the resulting kernel (2.6.15-19.29-vs2.0.1.3) against the latest testme & testfs scripts, and should i not encounter any problems before this weekend, i'll migrate my server to it (though my workstation is k7 and my server is amd64). and my patch may be redundant compared to Gerald Hochegger's work, but his kernel is not the latest (19.27 vs 19.29), i couldn't figure out the vserver patch revision from the package name (2.0.1.2 as mentioned elsewhere?), i couldn't review how he resolved the patch failures (without downloading his source package, diffing it against ubuntu, and running interdiff against that diff and vserver's patch), and i was scratching my own itch; it was a fun learning experience. > my modified patch: > http://people.uvt.tuke.sk/~mann/patch-2.6.15.6-vs2.0.2-rc13-ubuntu.diff.gz personally, i don't like to see patches this way. i know and trust Herbert's patches, but any additions to that i would want to see separately (for code inspection). i'm not too lazy to apply two consecutive patches (a lot of large patchsets are split out requiring that anyways), but i am too lazy to run interdiff against Herbert's original and your's. and it gets to really be a pain when Herbert releases an updated patch, where your deltas are still applicable, but too difficult to extract from your modified patch to apply with Herbert's update. anyways, i quickly looked at it, and it looks like it should work. looks like you decided on using Herbert's code to set __PAGE_OFFSET, but if that's the case then you really need to remove ubuntu's patch, especially from arch/i386/Kconfig where a user sets "User address space size", as that is negated by vserver's patch and would be confusing from a user's perspective if both configuration options exist (will the *real* config option please step forward). for cleanup you would need to remove include/asm-i386/page_offset.h (which only sets PAGE_OFFSET_RAW, but unused with your patch) and all references to that file or preprocessor variable in include/asm-i386/page.h (two lines right above where vserver's patch defines __PAGE_OFFSET). but if this is only for your personal use, then i'm sure you can remember to ignore ubuntu's configuration question and set vserver's. ;-) > i like to see patch to latest ubuntu dapper kernel ... and i can help, > like now ... but i'm not vserver kernel guru ;-) oh, i'm not either, so everything in this email comes with the standard disclaimer, but i've followed vserver for about 6 months and try to keep up with linux kernel issues (like memory split) on kerneltrap & lwn. i'm probably able to note the above things only because i've wasted more time and made more mistakes than you have. ;-) > i'm using Debian Sarge and i want stable kernel for my vservers ... so > dapper kernel is IMHO the best kernel for now ... (maybe until Debian > Etch) ;-) [i don't want change kernel after each vanilla release] nope, not even after etch, because between debian freezing their version of the kernel and the actual release, the kernel is nearly worthless from a "recent hardware" perspective, and finding support is difficult (ie vserver only tracks recent kernels and if you discover an issue with an older kernel/patch, you'll probably be told to upgrade). with ubuntu's 6 month release cycle and 18 months of security support, i can use their kernel (with vserver patch) at release and have 1.5 years and 3 more ubuntu releases before i lose security support. for example, i'm currently using breezy's 2.6.12 with vserver's 2.0, and pretending that i can't get any vserver release to apply to dapper's 2.6.15, i can continue using my current setup and i'll still have another year and 2 more ubuntu releases before i have to upgrade to continue receiving security support. i still have the problem with using older kernels on newer hardware, but i have another chance to upgrade every 6 months (and can even adapt my purchasing to accomodate that schedule). maybe i'm making too big of a deal over this, but after enduring the sarge release cycle, i'm cautious. alternatively, there's a vserver-enabled kernel in unstable, but from the description i couldn't figure out what vserver patch they were using (stable or unstable?) and to receive security support am i going to have to constantly upgrade to the latest version in unstable; that's nearly as bad as tracking upstream. if etch releases with a vserver-enabled kernel, that'll be useful for a whole 6 months before the standard problems apply. a kernel really needs to be in the volatile repository to be useful; but i'm fine using ubuntu. enough of my ranting. that's my posting for the month, so the list doesn't have to worry about my multi-kilobyte ramblings for a while. :-D corey -- [EMAIL PROTECTED]
linux-source-2.6.15-19.29-vs2.0.1.3.patch.gz
Description: Binary data
_______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
