[Vserver] Patching kernel-source-2.6.10 (Debian)
Hi list I tried patching kernel-source-2.6.10 with patch-2.6.10-vs1.9.4.diff: kernel-source-2.6.10 - Linux kernel source for version 2.6.10 with Debian patches But then this happens? patching file mm/mmap.c Hunk #3 FAILED at 1353. Hunk #4 FAILED at 1368. Hunk #5 FAILED at 1418. Hunk #6 FAILED at 1434. Hunk #7 succeeded at 1573 (offset 31 lines). Hunk #8 succeeded at 1813 (offset 31 lines). Hunk #9 succeeded at 1842 (offset 37 lines). Hunk #10 succeeded at 1871 (offset 37 lines). Hunk #11 succeeded at 1907 (offset 37 lines). 4 out of 11 hunks FAILED -- saving rejects to file mm/mmap.c.rej I know there's a kernel-patch-ctx for Debian, but this is only 1.29 vserver patch. Is someone doing the 1.9.4 like a Debian package which applies to kernel-source-2.6.10 - Linux kernel source for version 2.6.10 with Debian patches ? Or have an idea how to apply the patch. Thanks. -- Med venlig hilsen / Best regards Lars E. D. Jensen [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] RedHat ES4 and Vserver with vanilla kernel.
On Wed, Feb 16, 2005 at 09:33:12PM +, Andy Fletcher wrote: I'm trying to get vserver working with the 2.9.10 and the development patches but just getting lots of segfaults all the time, randomly. no wonder, 2.9.10 will not be released anytime soon, you should not use patches from the future ... ;) The guides available on the vserver website have been followed and the system will sometimes boot, but sometimes not. interesting ... In my experience, random crashes are often the result of hardware problems. I would run an updated memtest program overnight first to at least rule out that possibility. Best Regards, Tor Rune Skoglund -- DataKompaniet as Teknobyen Innovasjonssenter, Abelsgt. 5 Tel: +47 73 51 51 51 N-7030 Trondheim, NorwayFax: +47 73 94 38 61 WWW:http://www.datakompaniet.no E-mail: [EMAIL PROTECTED] Ved svar på email, fjern all overflødig tekst, men inkluder alltid nok av gammel email slik at det går klart frem hva saken gjelder. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
AW: [Vserver] Routing Problem with VServer Kernel
I found the reason / solution of this problem ! I started the sshd with v_sshd wrapper. The chbind bound the sshd and all subprocesses to my ipv4root on eth0, so requests via eth1 interface fails. I configured /etc/ssh/sshd_config to listen only on one address and didn't use v_sshd, now everything works fine. regards Holger -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. Januar 2005 13:50 An: vserver@list.linux-vserver.org Betreff: [Vserver] Routing Problem with VServer Kernel Hi, i have a strange behavior of Kernel 2.6.10-vs1.9.3.17 on SuSE 9.2. The kernel uses the wrong route/interface (see below). If i reboot the system with original suse kernel or unpatched vanilla 2.6.10 with same configuration, the outgoing request uses the right interface eth1. This is not inside a vserver, the only change i did was applying the vserver-patch and enabling CONFIG_VSERVER_HARDCPU=y, there are no further iptable or policy routing defines. thanks in advance Holger Manthey My configuration: The 2 network devices eth0 inet addr:x.y.z.10 Bcast:x.y.z.127 Mask:255.255.255.128 eth1 inet addr:172.25.128.10 Bcast:172.25.128.127 Mask:255.255.255.128 and this is my routing table Destination Gateway Genmask Flags MSS Window irtt Iface 172.23.152.0172.25.128.1255.255.255.192 UG0 0 0 eth1 172.25.128.00.0.0.0 255.255.255.128 U 0 0 0 eth1 x.y.z.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 x.y.z.1 0.0.0.0 UG0 0 0 eth0 ping 172.25.128.1 PING 172.25.128.1 (172.25.128.1) 56(84) bytes of data. From x.y.z.10: icmp_seq=2 Destination Host Unreachable ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
patching file mm/mmap.c Hunk #3 FAILED at 1353. Hunk #4 FAILED at 1368. Hunk #5 FAILED at 1418. Hunk #6 FAILED at 1434. Hunk #7 succeeded at 1573 (offset 31 lines). Hunk #8 succeeded at 1813 (offset 31 lines). Hunk #9 succeeded at 1842 (offset 37 lines). Hunk #10 succeeded at 1871 (offset 37 lines). Hunk #11 succeeded at 1907 (offset 37 lines). 4 out of 11 hunks FAILED -- saving rejects to file mm/mmap.c.rej yes, the patch-2.6.10-vs1.9.4.diff is for vanilla kernels (from kernel.org) which should work quite fine with debian but I'm sure somebody has already adapted the patch for the debian source (which is probably more like 2.6.11-rc*) I think I'll stick to the vanilla kernel. I know there's a kernel-patch-ctx for Debian, but this is only 1.29 vserver patch. please file a request to the debian maintainer(s) ... I've read in another thread that the reason why the 1.9.x branch isn't in the unstable/testing Debian yet... is that it's still in development. But the someone in that thread also said that a kernel patch might not apply to normal Debian policy very good, which I partly agree with. Is someone doing the 1.9.4 like a Debian package which applies to kernel-source-2.6.10 - Linux kernel source for version 2.6.10 with Debian patches ? Or have an idea how to apply the patch. look into the rejects and fix them yourself? If I only knew how :) -- Med venlig hilsen / Best regards Lars E. D. Jensen [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] problem with proc
Hi, I' trying to get a vserver environment on SUSE 9.2, Athlon AMD 64, kernel 2.6.10-vs1.9.4 with util-vserver-0.30.203 rel:1mdk, installed as i586.rpm. Kernelcompilation finished without probs. Whe asking vserver-stat i get #: /usr/lib/util-vserver # vserver-stat WARNING: can not access /proc/uptime. Usually, this is caused by procfs-security. Please read the FAQ for more details http://www.linux-vserver.org/index.php?page=Linux-Vserver+FAQ open(/proc/uptime): No such file or directory So I read the FAQ and tried vprocunhide an got /proc/net/snmp6: Invalid argument /proc/net/igmp6: Invalid argument /proc/net/snmp: Invalid argument /proc/net/route: Invalid argument /proc/net/igmp: Invalid argument /proc/net/arp: Invalid argument /proc/net/dev: Invalid argument /proc/net/rpc/nfs: Invalid argument ... and much more like this. capability is loaded as module. /proc is mounted and I can get all information on it (as root on host). How can I check it in context xid 1? What can I do next to solve the problem? Thx Anders -- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Routing Problem with VServer Kernel
On Thu, Feb 17, 2005 at 11:48:04AM +0100, [EMAIL PROTECTED] wrote: I found the reason / solution of this problem ! I started the sshd with v_sshd wrapper. The chbind bound the sshd and all subprocesses to my ipv4root on eth0, so requests via eth1 interface fails. so you actually where _inside_ a vserver chbind ;) I configured /etc/ssh/sshd_config to listen only on one address and didn't use v_sshd, now everything works fine. excellent! hopefully others learn from that too ... thanks, Herbert regards Holger -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. Januar 2005 13:50 An: vserver@list.linux-vserver.org Betreff: [Vserver] Routing Problem with VServer Kernel Hi, i have a strange behavior of Kernel 2.6.10-vs1.9.3.17 on SuSE 9.2. The kernel uses the wrong route/interface (see below). If i reboot the system with original suse kernel or unpatched vanilla 2.6.10 with same configuration, the outgoing request uses the right interface eth1. This is not inside a vserver, the only change i did was applying the vserver-patch and enabling CONFIG_VSERVER_HARDCPU=y, there are no further iptable or policy routing defines. thanks in advance Holger Manthey My configuration: The 2 network devices eth0 inet addr:x.y.z.10 Bcast:x.y.z.127 Mask:255.255.255.128 eth1 inet addr:172.25.128.10 Bcast:172.25.128.127 Mask:255.255.255.128 and this is my routing table Destination Gateway Genmask Flags MSS Window irtt Iface 172.23.152.0172.25.128.1255.255.255.192 UG0 0 0 eth1 172.25.128.00.0.0.0 255.255.255.128 U 0 0 0 eth1 x.y.z.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 x.y.z.1 0.0.0.0 UG0 0 0 eth0 ping 172.25.128.1 PING 172.25.128.1 (172.25.128.1) 56(84) bytes of data. From x.y.z.10: icmp_seq=2 Destination Host Unreachable ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] RedHat ES4 and Vserver with vanilla kernel.
On Thu, Feb 17, 2005 at 12:04:07PM +, Andy Fletcher wrote: Thursday, February 17, 2005, 8:52:57 AM, you wrote: On Wed, Feb 16, 2005 at 09:33:12PM +, Andy Fletcher wrote: I'm trying to get vserver working with the 2.9.10 and the development patches but just getting lots of segfaults all the time, randomly. no wonder, 2.9.10 will not be released anytime soon, you should not use patches from the future ... ;) The guides available on the vserver website have been followed and the system will sometimes boot, but sometimes not. interesting ... In my experience, random crashes are often the result of hardware problems. I would run an updated memtest program overnight first to at least rule out that possibility. Normally this would be my first port of call, but as I mentioned this is actually running under VMWare, and the machine which it's running on is rock solid stable, so I'm certain it's not memory.. hehe, maybe VMware is sooo good at emulating a real PC that it also adds the broken memory found in most recent machines (just kidding ;) Just going to apply the patch Herbert mentioned now.. let me know the results ... best, Herbert Andy ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
On Thu, Feb 17, 2005 at 02:23:00PM +0100, Lars E. D. Jensen wrote: patching file mm/mmap.c Hunk #3 FAILED at 1353. Hunk #4 FAILED at 1368. Hunk #5 FAILED at 1418. Hunk #6 FAILED at 1434. Hunk #7 succeeded at 1573 (offset 31 lines). Hunk #8 succeeded at 1813 (offset 31 lines). Hunk #9 succeeded at 1842 (offset 37 lines). Hunk #10 succeeded at 1871 (offset 37 lines). Hunk #11 succeeded at 1907 (offset 37 lines). 4 out of 11 hunks FAILED -- saving rejects to file mm/mmap.c.rej yes, the patch-2.6.10-vs1.9.4.diff is for vanilla kernels (from kernel.org) which should work quite fine with debian but I'm sure somebody has already adapted the patch for the debian source (which is probably more like 2.6.11-rc*) I think I'll stick to the vanilla kernel. a good choice IMHO, because: - mainline (vanilla) kernels get more testing - linux-vserver patches for vanilla kernels get more testing - issues and bugs are easier resolved with more feedback I know there's a kernel-patch-ctx for Debian, but this is only 1.29 vserver patch. please file a request to the debian maintainer(s) ... I've read in another thread that the reason why the 1.9.x branch isn't in the unstable/testing Debian yet... is that it's still in development. well, then maybe the debian very-unstable/development-testing branch would fit better (no idea what the debian policies are ;) But the someone in that thread also said that a kernel patch might not apply to normal Debian policy very good, which I partly agree with. I cannot comment on that, but it might be true, of course ... best, Herbert Is someone doing the 1.9.4 like a Debian package which applies to kernel-source-2.6.10 - Linux kernel source for version 2.6.10 with Debian patches ? Or have an idea how to apply the patch. look into the rejects and fix them yourself? If I only knew how :) -- Med venlig hilsen / Best regards Lars E. D. Jensen [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] problem with proc
On Thu, Feb 17, 2005 at 04:45:06PM +0100, Andreas Vogt wrote: Hi, I' trying to get a vserver environment on SUSE 9.2, Athlon AMD 64, kernel 2.6.10-vs1.9.4 with util-vserver-0.30.203 rel:1mdk, installed as i586.rpm. Kernelcompilation finished without probs. Whe asking vserver-stat i get #: /usr/lib/util-vserver # vserver-stat WARNING: can not access /proc/uptime. Usually, this is caused by procfs-security. Please read the FAQ for more details http://www.linux-vserver.org/index.php?page=Linux-Vserver+FAQ open(/proc/uptime): No such file or directory So I read the FAQ and tried vprocunhide an got /proc/net/snmp6: Invalid argument /proc/net/igmp6: Invalid argument /proc/net/snmp: Invalid argument /proc/net/route: Invalid argument /proc/net/igmp: Invalid argument /proc/net/arp: Invalid argument /proc/net/dev: Invalid argument /proc/net/rpc/nfs: Invalid argument ... and much more like this. could it be that you have a mixed environment? i.e. 64bit kernel and 32bit userspace? if so, for now the util-vserver tools need to be compiled as 64bit userspace too, if using 64bit kernels, otherwise something like that will happen (this will be fixed in the future) HTH, Herbert capability is loaded as module. /proc is mounted and I can get all information on it (as root on host). How can I check it in context xid 1? What can I do next to solve the problem? Thx Anders -- ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
* Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Feb 17, 2005 at 02:23:00PM +0100, Lars E. D. Jensen wrote: patching file mm/mmap.c Hunk #3 FAILED at 1353. Hunk #4 FAILED at 1368. Hunk #5 FAILED at 1418. Hunk #6 FAILED at 1434. Hunk #7 succeeded at 1573 (offset 31 lines). Hunk #8 succeeded at 1813 (offset 31 lines). Hunk #9 succeeded at 1842 (offset 37 lines). Hunk #10 succeeded at 1871 (offset 37 lines). Hunk #11 succeeded at 1907 (offset 37 lines). 4 out of 11 hunks FAILED -- saving rejects to file mm/mmap.c.rej This isn't hard to fix. There was just a little rework of a couple functions in mmap.c. I can create a patch if you need it for debian+vserver. yes, the patch-2.6.10-vs1.9.4.diff is for vanilla kernels (from kernel.org) which should work quite fine with debian but I'm sure somebody has already adapted the patch for the debian source (which is probably more like 2.6.11-rc*) I think I'll stick to the vanilla kernel. a good choice IMHO, because: Actually, a bad choice. - mainline (vanilla) kernels get more testing But continue to have bugs in them, hope you're not doing much 'net traffic w/ that 2.6.10 kernel and iptables- it's got a bug wrt handling RST packets, as in, it doesn't handle them well and your conntrack table will get filled up. This is fixed in the Debian kernels. The Debian kernels also get a fair bit of testing themselves, I don't know if it's more than vanilla kernels or not, but it's probably less than RedHat kernels. - linux-vserver patches for vanilla kernels get more testing - issues and bugs are easier resolved with more feedback Debian's kernel team is actually rather responsive to handling bugs and getting updates into their kernels to fix the problems in the vanilla kernels (of which there's been more and more lately...). I know there's a kernel-patch-ctx for Debian, but this is only 1.29 vserver patch. please file a request to the debian maintainer(s) ... I've read in another thread that the reason why the 1.9.x branch isn't in the unstable/testing Debian yet... is that it's still in development. well, then maybe the debian very-unstable/development-testing branch would fit better (no idea what the debian policies are ;) The issue with this is that Debian is looking to release and things in unstable migrate to testing and then eventually will be released with stable. unstable isn't really a whole seperate tree in that sense, at least, not right now. After stable is released it'll go back to being the latest-greatest that compiles and works after a cursory test. But the someone in that thread also said that a kernel patch might not apply to normal Debian policy very good, which I partly agree with. I cannot comment on that, but it might be true, of course ... In general the vserver patches actually work pretty well against the Debian kernel patches, it all just depends on what's changeing in each patch. Considering the sizes of the patches I'd say it's pretty good that there was only one reject, and that wasn't hard to fix anyway. Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
On Thu, Feb 17, 2005 at 12:18:31PM -0500, Stephen Frost wrote: * Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Feb 17, 2005 at 02:23:00PM +0100, Lars E. D. Jensen wrote: patching file mm/mmap.c Hunk #3 FAILED at 1353. Hunk #4 FAILED at 1368. Hunk #5 FAILED at 1418. Hunk #6 FAILED at 1434. Hunk #7 succeeded at 1573 (offset 31 lines). Hunk #8 succeeded at 1813 (offset 31 lines). Hunk #9 succeeded at 1842 (offset 37 lines). Hunk #10 succeeded at 1871 (offset 37 lines). Hunk #11 succeeded at 1907 (offset 37 lines). 4 out of 11 hunks FAILED -- saving rejects to file mm/mmap.c.rej This isn't hard to fix. There was just a little rework of a couple functions in mmap.c. I can create a patch if you need it for debian+vserver. yes, the patch-2.6.10-vs1.9.4.diff is for vanilla kernels (from kernel.org) which should work quite fine with debian but I'm sure somebody has already adapted the patch for the debian source (which is probably more like 2.6.11-rc*) I think I'll stick to the vanilla kernel. a good choice IMHO, because: Actually, a bad choice. well _in your opinion_ that is ;) - mainline (vanilla) kernels get more testing But continue to have bugs in them, hope you're not doing much 'net traffic w/ that 2.6.10 kernel and iptables- it's got a bug wrt handling RST packets, as in, it doesn't handle them well and your conntrack table will get filled up. This is fixed in the Debian kernels. it is also fixed in the prepatches for the stable kernel release (2.6.11-rc4) The Debian kernels also get a fair bit of testing themselves, I don't know if it's more than vanilla kernels or not, but it's probably less than RedHat kernels. nobody said that debian kernels are untested, and maybe they get more testing than the mainline kernels but for sure more feedback happens on lkml for mainline than for debian ... no? - linux-vserver patches for vanilla kernels get more testing - issues and bugs are easier resolved with more feedback Debian's kernel team is actually rather responsive to handling bugs and getting updates into their kernels to fix the problems in the vanilla kernels (of which there's been more and more lately...). which isn't the point here, as I was talking about linux-vserver issues and bugs, which AFAIK are not resolved by Debian's kernel team but by the linux- vserver's kernel team ;) anyway, I never did and never will disencourage anybody willing to provide quality support for some distribution or spezialized patchset, on the contrary I'll support anybody doing so, as best as I can, and you should know that by now ;) best, Herbert I know there's a kernel-patch-ctx for Debian, but this is only 1.29 vserver patch. please file a request to the debian maintainer(s) ... I've read in another thread that the reason why the 1.9.x branch isn't in the unstable/testing Debian yet... is that it's still in development. well, then maybe the debian very-unstable/development-testing branch would fit better (no idea what the debian policies are ;) The issue with this is that Debian is looking to release and things in unstable migrate to testing and then eventually will be released with stable. unstable isn't really a whole seperate tree in that sense, at least, not right now. After stable is released it'll go back to being the latest-greatest that compiles and works after a cursory test. But the someone in that thread also said that a kernel patch might not apply to normal Debian policy very good, which I partly agree with. I cannot comment on that, but it might be true, of course ... In general the vserver patches actually work pretty well against the Debian kernel patches, it all just depends on what's changeing in each patch. Considering the sizes of the patches I'd say it's pretty good that there was only one reject, and that wasn't hard to fix anyway. Stephen ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: Routing Problem with VServer Kernel
Le jeudi 17 Février 2005 17:15, Herbert Poetzl a écrit : On Thu, Feb 17, 2005 at 11:48:04AM +0100, [EMAIL PROTECTED] wrote: I found the reason / solution of this problem ! I started the sshd with v_sshd wrapper. The chbind bound the sshd and all subprocesses to my ipv4root on eth0, so requests via eth1 interface fails. so you actually where _inside_ a vserver chbind ;) I configured /etc/ssh/sshd_config to listen only on one address and didn't use v_sshd, now everything works fine. excellent! hopefully others learn from that too ... This should go to http://linux-vserver.org/ProblematicPrograms?action=findfind=ProblematicPrograms ;) -- ,, (° Nicolas Costes /|\ IUT de La Roche / Yon ( ^ ) Clé publique: http://www.keyserver.net/ ^ ^ Musique libre: http://www.magnatune.com/ pgpn0juSCJA7U.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
Torsdag den 17. februar 2005 18:30 skrev Micah Anderson: Stephen Frost schrieb am Thursday, den 17. February 2005: well, then maybe the debian very-unstable/development-testing branch would fit better (no idea what the debian policies are ;) The issue with this is that Debian is looking to release and things in unstable migrate to testing and then eventually will be released with stable. unstable isn't really a whole seperate tree in that sense, at least, not right now. After stable is released it'll go back to being the latest-greatest that compiles and works after a cursory test. It is possible in Debian to have things put into unstable, and keep them from migrating into Sarge. There are many packages that are being held back from moving into testing so that Sarge can release. It is perfectly reasonable to put the vserver development tools into unstable and keep them out of Sarge... if you dont want to go that route, there is also the experimental repository. However, in my experience the vserver development tools are really stable. Micah IMHO putting vserver patch into unstable isn't good seen from a production environment pov. The ideal solution to me would be to use the official debianized 2.6.10 from unstable and backport this to testing release (including the Debian patches if possible) with the newest 1.9.4 vserver patch. Or Make it possible to apply the newest vserver patch to current 2.6 kernel in Debian testing. This would fit as a good base for a production environment since you get vserver bugs out of the way and get newest features. The latter is best I think, but demands more work since it's probably more difficult to apply a 1.9.4 vserver patch on a 2.6.8 kernel (testings 2.6 kernel) - if possible at all... Of course this would also have to be maintained by a cool kernel-source debianizer, who sadly isn't me :( But I don't know if you think this is a good idea. -- Med venlig hilsen / Best regards Lars E. D. Jensen [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
* Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Feb 17, 2005 at 12:18:31PM -0500, Stephen Frost wrote: Actually, a bad choice. well _in your opinion_ that is ;) I don't believe there's really any serious question about the usability of 2.6.10 (which I believe is what Lars was referring to when he was talking about a 'vanilla' kernel- please correct me if I was wrong on that) on a machine running iptables/conntrack. - mainline (vanilla) kernels get more testing But continue to have bugs in them, hope you're not doing much 'net traffic w/ that 2.6.10 kernel and iptables- it's got a bug wrt handling RST packets, as in, it doesn't handle them well and your conntrack table will get filled up. This is fixed in the Debian kernels. it is also fixed in the prepatches for the stable kernel release (2.6.11-rc4) Yes, but I don't think that's what the discussion was about. The Debian kernels also get a fair bit of testing themselves, I don't know if it's more than vanilla kernels or not, but it's probably less than RedHat kernels. nobody said that debian kernels are untested, and maybe they get more testing than the mainline kernels but for sure more feedback happens on lkml for mainline than for debian ... no? Debian kernels get quite a bit of feedback. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=kernel-source-2.6.10 http://lists.debian.org/debian-kernel/2005/02/threads.html Perhaps not as much as lkml, but Debian isn't developing the kernel, just trying to maintain it. A better comparison would be to the feedback RedHat or Suse gets. - linux-vserver patches for vanilla kernels get more testing - issues and bugs are easier resolved with more feedback Debian's kernel team is actually rather responsive to handling bugs and getting updates into their kernels to fix the problems in the vanilla kernels (of which there's been more and more lately...). which isn't the point here, as I was talking about linux-vserver issues and bugs, which AFAIK are not resolved by Debian's kernel team but by the linux- vserver's kernel team ;) anyway, I never did and never will disencourage anybody willing to provide quality support for some distribution or spezialized patchset, on the contrary I'll support anybody doing so, as best as I can, and you should know that by now ;) My only issue is with you appearing to recommend kernels with serious known bugs over Debian kernels with a claim about more testing and because vserver patches patch cleanly with 'vanilla' (ie: released, imv) kernels. If people are really interested I'll provide a vserver patch which patches cleanly against Debian sources. Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
* Lars E. D. Jensen ([EMAIL PROTECTED]) wrote: Torsdag den 17. februar 2005 18:30 skrev Micah Anderson: Stephen Frost schrieb am Thursday, den 17. February 2005: well, then maybe the debian very-unstable/development-testing branch would fit better (no idea what the debian policies are ;) The issue with this is that Debian is looking to release and things in unstable migrate to testing and then eventually will be released with stable. unstable isn't really a whole seperate tree in that sense, at least, not right now. After stable is released it'll go back to being the latest-greatest that compiles and works after a cursory test. It is possible in Debian to have things put into unstable, and keep them from migrating into Sarge. There are many packages that are being held back from moving into testing so that Sarge can release. It is perfectly reasonable to put the vserver development tools into unstable and keep them out of Sarge... if you dont want to go that route, there is also the experimental repository. However, in my experience the vserver development tools are really stable. (I don't appear to have gotten this message, kind of odd, but whatever) My feeling is also that the vserver development tools are quite stable and I really wish they'd release a 'stable' version of them so the current Debian maintainer of vservers would put it in unstable (and even let it migrate to testing/sarge). The mechanisms for keeping things in unstable that shouldn't go into sarge are less than perfect, and make it more difficult to update what's going into sarge. It's unfortunate, but there it is. It's gotten a little better but there's still alot of room for improvement. IMHO putting vserver patch into unstable isn't good seen from a production environment pov. The ideal solution to me would be to use the official debianized 2.6.10 from unstable and backport this to testing release (including the Debian patches if possible) with the newest 1.9.4 vserver patch. 2.6.10 should be making its way into testing/sarge and is planned to become the 2.6 kernel for d-i as well, I believe. Make it possible to apply the newest vserver patch to current 2.6 kernel in Debian testing. This is certainly something I'm all for, and were the Debian maintainer of vserver going to upload a kernel-patch for 1.9.4 I'd be happy to help him create that package such that it patches cleanly against Debian kernel sources (again, not hard to do, really). This would fit as a good base for a production environment since you get vserver bugs out of the way and get newest features. The latter is best I think, but demands more work since it's probably more difficult to apply a 1.9.4 vserver patch on a 2.6.8 kernel (testings 2.6 kernel) - if possible at all... Well, since we're moving to 2.6.10 and it's not too bad to get 1.9.4 patched against 2.6.10 I think that's probably the way to go... Of course this would also have to be maintained by a cool kernel-source debianizer, who sadly isn't me :( Debian kernel-patches aren't hard to create, and the Debian maintainer of vservers has done it before. But I don't know if you think this is a good idea. I think it's a good idea, but I'm not the current maintainer, just another DD. Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
On Thu, Feb 17, 2005 at 01:55:10PM -0500, Stephen Frost wrote: * Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Feb 17, 2005 at 12:18:31PM -0500, Stephen Frost wrote: Actually, a bad choice. well _in your opinion_ that is ;) I don't believe there's really any serious question about the usability of 2.6.10 (which I believe is what Lars was referring to when he was talking about a 'vanilla' kernel- please correct me if I was wrong on that) on a machine running iptables/conntrack. - mainline (vanilla) kernels get more testing But continue to have bugs in them, hope you're not doing much 'net traffic w/ that 2.6.10 kernel and iptables- it's got a bug wrt handling RST packets, as in, it doesn't handle them well and your conntrack table will get filled up. This is fixed in the Debian kernels. it is also fixed in the prepatches for the stable kernel release (2.6.11-rc4) Yes, but I don't think that's what the discussion was about. The Debian kernels also get a fair bit of testing themselves, I don't know if it's more than vanilla kernels or not, but it's probably less than RedHat kernels. nobody said that debian kernels are untested, and maybe they get more testing than the mainline kernels but for sure more feedback happens on lkml for mainline than for debian ... no? Debian kernels get quite a bit of feedback. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=kernel-source-2.6.10 http://lists.debian.org/debian-kernel/2005/02/threads.html Perhaps not as much as lkml, but Debian isn't developing the kernel, just trying to maintain it. A better comparison would be to the feedback RedHat or Suse gets. yes, and if you sum up all the distros feedback regarding the kernel then you might compare it to the feedback the mainline kernels get ... which IMHO is superior to any distribution specific feedback ... - linux-vserver patches for vanilla kernels get more testing - issues and bugs are easier resolved with more feedback Debian's kernel team is actually rather responsive to handling bugs and getting updates into their kernels to fix the problems in the vanilla kernels (of which there's been more and more lately...). which isn't the point here, as I was talking about linux-vserver issues and bugs, which AFAIK are not resolved by Debian's kernel team but by the linux- vserver's kernel team ;) anyway, I never did and never will disencourage anybody willing to provide quality support for some distribution or spezialized patchset, on the contrary I'll support anybody doing so, as best as I can, and you should know that by now ;) My only issue is with you appearing to recommend kernels with serious known bugs over Debian kernels with a claim about more testing and because vserver patches patch cleanly with 'vanilla' (ie: released, imv) kernels. 90% of all 'supposed to be' linux-vserver issues are debian issues (I'm still confident that this will change in the near future), but all linux-vserver testing is currently done with the mainline kernels and patches, so it is natural that I recommend them over 'self' patching them ontop of vendor specific patches, especially if they tend to release newer kernels with older versions ;) If people are really interested I'll provide a vserver patch which patches cleanly against Debian sources. would be great, just make sure that the following is true: - folks know where to get them, and do not adapt the mainline patches themselves - 'your' patches keep up with 'our' development/bugfix cycle (i.e. you track the prereleases and rcs too) - you get some decent testing on the 'adapted' debian version before you put them in the wild this has worked before, so I'm pretty sure it is possible again, and as I said, I have absolutely no problem with a debian kernel patch, if it is maintained and tested ... best, Herbert Stephen ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
* Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Feb 17, 2005 at 01:55:10PM -0500, Stephen Frost wrote: Perhaps not as much as lkml, but Debian isn't developing the kernel, just trying to maintain it. A better comparison would be to the feedback RedHat or Suse gets. yes, and if you sum up all the distros feedback regarding the kernel then you might compare it to the feedback the mainline kernels get ... which IMHO is superior to any distribution specific feedback ... Yet distribution kernels are almost *certainly* tested more and running on more end-user machines than vanilla kernels. My only issue is with you appearing to recommend kernels with serious known bugs over Debian kernels with a claim about more testing and because vserver patches patch cleanly with 'vanilla' (ie: released, imv) kernels. 90% of all 'supposed to be' linux-vserver issues are debian issues (I'm still confident that this will change in the near future), but all linux-vserver testing is currently done with the mainline kernels and patches, so it is natural that I recommend them over 'self' patching them ontop of vendor specific patches, especially if they tend to release newer kernels with older versions ;) This is an unfortunate consequence of the current state of the Debian vserver package, which fewer and fewer people are using (thankfully). Of course, the state of the Debian vserver package is a direct consequence of linux-vserver unstable labeling, which isn't exactly something we have a whole lot of say over, though I've been bitching about it for months anyway. If people are really interested I'll provide a vserver patch which patches cleanly against Debian sources. would be great, just make sure that the following is true: - folks know where to get them, and do not adapt the mainline patches themselves - 'your' patches keep up with 'our' development/bugfix cycle (i.e. you track the prereleases and rcs too) - you get some decent testing on the 'adapted' debian version before you put them in the wild I'll let the Debian vserver maintainer handle official Debian kernel-patch packages for vservers or help if he asks for it, which will follow your suggestions above. At the moment though, that's not me, so if I put a patch out there it'll be whatever I'm currently using (and hence, have tested) and people might have to dig a bit to find them. It also won't be in Debian kernel-patch format as I wouldn't really want people to get the wrong impression about those patches. this has worked before, so I'm pretty sure it is possible again, and as I said, I have absolutely no problem with a debian kernel patch, if it is maintained and tested ... I'd really like to see the official Debian packages updated and uploaded w/ decent kernel-patch packages but unfortunately we still have something of a stand off between the current Debian maintainer and linux-vserver upstream regarding the state of linux-vserver and if it's 'unstable' or 'stable'. I thought this was being worked on and I'm a little disappointed at the lack of comment from those who'd been working on it. Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Can't start vserver on x86_64 with 2.6.11-rc3-vs1.94
I'm at the point where I need some help. The machine is a dual Opteron, with Fedora Core 3 installed. I've downloaded a vanilla 2.6.11rc-3 kernel, and patched it with the latest vs1.94-rc4 patch set, which applied and built cleanly. Then I built the util-vserver packages from source, and installed them with rpm. Since I want to try things first with a FC3 x86_64 virtual server, I ended up using the legacy option to build vserver vts64. I then edited rc.sysinit to remove most everything. I also created a test server with the skeleton build option, and used that info and info from Google to create the newer config files for vts64. I'm fairly certain that all the config stuff is good. But .. when I try to start the vserver, I get this error message: vcontext: execvp(/etc/rc.d/rc): No such file or directory and the server fails to start. Of course, the file really IS there in the vdir, and in the proper place. I've searched high and low, and I cannot find anyone else having this particular issue. Any ideas? As an aside, I can't seem to get anywhere with building a vserver with yum --- it just complains about missing a .pkg directory. when I use the --pkgbase option, it seems to ignore it. Paul ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
On Thu, Feb 17, 2005 at 02:34:24PM -0500, Stephen Frost wrote: * Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Feb 17, 2005 at 01:55:10PM -0500, Stephen Frost wrote: Perhaps not as much as lkml, but Debian isn't developing the kernel, just trying to maintain it. A better comparison would be to the feedback RedHat or Suse gets. yes, and if you sum up all the distros feedback regarding the kernel then you might compare it to the feedback the mainline kernels get ... which IMHO is superior to any distribution specific feedback ... Yet distribution kernels are almost *certainly* tested more and running on more end-user machines than vanilla kernels. My only issue is with you appearing to recommend kernels with serious known bugs over Debian kernels with a claim about more testing and because vserver patches patch cleanly with 'vanilla' (ie: released, imv) kernels. 90% of all 'supposed to be' linux-vserver issues are debian issues (I'm still confident that this will change in the near future), but all linux-vserver testing is currently done with the mainline kernels and patches, so it is natural that I recommend them over 'self' patching them ontop of vendor specific patches, especially if they tend to release newer kernels with older versions ;) This is an unfortunate consequence of the current state of the Debian vserver package, which fewer and fewer people are using (thankfully). no comment ... Of course, the state of the Debian vserver package is a direct consequence of linux-vserver unstable labeling, which isn't exactly something we have a whole lot of say over, though I've been bitching about it for months anyway. there is no 'unstable' in linux-vserver ;) we have: - stable which means: the API and ABI will not change in any incompatible way and new features will not be introduced lightly (compare that to 2.2 or 2.4 kernel) - development which means: this is the place where new features can be found it is intended for testing, evaluation and if you are bold (or want to use the advantage) even production, but do not expect the API and ABI to be changeless or the patches to be well tested ... (compare that to 2.6 and 2.6-rc*) - experimental which means: we added some new stuff or changed something out of the blue, please give it a try in your test setup and let us know what you think/find/discover ... do not use it in production unless you know what you are doing ... (compare that to the bk releases or -mm) If people are really interested I'll provide a vserver patch which patches cleanly against Debian sources. would be great, just make sure that the following is true: - folks know where to get them, and do not adapt the mainline patches themselves - 'your' patches keep up with 'our' development/bugfix cycle (i.e. you track the prereleases and rcs too) - you get some decent testing on the 'adapted' debian version before you put them in the wild I'll let the Debian vserver maintainer handle official Debian kernel-patch packages for vservers or help if he asks for it, which will follow your suggestions above. At the moment though, that's not me, so if I put a patch out there it'll be whatever I'm currently using (and hence, have tested) and people might have to dig a bit to find them. It also won't be in Debian kernel-patch format as I wouldn't really want people to get the wrong impression about those patches. which would be? this has worked before, so I'm pretty sure it is possible again, and as I said, I have absolutely no problem with a debian kernel patch, if it is maintained and tested ... I'd really like to see the official Debian packages updated and uploaded w/ decent kernel-patch packages but unfortunately we still have something of a stand off between the current Debian maintainer and linux-vserver upstream regarding the state of linux-vserver and if it's 'unstable' or 'stable'. see above ... no idea what debian 'unstable' means (maybe that it is supposed to break?) I thought this was being worked on and I'm a little disappointed at the lack of comment from those who'd been working on it. me too, me too ... best, Herbert Stephen ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Can't start vserver on x86_64 with 2.6.11-rc3-vs1.94
On Thu, Feb 17, 2005 at 02:33:59PM -0500, Paul S. Gumerman wrote: I'm at the point where I need some help. The machine is a dual Opteron, with Fedora Core 3 installed. I've downloaded a vanilla 2.6.11rc-3 kernel, and patched it with the latest vs1.94-rc4 patch set, which applied and built cleanly. Then I built the util-vserver packages from source, and installed them with rpm. Since I want to try things first with a FC3 x86_64 virtual server, I ended up using the legacy option to build vserver vts64. I then edited rc.sysinit to remove most everything. I also created a test server with the skeleton build option, and used that info and info from Google to create the newer config files for vts64. I'm fairly certain that all the config stuff is good. But .. when I try to start the vserver, I get this error message: vcontext: execvp(/etc/rc.d/rc): No such file or directory did you check that this is no link of some sort which points into the void, or a script which requires a shell which is not installed in your vserver? carefully check with 'chroot /path/to/vserver ls -la /etc/rc.d/rc' and if you are confident that the script won't hurt your host setup with 'chroot /path/to/vserver /etc/rc.d/rc' and the server fails to start. Of course, the file really IS there in the vdir, and in the proper place. I've searched high and low, and I cannot find anyone else having this particular issue. Any ideas? sidenote: on x86_64 make sure that if your kernel is compiled as 64bit, then the userspace tools (util-vserver) have to be compiled 64bit too (for now) As an aside, I can't seem to get anywhere with building a vserver with yum --- it just complains about missing a .pkg directory. when I use the --pkgbase option, it seems to ignore it. somebody reported yum working for that purpose, please join this thread and comment here ... TIA, Herbert Paul ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
I thought this was being worked on and I'm a little disappointed at the lack of comment from those who'd been working on it. me too, me too ... best, Herbert Is the current debian maintainer actually maintaining the kernel-patch-ctx package at all? The current version in unstable is still 1.29. It seems like the vserver developement branch is misunderstood by the people who decides what comes into unstable. It's like they think that the vserver development branch is still in development (not finished) and therefore not working. Maybe we could somehow discuss this with these people (don't know how it works though). -- Med venlig hilsen / Best regards Lars E. D. Jensen [EMAIL PROTECTED] ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
* Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Feb 17, 2005 at 02:34:24PM -0500, Stephen Frost wrote: Of course, the state of the Debian vserver package is a direct consequence of linux-vserver unstable labeling, which isn't exactly something we have a whole lot of say over, though I've been bitching about it for months anyway. there is no 'unstable' in linux-vserver ;) we have: - stable which means: the API and ABI will not change in any incompatible way and new features will not be introduced lightly (compare that to 2.2 or 2.4 kernel) Which I assume is the '1.2' release set that pretty much everyone I've seen recommend against using... - development which means: this is the place where new features can be found it is intended for testing, evaluation and if you are bold (or want to use the advantage) even production, but do not expect the API and ABI to be changeless or the patches to be well tested ... (compare that to 2.6 and 2.6-rc*) I assume this is associated with the 1.9 set of releases, which is what pretty much everyone seems to recommend using, and is what most of us are running I believe. - experimental which means: we added some new stuff or changed something out of the blue, please give it a try in your test setup and let us know what you think/find/discover ... do not use it in production unless you know what you are doing ... (compare that to the bk releases or -mm) Near as I can tell these aren't even released as anything, and I'm guessing you're talking about ngnet stuff here. It also won't be in Debian kernel-patch format as I wouldn't really want people to get the wrong impression about those patches. which would be? That they're official Debian packages, of course. this has worked before, so I'm pretty sure it is possible again, and as I said, I have absolutely no problem with a debian kernel patch, if it is maintained and tested ... I'd really like to see the official Debian packages updated and uploaded w/ decent kernel-patch packages but unfortunately we still have something of a stand off between the current Debian maintainer and linux-vserver upstream regarding the state of linux-vserver and if it's 'unstable' or 'stable'. see above ... no idea what debian 'unstable' means (maybe that it is supposed to break?) s/unstable/development/ I believe to get the correct lingo for linux-vserver. Perhaps it'd be better if it was called unstable, 'cause it seems very much like Debian/unstable, perhaps not perfect, but nothing ever is and it works damn well for being called unstable. Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
* Lars E. D. Jensen ([EMAIL PROTECTED]) wrote: Is the current debian maintainer actually maintaining the kernel-patch-ctx package at all? The current version in unstable is still 1.29. It seems like the vserver developement branch is misunderstood by the people who decides what comes into unstable. It's like they think that the vserver development branch is still in development (not finished) and therefore not working. Maybe we could somehow discuss this with these people (don't know how it works though). You might read the mailing list for a month or so ago, basically there is some misunderstanding, imv anyway, between the Debian maintainer and the vserver upstream, and neither seems to want to take many steps to correct it. vserver upstream calls the 1.9 series 'development', yet it's the only thing that works for 2.6, and seems to be what upstream and everyone else recommends people to use. The Debian maintainer was intentionally tracking the 'stable' releases, since they're going into a distribution and will likely be released with sarge. Unfortunately, the 'stable' releases are against 2.4 and the number of people using 2.4 or the 'stable' vservers is probably ridiculously small. What's even better is that the 'tools' for the 'stable' set havn't changed since July of last year. vserver upstream appears to be most unwilling to release 1.9 as 'stable' and the Debian maintainer doesn't want to break existing 1.2 installs (if there actually are any..) or even package 1.9 until it's released as 'stable'. This puts the users in something of a bind- they're being told by upstream and other users to run 1.9 because it's got lots of fixes, improvments, features, and an actually maintained userspace tool set; but the Debian maintainer won't update the packages in Debian to what's being recommended. Now, some nice folks built some 0.30.196, as I recall, Debian packages and cleaned up the Debian packaging some, I even critiqued them some. I don't think they made kernel-patch debs, but perhaps they were going to or maybe they did and I didn't notice. I havn't seen those uploaded to Debian yet, and I'm not sure what the hold-up is at this point. Nobody who was working on it seems to want to comment either, perhaps a new thread on that issue needs to be started... Stephen signature.asc Description: Digital signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Documentation on 1-line configuration files
hi guys, where can i find a documentation and explanation (and not only a list) of the new configuration schema of vserver? thanks a lot and bye, werner. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Patching kernel-source-2.6.10 (Debian)
On Thu, Feb 17, 2005 at 03:36:57PM -0500, Stephen Frost wrote: * Herbert Poetzl ([EMAIL PROTECTED]) wrote: On Thu, Feb 17, 2005 at 02:34:24PM -0500, Stephen Frost wrote: Of course, the state of the Debian vserver package is a direct consequence of linux-vserver unstable labeling, which isn't exactly something we have a whole lot of say over, though I've been bitching about it for months anyway. there is no 'unstable' in linux-vserver ;) we have: - stable which means: the API and ABI will not change in any incompatible way and new features will not be introduced lightly (compare that to 2.2 or 2.4 kernel) Which I assume is the '1.2' release set that pretty much everyone I've seen recommend against using... and it will be the 2.0 release for 2.6 kernel ... - development which means: this is the place where new features can be found it is intended for testing, evaluation and if you are bold (or want to use the advantage) even production, but do not expect the API and ABI to be changeless or the patches to be well tested ... (compare that to 2.6 and 2.6-rc*) I assume this is associated with the 1.9 set of releases, which is what pretty much everyone seems to recommend using, and is what most of us are running I believe. and also the (basically discontinued) 1.3 branch for 2.4 - experimental which means: we added some new stuff or changed something out of the blue, please give it a try in your test setup and let us know what you think/find/discover ... do not use it in production unless you know what you are doing ... (compare that to the bk releases or -mm) Near as I can tell these aren't even released as anything, and I'm guessing you're talking about ngnet stuff here. you are wrong here, any release like 1.9.4.5 for example is an experimental release, of course ngnet stuff and such addons are considered experimental or highly experimental too ... It also won't be in Debian kernel-patch format as I wouldn't really want people to get the wrong impression about those patches. which would be? That they're official Debian packages, of course. this has worked before, so I'm pretty sure it is possible again, and as I said, I have absolutely no problem with a debian kernel patch, if it is maintained and tested ... I'd really like to see the official Debian packages updated and uploaded w/ decent kernel-patch packages but unfortunately we still have something of a stand off between the current Debian maintainer and linux-vserver upstream regarding the state of linux-vserver and if it's 'unstable' or 'stable'. see above ... no idea what debian 'unstable' means (maybe that it is supposed to break?) s/unstable/development/ I believe to get the correct lingo for linux-vserver. Perhaps it'd be better if it was called unstable, 'cause it seems very much like Debian/unstable, perhaps not perfect, but nothing ever is and it works damn well for being called unstable. unstable for me is something which will hold for some time but then fall apart (usually accompanied by some fancy effects) like uranium ... linux-vserver is not supposed to fall apart ;) best, Herbert Stephen ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Documentation on 1-line configuration files
On Thu, Feb 17, 2005 at 09:56:08PM +0100, Werner Schalk wrote: hi guys, where can i find a documentation and explanation (and not only a list) of the new configuration schema of vserver? http://linux-vserver.org/alpha+util-vserver http://www-user.tu-chemnitz.de/~ensc/util-vserver/doc/conf/configuration.html as well as in your util-vserver /doc dir as xml (and html) source ... if you are looking for more documentation/explanation this would be a good start for a wikified version where you add all the 'useful' information you might collect on the irc channel (or from the irc logs) HTH, Herbert thanks a lot and bye, werner. ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
re: [Vserver] Can't start vserver on x86_64 with 2.6.11-rc3-vs1.94
On Thu, 17 Feb 2005 14:33:05 -0500, Paul S. Gumerman wrote I'm at the point where I need some help. The machine is a dual Opteron, with Fedora Core 3 installed. I've downloaded a vanilla 2.6.11rc-3 kernel, and patched it with the latest vs1.94-rc4 patch set, which applied and built cleanly. Then I built the util-vserver packages from source, and installed them with rpm. Since I want to try things first with a FC3 x86_64 virtual server, I ended up using the legacy option to build vserver vts64. I then edited rc.sysinit to remove most everything. I also created a test server with the skeleton build option, and used that info and info from Google to create the newer config files for vts64. I'm fairly certain that all the config stuff is good. But .. when I try to start the vserver, I get this error message: vcontext: execvp(/etc/rc.d/rc): No such file or directory Do you have /lib64 installed in the vserver ? Maybe the build strategy ignore this directory (which only exists on x64). - Jacques Gelinas [EMAIL PROTECTED] dav_ufs: Access your home directory using WebDav http://www.solucorp.qc.ca/miscprj/dav_ufs.hc ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Can't start vserver on x86_64 with 2.6.11-rc3-vs1.94
The "legacy" method did, in fact, ignore /lib64 and failed to copy it.
After manually copying that directory,
I got no error messages, but I still couldn't start the vserver.
I finally managed to get the "yum" method to work, and the vserver
starts YEAH!
Jacques Gelinas wrote:
On Thu, 17 Feb 2005 14:33:05 -0500, Paul S. Gumerman wrote
I'm at the point where I need some help.
The machine is a dual Opteron, with Fedora Core 3 installed. I've
downloaded a vanilla 2.6.11rc-3 kernel, and patched it with the latest
vs1.94-rc4 patch set, which applied and built cleanly. Then I built the
util-vserver packages from source, and installed them with rpm.
Since I want to try things first with a FC3 x86_64 virtual server, I
ended up using the "legacy" option to build vserver "vts64". I then
edited rc.sysinit to remove most everything. I also created a "test"
server with the "skeleton" build option, and used that info and info
from Google to create the newer config files for "vts64". I'm fairly
certain that all the config stuff is good.
But .. when I try to start the vserver, I get this error message:
vcontext: execvp("/etc/rc.d/rc"): No such file or directory
Do you have /lib64 installed in the vserver ?
Maybe the build strategy ignore this directory (which only exists on x64).
-
Jacques Gelinas [EMAIL PROTECTED]
dav_ufs: Access your home directory using WebDav
http://www.solucorp.qc.ca/miscprj/dav_ufs.hc
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] Re: Fedora 3 X86_64 vserver
Mart, Adaptive Server Enterprise/12.5.0.3/EBF 10980 ESD#1/P/Linux Intel/Linux 2.4.18-18.7.xsmp i686/rel12503/1919/32-bit/OPT/Mon Mar 24 20:49:12 is running just fine in an FC3 2.6.11-rc3-vs1.94-rc4 kernel host, with a yum-installed vserver with the absolute up to the minute current FC3 updates. It all just *worked*, once I got everything copied over from my old development database machine, and got all the names and permissions set up for sybase. Oh I had to copy resolv.conf from the host into the vserver's vdir. I think that was it. Not yet tested, other than a query or two, but I've always found that if it ran at all, Sybase would work just fine. (Knocking on wood now ) Paul ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
