Bug#576227: insserv: warning: script is corrupt or invalid
On 09/09/2010 12:33 PM, Christian Hofstaedtler wrote: Ola, Do I need to have a kernel with vzevent support for this to test? Chris, this is correct. If so then I must wait until such a kernel appears in Debian... Right. Max Attems informed me yesterday that the kernel will be ready in a few days or so: On 09/08/2010 05:36 PM, maximilian attems wrote: thanks for the notifications, will do next days. current branch has unrelated input abi breakage that first need to be sorted out. Once that done I'll just add latest openvz git. So yes, we have to wait for the kernel with vzevent module first... Thanks, Christian * Ola Lundqvisto...@debian.org [100909 08:06]: Hi Christian I have today uploaded a 3.0.24-4 version with a backport of support for this. It is a rather extensive patch so I would like you to test that this actually works well for you. I'm eager to get this into squeeze so if you have the possibility to test this soon that would be really great. Best regards, // Ola On Mon, Aug 30, 2010 at 08:55:04AM +0200, Christian Hofstaedtler wrote: Hi Ola, Kir, the sysv-rc upgrade today migrated my installation to 'dependency based booting', complained quite a bit about K00vzreboot, but went on with the migration. It left this state: # ls -CF1 /etc/rc6.d K00vzreboot* K01nullmailer@ K01pdns@ K01unattended-upgrades@ K01urandom@ K02sendsigs@ K03rsyslog@ K04hwclock.sh@ K04umountnfs.sh@ K05networking@ K06ifupdown@ K07umountfs@ K08umountroot@ K09reboot@ README If I'm not mistaken this will start vzreboot first, and then the other shutdown scripts will never run. If this is the case, this is a critical issue. After restarting the CT, I now have these scripts: # ls -CF1 /etc/rc6.d K00vzreboot* K01nullmailer@ K01pdns@ K01unattended-upgrades@ K01urandom@ K02sendsigs@ K03rsyslog@ K04hwclock.sh@ K04umountnfs.sh@ K05networking@ K06ifupdown@ K07umountfs@ K08umountroot@ K09reboot@ README S00vzreboot* This can't be correct ;) Christian -- christian hofstaedtler -- - Ola Lundqvist --- / o...@debian.org Annebergsslingan 37 \ | o...@inguza.com 654 65 KARLSTAD | | http://inguza.com/ +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513310: [Debian] Re: Bug#513310: vzctl fails to set capabilities, and subsequently fails to start any VE
I'm not really sure but maybe this one can help:
http://git.openvz.org/?p=vzctl;a=commitdiff;h=bca585d9c7c9e72bad99fc3f48bd8245ab21848c
Daniel, can you try it out?
If that does not work I need straces from both working and non-working
versions.
Ola Lundqvist wrote:
This was already corrected in
vzctl (3.0.22-9) unstable; urgency=low
* Correction of capability problem on some platforms. Closes: #482974.
-- Ola Lundqvist o...@debian.org Sat, 7 Jun 2008 19:26:21 +0200
Do you have any other idéa?
// Ola
On Thu, Jan 29, 2009 at 08:54:13AM +0100, Ola Lundqvist wrote:
Hi Kir
I will backport this fix. I thought I already did that. Thanks!
// Ola
Quoting Kir Kolyshkin k...@openvz.org:
This is caused by newer kernel headers (in this case on a build system
that was used to build this vzctl package), and is fixed in
vzctl-3.0.23. See the following git commit:
http://git.openvz.org/?p=vzctl;a=commit;h=0d6bfad92c7cb6a193801ce8dac3a0dc64396ca8
So the solution is either to upgrade to vzctl-3.0.23 or to backport
this simple fix.
Ola Lundqvist wrote:
Hi Daniel
This is interesting as it works very well on my systems. On other hand
that
system is a 686 based one.
You write that you have not significantly changed your system, but at the
same time you write that you are not sure that it has ever worked with the
2.6.26 kernel.
Can you please elaborate when it worked last time, and what you have done
since then?
Which version of the linux kernel are you running for example?
If you switch to the 2.6.24 kernel do it work then?
Best regards,
// Ola
On Wed, Jan 28, 2009 at 01:34:52PM +1100, Daniel Pittman wrote:
Package: vzctl
Version: 3.0.22-14
Severity: grave
Justification: renders package unusable
When trying to start a VE I get the following output:
] sudo vzctl start sd-dev
Starting VE ...
VE is mounted
Unable to set capability: Operation not permitted
Unable to set capability
VE start failed
VE is unmounted
When I strace the system I see the following call to set capabilities:
[pid 14391] capget(0x20071026, 0, NULL) = -1 EFAULT (Bad address)
[pid 14390] exit_group(0) = ?
Process 14390 detached
[pid 14391] capset(0x20071026, 0,
{CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800, CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800, CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800}) = -1 EPERM (Operation not
permitted)
This fails to start the VE, reporting that the capset operation failed.
None of my configuration has been modified significantly, and certainly
not
to change the capability set of the VE or anything like that.
This same configuration worked on a 2.6.24 VZ kernel, but I am not
sure it ever
worked on the 2.6.26 kernel.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-openvz-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages vzctl depends on:
ii iproute 20080725-2 networking and
traffic control too
ii libc6 2.7-18 GNU C Library: Shared
libraries
ii vzquota 3.0.11-1 server virtualization
solution - q
Versions of packages vzctl recommends:
ii rsync 3.0.5-1fast remote file copy
program (lik
Versions of packages vzctl suggests:
pn linux-patch-openvznone (no description available)
-- no debconf information
--
--- Inguza Technology AB --- MSc in Information Technology
/ o...@inguza.comAnnebergsslingan 37\
| o...@debian.org 654 65 KARLSTAD|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513310: [Debian] Re: Bug#513310: vzctl fails to set capabilities, and subsequently fails to start any VE
This is caused by newer kernel headers (in this case on a build system
that was used to build this vzctl package), and is fixed in
vzctl-3.0.23. See the following git commit:
http://git.openvz.org/?p=vzctl;a=commit;h=0d6bfad92c7cb6a193801ce8dac3a0dc64396ca8
So the solution is either to upgrade to vzctl-3.0.23 or to backport this
simple fix.
Ola Lundqvist wrote:
Hi Daniel
This is interesting as it works very well on my systems. On other hand that
system is a 686 based one.
You write that you have not significantly changed your system, but at the
same time you write that you are not sure that it has ever worked with the
2.6.26 kernel.
Can you please elaborate when it worked last time, and what you have done
since then?
Which version of the linux kernel are you running for example?
If you switch to the 2.6.24 kernel do it work then?
Best regards,
// Ola
On Wed, Jan 28, 2009 at 01:34:52PM +1100, Daniel Pittman wrote:
Package: vzctl
Version: 3.0.22-14
Severity: grave
Justification: renders package unusable
When trying to start a VE I get the following output:
] sudo vzctl start sd-dev
Starting VE ...
VE is mounted
Unable to set capability: Operation not permitted
Unable to set capability
VE start failed
VE is unmounted
When I strace the system I see the following call to set capabilities:
[pid 14391] capget(0x20071026, 0, NULL) = -1 EFAULT (Bad address)
[pid 14390] exit_group(0) = ?
Process 14390 detached
[pid 14391] capset(0x20071026, 0,
{CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800,
CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800,
CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_FSETID|CAP_KILL|CAP_SETGID|CAP_SETUID|CAP_LINUX_IMMUTABLE|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_IPC_LOCK|CAP_IPC_OWNER|CAP_SYS_CHROOT|CAP_SYS_PTRACE|CAP_SYS_BOOT|CAP_SYS_NICE|CAP_SYS_RESOURCE|CAP_SYS_TTY_CONFIG|0x7800})
= -1 EPERM (Operation not permitted)
This fails to start the VE, reporting that the capset operation failed.
None of my configuration has been modified significantly, and certainly not
to change the capability set of the VE or anything like that.
This same configuration worked on a 2.6.24 VZ kernel, but I am not sure it ever
worked on the 2.6.26 kernel.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-openvz-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages vzctl depends on:
ii iproute 20080725-2 networking and traffic control too
ii libc6 2.7-18 GNU C Library: Shared libraries
ii vzquota 3.0.11-1 server virtualization solution - q
Versions of packages vzctl recommends:
ii rsync 3.0.5-1fast remote file copy program (lik
Versions of packages vzctl suggests:
pn linux-patch-openvznone (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#482974: [Debian] Re: Bug#482974: vzctl: vzctl start fails with Unable to set capability: Invalid argument
Ola, We plan to have it ready in two weeks. The patch that fixes the issue is in git [1] and I suggest you to take it and build a bugfix update to 3.0.22 [1] http://git.openvz.org/?p=vzctl;a=commit;h=0d6bfad92c7cb6a193801ce8dac3a0dc64396ca8 Ola Lundqvist wrote: Hi Ok, I see. This is a problem on all other platforms than i386. The reason is that they are automatically built. If the kernel information is wrong on the build machine it will get this problem. When is the next release? Best regards, // Ola On Tue, May 27, 2008 at 12:47:50PM +0400, Kir Kolyshkin wrote: It's just that vzctl needs a header (capability.h, usually this is /usr/include/linux/capability.h) from an older kernel (i.e. pre 2.6.24). We hope to fix this in the next vzctl release. Ola Lundqvist wrote: Hej Marcus I'll try to get some comments from upstream about this. I was not aware of the build dependency towards the kernel. Kir or anyone else in the openvz group, can you describe this to me? Best regards, // Ola On Mon, May 26, 2008 at 12:28:25PM +0200, Marcus Better wrote: Package: vzctl Severity: grave Version: 3.0.22-8 This started happening recently: ~# vzctl start 107 Starting VE ... VE is mounted Unable to set capability: Invalid argument Unable to set capability VE start failed VE is unmounted Downgrading temporarily to 3.0.11-13 fixed it, but I believe the problem was introduced in 3.0.22-7. According to upstream it is caused by compiling against a mis-matched version of /usr/include/linux/capability.h. I'm running a self-compiled 2.6.24 OpenVZ kernel. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-melech (SMP w/2 CPU cores; PREEMPT) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415579: kernel-patch-openvz: Kernel does not compile
It looks like you have not enabled CONFIG_VE (perhaps because of enabled CONFIG_SECURITY). So the way to solve this is disable CONFIG_SECURITY and then enable CONFIG_VE. Konstantin Seiler wrote: Package: kernel-patch-openvz Version: 028.18.1 Severity: grave Justification: renders package unusable The current kernel-patch doesn't compile. The output of one tried compilation is below. The Used Kernelsource was 2.6.18.dfsg.1-11. Cheers, Konstantin Command: make-kpkg --added-patches openvz --append-to-version -kamet2 --initrd binary-arch [...] == making target debian/stamp-build-kernel [new prereqs: sanity_check stamp-kernel-conf]== This is kernel package version 10.067. /usr/bin/make EXTRAVERSION=-kamet2 ARCH=i386 \ bzImage make[1]: Entering directory `/usr/src/linux-source-2.6.18' CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h dnsdomainname: Unknown host CC kernel/sched.o kernel/sched.c: In function ‘__activate_task’: kernel/sched.c:1565: warning: implicit declaration of function ‘ve_stop_idle’ kernel/sched.c:1565: error: ‘ve’ undeclared (first use in this function) kernel/sched.c:1565: error: (Each undeclared identifier is reported only once kernel/sched.c:1565: error: for each function it appears in.) kernel/sched.c: In function ‘deactivate_task’: kernel/sched.c:1718: error: ‘pcpu’ undeclared (first use in this function) kernel/sched.c:1735: warning: implicit declaration of function ‘ve_strt_idle’ kernel/sched.c:1735: error: ‘ve’ undeclared (first use in this function) kernel/sched.c:1735: error: ‘cpu’ undeclared (first use in this function) kernel/sched.c: In function ‘pull_task’: kernel/sched.c:3037: error: ‘ve’ undeclared (first use in this function) kernel/sched.c: In function ‘vsched_add_vcpu’: kernel/sched.c:8218: error: invalid application of ‘sizeof’ to incomplete type ‘struct ve_cpu_stats’ kernel/sched.c:8218: warning: implicit declaration of function ‘VE_CPU_STATS’ kernel/sched.c:8218: error: ‘struct fairsched_node’ has no member named ‘owner_env’ kernel/sched.c:8218: error: invalid application of ‘sizeof’ to incomplete type ‘struct ve_cpu_stats’ kernel/sched.c:8218: warning: passing argument 1 of ‘__constant_c_and_count_memset’ makes pointer from integer without a cast kernel/sched.c:8218: error: ‘struct fairsched_node’ has no member named ‘owner_env’ kernel/sched.c:8218: error: invalid application of ‘sizeof’ to incomplete type ‘struct ve_cpu_stats’ kernel/sched.c:8218: warning: passing argument 1 of ‘__constant_c_memset’ makes pointer from integer without a cast kernel/sched.c:8218: error: invalid application of ‘sizeof’ to incomplete type ‘struct ve_cpu_stats’ kernel/sched.c:8218: error: ‘struct fairsched_node’ has no member named ‘owner_env’ kernel/sched.c:8218: error: invalid application of ‘sizeof’ to incomplete type ‘struct ve_cpu_stats’ kernel/sched.c:8218: warning: passing argument 1 of ‘__memset_generic’ makes pointer from integer without a cast kernel/sched.c:8218: error: ‘struct fairsched_node’ has no member named ‘owner_env’ kernel/sched.c:8218: error: invalid application of ‘sizeof’ to incomplete type ‘struct ve_cpu_stats’ kernel/sched.c:8218: warning: passing argument 1 of ‘__memset_generic’ makes pointer from integer without a cast kernel/sched.c:8221: error: ‘struct fairsched_node’ has no member named ‘owner_env’ make[2]: *** [kernel/sched.o] Fehler 1 make[1]: *** [kernel] Fehler 2 make[1]: Leaving directory `/usr/src/linux-source-2.6.18' make: *** [debian/stamp-build-kernel] Fehler 2 kamet:/usr/src/linux-source-2.6.18# -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-kamet1 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages kernel-patch-openvz depends on: ii bash 3.1dfsg-8 The GNU Bourne Again SHell ii grep-dctrl2.9.3 Grep Debian package information - ii patch 2.5.9-4Apply a diff file to an original kernel-patch-openvz recommends no packages. -- no debconf information
Bug#400675: kernel-patch-openvz: patch still not applying cleanly
Hi Steve, See my comments below. Steve Langasek wrote: If so I need to be prepared as that will probably break this patch. Why is this patch so fragile? If it breaks that easily, it hardly seems releasable -- how do we protect against it being broken by security updates? I suggest that a. A workaround is to have kernel-image-openvz, the same as Linux-VServer does. Thus people will not run into troubles. b. A solution is to coordinate Debian security updates with OpenVZ kernel team. Thus OpenVZ team can timely (i.e. before you release) prepare a patch which is surely applicable to your kernel flavour. Answering your question -- there were two fails, I looked through .rej files and found their causes: One failed hunk in net/ipv6/udp.c -- looks like the patch from 2.6.18.5 is not applied to linux-source-2.6.18-7: * http://tinyurl.com/2n9554 Six failed hunks in net/ipv4/ip_tables.c -- same, looks like a few patches from 2.6.18.y-stable are not applied to linux-source-2.6.18-7. I see at least the following ones: * http://tinyurl.com/2l5sae * http://tinyurl.com/38bgxa * http://tinyurl.com/2wx9jz I have just checked that after applying four patches linked above, kernel-patch-openvz-028test007.1 applies cleanly on top of linux-source-2.6.18-2.6.18-7. Thus the question: are you tracking the -stable tree, and how closely do you follow it? Regards, Kir. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400675: kernel-patch-openvz: OpenVZ-Patch does not apply to Debian-Kernel
Could we set up some machinery in order to be notified ASAP about the kernel-patch-openvz rejects? Ola Lundqvist wrote: Hi On Mon, Dec 04, 2006 at 02:40:21PM +0300, Vasily Tarasov wrote: Hi, When I was preparing previous patch only 2.6.18-5 was available from I see. I forgot about that I requested -5 instead of -6. Debian repository, so the patch was for this version. In 2.6.18-6 they have merged some fixes for mm from 2.6.19, therefore rejects... Ohh. You can download new patch from http://7ka.mipt.ru/~vass/debian/patch-2.6.18.3-deb-6-028test006-cpt-sched-fix.gz Thanks a lot! Regards, // Ola Thank you, Vasily! Ola Lundqvist wrote: Hi I have now applied this file and I got a number of rejects... Attaching the apply logs. I patched the following debian version... 2.6.18-6 Can you help me to correct these problems? Regards, // Ola On Wed, Nov 29, 2006 at 12:27:29PM +0300, Vasily Tarasov wrote: Hello, 028test006 patch (with lockup fix from xemul@) for Debian is ready. You can download it from http://7ka.mipt.ru/~vass/debian/patch-028test006-debian.tar.gz Thank you! Kirill Korotaev wrote: Vasiliy, please help Ola. 2.6.18-ovz028test006 has been released today and includes 2.6.18.3 patches. Thanks, Kirill Hi Thanks for the report. Yes 2.6.17 is not supported, because 2.6.18 is the version that will be shipped in etch. I'll contact upstream about this issue. The kernel team have moved to 2.6.18.3 according to the changelog in http://packages.qa.debian.org/l/linux-2.6/news/20061123T193153Z.html Kir, Kiril or Vasily: Can you help me to get a applyable version of the kernel patch? Regards, // Ola -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
