On Sat, Sep 30, 2006 at 10:20:56AM +0200, Loïc Minier wrote:
[Loïc Minier]
Now that I think again about it, I suppose what happened is that
some services with init scripts were upgraded, then initscripts, but
since the old initscript was used in the first part of the upgrade,
the tmpfs was
On Sat, Sep 30, 2006, Loïc Minier wrote:
Petter, I'm using cowbuilder, and it broke there as well, today, when
upgrading to sysvinit 2.86.ds1-28. TTBOMK, pbuilder uses a simple
chroot as well.
I grepped the files of sysvinit for chroot, and could not find the
relevant change, perhaps
On Fri, Sep 29, 2006, Petter Reinholdtsen wrote:
Yes. This is fixed in -28. It will not mount it in chroots any more.
Petter, I'm using cowbuilder, and it broke there as well, today, when
upgrading to sysvinit 2.86.ds1-28. TTBOMK, pbuilder uses a simple
chroot as well.
I grepped the
On Sat, Sep 30, 2006, Petter Reinholdtsen wrote:
Right. This is the change I applied to avoid mounting /lib/init/rw/
in chroot environments. I am still curious about vserver environments
and why the package break there.
Thanks, I confirm that the chrooted() test works from from a cowbuilder
Hi,
I've just suffered this same issue with my vservers breaking. The
problem is your use of
mount -n --bind / /.root
By default, vservers have no capabilities and so this call fails with
Permission denied. The only solution I came across was to restart the
vserver with CAP_SYS_ADMIN so that
Package: initscripts
Version: 2.86.ds1-27
Severity: serious
Hello,
the new initscripts package mounts ramfs filesystems into my chroots:
tmpfs /org/chroots/sid/lib/init/rw tmpfs rw,nosuid 0 0
additionally, it breaks on upgrade in my vservers:
Setting up initscripts (2.86.ds1-27) ...
mount:
[Frederik Schueler] wrote:
the new initscripts package mounts ramfs filesystems into my chroots:
tmpfs /org/chroots/sid/lib/init/rw tmpfs rw,nosuid 0 0
Yes. This is fixed in -28. It will not mount it in chroots any more.
additionally, it breaks on upgrade in my vservers:
Can you explain
7 matches
Mail list logo