Hi Fajar,
> > not lxd, it's plain lxc from linuxcontainers.org and compiled the
> > same way as 1.1.2. To start I use as part of init-script, started
> > by root:
> >
> > /usr/local/bin/cgm create all ${CONTAINER}
> > /usr/local/bin/cgm chown all ${CONTAINER} `id -u $user` `id -g $user`
>
On Fri, Oct 16, 2015 at 2:43 AM, Dirk Geschke wrote:
> not lxd, it's plain lxc from linuxcontainers.org and compiled the
> same way as 1.1.2. To start I use as part of init-script, started
> by root:
>
> /usr/local/bin/cgm create all ${CONTAINER}
> /usr/local/bin/cgm chown all ${CONTAINER}
Hi Tycho,
> How are you starting these (hand-built lxd?). lxc 1.1.2 => 1.1.3
> reverted an ABI break which could cause some of these problems,
> perhaps you're hitting that somehow?
not lxd, it's plain lxc from linuxcontainers.org and compiled the
same way as 1.1.2. To start I use as part of init
Hi Dirk,
On Thu, Oct 15, 2015 at 09:22:25PM +0200, Dirk Geschke wrote:
> Hi all,
>
> I have unprivileged containers running with lxc-1.1.2. They are
> started by a normal, non-root user and it works. But today I
> tried to start them with lxc-1.1.4 and it fails:
>
>WARN: could not reopen t
Hi all,
I have unprivileged containers running with lxc-1.1.2. They are
started by a normal, non-root user and it works. But today I
tried to start them with lxc-1.1.4 and it fails:
WARN: could not reopen tty: Permission denied
newuidmap: write to uid_map failed: Operation not permitted
Start by checking the host's syslog (right after reproducing the failure
in the container) and look for DENIED messages. Report them here.
Then do
strace -f -ostrace.out whatever-command-you-run-that-fails
in the container. Look at the output of
egrep -e '(EPERM|EACCES)' strace.out
(or send
On 10/15/2015 03:22 PM, Davide Baldini wrote:
Issuing
mount -o remount,ro -t ext4 /dev/md0 /
from inside the guest after it has fully booted, results in:
mount: / is busy
Nevermind that snippet, it's normal it can't be remounted read-only.
-- Davide
_
thanks for the advice but I'm not very skilled in linux, so eacess or
eperm don't ring a bell.
Before I used an OpenZV container and that worked fine. Unfortunately
Proxmox decided to switch to lxc
Op di, 13 okt 2015 om 3:55 , schreef Serge Hallyn
:
Don't know anything about it, but
I actually don't care about micro-management of individual containers, such as
fstab or fsck, as long as they work and do their duty. That's one reason why I
moved away from qemu-KVM.
Wouldn't an fsck that runs when an fs is mounted read-write potentially cause
an error to the fs?
But that
On Thu, Oct 15, 2015 at 5:29 PM, Davide Baldini
wrote:
> Thanks Fajar,
>
> it turned out to be simpler: the guest OS was simply missing e2fsprogs, thus
> sysvinit couldn't switch from runlevel "S" into 2 because of a blocking
> warning message about failed disk check, indicating the culprit was a
Thanks Fajar,
it turned out to be simpler: the guest OS was simply missing e2fsprogs, thus
sysvinit couldn't switch from runlevel "S" into 2 because of a blocking warning
message about failed disk check, indicating the culprit was a /etc/rcS.d/
script. That's what got me believe the container
11 matches
Mail list logo
