** Changed in: linux (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/110992
Title:
ipmi modules need to manually inserted and device created
I'm seeing a direct correlation here between the symptom and the kernel
emitting uevents. For example, in the host run:
$ udevadm --monitor
And in another terminal in the host run:
# losetup /dev/loop0 foo
This causes the symptoms even though it has no direct impact on the
container, but does
Public bug reported:
When running a trusty userspace with a newer kernel (e.g. 3.15-rc4),
attempting to start a container fails:
$ lxc-start -n p2
lxc_container: call to cgmanager_create_sync failed: invalid request
lxc_container: Failed to create net_cls:p2
lxc_container: Error creating cgroup n
** Also affects: lxc (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Utopic)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.
I tried reproducing this while using trusty on the host and was unable
to do so. I also could not reproduce with the trusty kernel (currently
3.12) running with saucy userspace on the host. So as far as I can tell
the issue is fixed in 3.12.
I took a stab at trying to bisect, but something between
I tried the kernel patch from the mailing list, but that doesn't fix the
problem. It does fix permissions for most /proc/pid/* files in setuid
processes, but the console problems remain.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to l
I straced bash, and I think this is what ends up causing job control to
be disabled:
ioctl(255, SNDRV_TIMER_IOCTL_SELECT or TIOCSPGRP, [1144]) = -1 ENOTTY
(Inappropriate ioctl for device)
255 is stderr duped to a high fd, so it looks like whatever stderr is
mapped to is not a tty.
--
You receiv
stderr actually is mapped to a pty. The problem seems to be that getty
can't set /dev/console as its controlling terminal because it's already
the controlling tty for init, which is in a different process group.
Thus getty ends up with no controlling tty, this is inherited by bash,
and thus bash ca
On Tue, Jan 14, 2014 at 08:42:06PM -, Serge Hallyn wrote:
> Note that what you describe should also be the case if using a regular
> container
>
> sudo lxc-create -t ubuntu-cloud -n u1
> sudo lxc-start -n u1
>
> Is the process group of init somehow ending up different in the user
The same basic sequence of events happens with and without user
namespaces. init sheds its tty with setsid() but then opens
/dev/console, which as the effect of making /dev/console it's
controlling tty. Later getty also opens /dev/console and tries the
TIOCSCTTY ioctl on the fd. At this point I thi
On Wed, Jan 15, 2014 at 06:37:41PM -, Serge Hallyn wrote:
> If it is possible to get to the inode backing the tty at this point
> then we should be able to do inode_capable(tty_inode(tty),
> CAP_SYS_ADMIN), which should be safe and adquate right?
>
> But I dont' think we can get inode from tty
On Wed, Jan 15, 2014 at 08:18:04PM -, Serge Hallyn wrote:
> The ns_capable line doesn't check the capabilities of tty->session,
> but rather current's capabilities targeted toward the user namespace
> which owns tty->session.
Okay, this was my fundamental misunderstanding. It makes sense now.
Serge: I've got a patch that fixes the problem. I've uploaded a test
build along with the patch to:
http://people.canonical.com/~sforshee/lp1263738/linux-3.13.0-3.18~lp1263738v201401152110/
I still want to verify that it's impossible to steal a tty from a
process in a parent namespace, but if tha
I've added an upstart task to the bug. After looking a bit more it seems
upstart is trying to always open terminal devices with O_NOCTTY, so the
tty ownership by init is likely unintentional and therefore a bug. I
haven't been able to find where in upstart this is happening, but on the
kernel side
** Also affects: upstart
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1263738
Title:
login console 0 in user namespace container is not con
On Mon, Jan 20, 2014 at 06:30:24PM -, James Hunt wrote:
> Upstart does not open /dev/console without O_NOCTTY afaics. Are you sure
> your kernel debug is showing pid 1 is doing this?
Yes, pid 1 within the namespace at least. I couldn't find anywhere where
upstart opened /dev/console without O_
igure that out, and in the meantime I'll attend to the kernel patch.
** Changed in: linux (Ubuntu Trusty)
Assignee: (unassigned) => Seth Forshee (sforshee)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lx
17 matches
Mail list logo