After applying the latest kernel package, all of my VMs started just fine as
well. All i386.
--
Scott Barker sc...@mostlylinux.ca
Linux Consultant http://www.mostlylinux.ca/scott
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe.
On Fri, Aug 27, 2010 at 12:13:00PM -0600, Scott Barker wrote:
After applying the latest kernel package, all of my VMs started just fine as
well. All i386.
Well, this is good news I suppose.. personally I'd rather have
something 100% reproducing than intermittently failing :(
--
dann frazier
On Mon, 23 Aug 2010 21:56:17 +0200 (CEST), Tomas Pospisek t...@sourcepole.ch
wrote:
On a different note: the last update to the most recent DSA kernels [2]
went completely smoothly - that is all vservers restarted without a
hickup. Makes me wonder if that was caused by a change in the
Thanks, I tested that [1], and it does seem to work.
Hopefully this bug is being worked on by someone upstream.
AFAIK it's not worked on upstream and very probably fixed in newer
vserver releases. I asked on vserver's IRC channel and was told in quite
clear words something along the lines of
Thanks, I tested that, and it does seem to work.
Hopefully this bug is being worked on by someone upstream.
--
Scott Barker sc...@mostlylinux.ca
Linux Consultant http://www.mostlylinux.ca/scott
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of
As a workaround instead of stopping and restarting you might want to use vmount
on the affected vservers:
# vmount foo -- -a
You will get some error messages for all already correctly mounted filesystems,
but you can enter your vserver again.
Running
###
for vserver in `vserver-stat | tail
I am experiencing this problem as well. I have read through this bug report,
and the most recent entry suggesting purging util-vserver does not make any
sense. If you purge that package, you lose the utilities you need to start
the virtual servers. If you re-install it from lenny sources, the
I can confirm that this manifested with the 2.6.26-21lenny3 security
upgrade in Feburary (DSA-1996). It seems like what happens is when the
system boots, it runs the /etc/init.d/util-vserver script, which
attempts to automatically start all the guests which have the 'default'
mark. Sometimes
Hi,
Same problem here (Lenny) since we updated our
linux-image-2.6.26-vserver-86 kernel to 2.6.26-21lenny3 : when the host
server is rebooted, the guest vservers are started but can't be entered
(or accessed by SSH), with the same error message : vlogin: openpty():
No such file or directory (or
Package: linux-2.6
Version: 2.6.26-21lenny3
Severity: normal
After upgrading the kernel from linux-image-2.6.26-2-vserver-686 2.6.26-21
to 2.6.26-21lenny3 and rebooting we could not log into the vservers any
more and got the mentioned error instead:
# vserver foo enter
vlogin:
I experienced similar behaviour, however I saw different results when
using vserver foo start and when using /etc/init.d/util-vserver
start, with only the latter exhibiting the problem. The problem appears
to be caused by secure-mount segfaulting (as you can see in your logs)
when mounting
Unfortunately it seems my fix does not work. The problem is not
consistently reproducible, hence my belief I had fixed it.
I tried backporting the util-vserver package from squeeze
(0.30.216-pre2864-1) and had exactly the same problem.
The problem appears to be caused by failure of old_mmap() in
(I'm including Micah Anderson, maintainer of util-vserver in the Cc: in
the hope that maybe the symptoms mentioned here may ring a bell with
him. I hope you don't mind Micah.)
Dan Gardner wrote on Feb 18 :
I experienced similar behaviour, however I saw different results when
using vserver
On Thu, Feb 18, 2010 at 05:24:05PM +, Dan Gardner wrote:
Unfortunately it seems my fix does not work. The problem is not
consistently reproducible, hence my belief I had fixed it.
I tried backporting the util-vserver package from squeeze
(0.30.216-pre2864-1) and had exactly the same
On Thu, 18 Feb 2010, Dan Gardner wrote:
The problem appears to be caused by failure of old_mmap() in
secure-mount. Here is the strace output of a failed secure-mount:
execve(/usr/lib/util-vserver/secure-mount,
[/usr/lib/util-vserver/secure-mou..., -a, --chroot, --fstab,
15 matches
Mail list logo
